Snakes in your Coffee

In an attempt to be more versatile and perhaps less Java-centric, I’ve taken a look at learning a new programming language. The choices were narrowed down to classic Objective C, Ruby or Python. Given that Objective C is a bit more arcane and less likely to make much headway on the Internet, I’ve now got to choose between Ruby and Python.

Looking at both of these language, I can immediately see the similarities. Neither requires compiled binary class files, and both are compact languages. Clearly, Ruby is the more trendy language as everyone and their roommate’s girlfriend’s dog seems to be doing it. So I chose Python.

Python is a fairly young language, currently in its 2.x incarnation, and 3.0 under development. Invented in late-80’s by Guido van Rossum, it is heavily influenced by Modula-3 and Haskell (!). It had gained a large cult following of hardcore developers and early praise from the likes of Martin Fowler. Fowler once wrote in his Patterns of Enterprise Applications book that he’d love to see Python give Java a run for its money. All we need is a huge corporation to back it, and a guerrilla marketing gambit.

In my brief excursion so far, a few programming principles have come into question. Revelations of the clumsiness of the Java language have surfaced and I’ve gladly enjoyed the experience so far. Certain things that only nerdy computer scientists would fine remotely intriguing, such as comparisons between statically-typed vs. dynamically-typed lanugages, checked vs. unchecked exception and verbosity vs. compactness of a language.

As architects and designers we are resolute in attacking problems creatively and without prejudice. As implementors and builders, we must understand all the tools available to us and appreciate the differences between each. Knowing the advantages and likely uses of one over the other will afford us a greater breadth of knowledge and allow us to make better choices.

The Next Generation of Collaborative Development

I have recently discovered Google Docs, and decided that I love it, like many things Google. I was collaborating on a few documents with a friend, and watched in real-time as he edited and fixed my typos. He was somewhere in Vancouver, BC and I was sitting my gitches on my couch in Mississauga, ON. It dawned on me that this is collaboration could be the key to distributed development.

Suppose there was Google IDE, you could have developers pair-programming remotely and watching each other code. It would be revolutionary! Incorporated with Subversion and revision history, your development environment now lives on a remote server. For fresh, new startups and open-source projects you could house your project and code on Google. For corporations and proprietary source code, you could install the web application internally.

In some ways, this would be similar to the “screen” program in Unix, where you could trade control back and forth to each other and see each other type. Of course, it would need to have all the features of eclipse, minus the bloat and memory consumption.

When the Internet goes down, you could still code and work, since its just a text editor. Perhaps give the option of storing a cache locally for offline development. Perhaps even add a merge functionality for when you reconnect to the repository. It would need to be responsive, so obviously the UI has to be responsive like everything else Web 2.0.

No longer would you need to download overly bloated IDEs, or wait for minutes as the Mac color wheel spins, eating up memory. No longer would you need to undergo a learning transfer as you upgrade to the next popular IDE of the Month/Year/Decade.

How would we build this, short of getting hired by Google? If we built this first, there’s a slim chance that Google will buy us. Slowly developing more and more applications running solely on the Internet, Google has solved many problems and done the hard part for us. Soon “Google” will become synonymous with “Internet” and that would be just fine with me.

We need to take our cues from Google, and create wealth by solving the hard problems. Build something people will want to use, because our measure of success will not be how technically perfect our solution is, but by how many people find our product useful. Otherwise, it is just adding to the already cluttered closet of the Internet.

What Would Jesus Do?

I’ve always had a penchant for all things miraculous: God speaking to me through a homeless person, large structures randomly falling out of the sky, estimating a development effort accurately 8-months in advance. I’ve recently been tasked with the last one, given that we are subscribing to a SDLC that is slowly falling down a giant waterfall. We’re currently in Week 13 of requirements gathering.

The field of software engineering has evolved through years of theoretical research. Computer Scientists have come up with great ideas that should work in theory, but are seldom applicable in real world situations. I have learned more about software development out in the field than university could ever have prepared me for. Most of the things I did learn in university, I would need to look up on the Internet anyway, say if the rare occasion ever arose that I would need to know how hash maps are implemented using Red-Black Trees (I only apply at Google once ever 18 months).

Software is an immature discipline and software itself rarely lasts much longer than 4-5 years before it becomes legacy. As such, it becomes increasingly hard to predict, as complexity increases. Only thirty years ago, computers were the size of refrigerators and Irene, the 70 year old grandmother you see today coding in COBOL while staring at a 50lb CRT monitor running at 640×480, was in the prime of her life. And in fact, there’s an army of Irenes who don’t like it when you show up in Lacoste shoes, and tight pants. Sometimes I wear pin-striped dress pants with a checkered shirt and that completely throws her off.

Irene probably went to a very good school where they taught her everything to know about documentation and software specification. In fact, she probably received accolades for her work in the field of requirements engineering. But now, the business’ needs have changed drastically, as have the times, and that mainframe system backed by a flat file-based database, can’t support what the business needs to do.

Large corporations reinvent themselves all the time to accommodate climate changes in the economy, business direction changes and continually respond to the market’s whims. There is no reason software development shouldn’t be any different. Software processes need to be adaptive to these changes just as much as individuals do. Clinging onto traditional methods that are known to be heavyweight and slow will only demean what we do as professionals and continue to lose the trust and confidence of our customers. Arguably, some of the time, developers are happy to engage in lightweight processes, but its the archaic bastions of old-school software engineering who claim authority over this subject matter, that refuse to allow it.

Agile development is so radically different than most of what they’ve been teaching in school that traditionalists are worried that they will need to adjust their thinking. Meanwhile, there are those of us who have been dying, waiting for something like this to come along and revitalize our craft. In time, agile processes will mature and evolve, and things like distributed agile development will come into focus. In time, agile processes will become obsolete and perhaps a successor will emerge as a better way to build software and provide business value. Those are the things we should look forward to and embrace, rather than reject and undermine.

How do television evangelists do it? Day after day, they convince millions of Americans to follow them and give them money, and yet I can’t convince one person in this organisation to adopt a lean software development methodology. Perhaps, I’d have better luck converting them to mormonism. But that’d be too easy. Given the option of marrying multiple 16-year olds, I’m sure they’d choose that over lent any day. I’d be happy with just one.

Christians need to work on their marketing. The best that Christians have come up with in the last 100 years is a fish. Lame! I recently saw a bumper sticker that said, “Try Jesus” as though Jesus was a spicy Mexican dish that you’d never seen or heard of before advertised on a giant poster on the side of a dingy roadside restaurant that read, “Try our new Mole con Pollo!” And frankly, I don’t doubt that Jesus loves mole con pollo.

References:

¹Agile Requirements Best Practices Ambler, Scott
²Agile Requirements Definition: A View from Requirements Engineering Eberlein, Armin, et al.
³Mole con Pollo! Mexicans everywhere.

Life in the Consultinghood

I realized on the weekend that I really don’t like to iron my own clothes. In fact, I don’t like ironing other people’s clothes either. How blissful it was, to just throw on a pair of jeans and tee-shirt and head to work. These days, I have to have a routine in order to get ready for my day in consultinghood: underpants, dress shirt, dress pants, belt, security badge, cell phone and keys all to the iTune of Tom Jones. Sometimes, I throw on a sweater vest.

Sometimes, I consider everything in perspective. Yes, I do enjoy looking like Carlton Banks, just not everyday. It makes me wonder if perhaps the only way I can achieve job satisfaction is to run my own company.

I have an idea to start up a website that incubates business ideas in partnership with technology. Something like what open-source software is, except for entrepreneurs. A common meeting place online where people can post blogs about business ideas and have a community of contributors help build that idea. Open-source ideas where everyone is free to use and incorporate it into their business model. People who are successful contribute back to the community with lessons learned, and help future entrepreneurs.

An Idea Farm of sorts.

I would love to start something like that, even in real life. I suppose its more akin to what Google has done with the 80/20 rule, where 80% of the business funds the 20% of the entrepreneurs. Wouldn’t it be rad if we had a 20/80 rule where 20% of the business funds 80% of the cool ideas.

For now, I’m commuting in my Civic 46.8 kms to the client site (which I’m not allowed to say who) where I sit in the basement elbow to elbow with other consultants and try to convince someone to buy more of my time. That is what I do; I sell my brain through Word documents and Power Point presentations (they’re called “decks” in the biz). Maybe someday, through RFPs as well.

The consulting I want to get into is the kind that ThoughtWorks does or what SpringSource does. Agile Software enablement, or training. Developing skills through SOLID methodologies. But of course, these types of engagements are harder to sell because there’s no visible bottom-line. You can’t tell the VP to pay $250K for two hippy consultants and all they’re going to do is make the employees happier. What a waste of money! We need to deliver business value through better software practices.

So that’s why there’s so many shitty projects out there. Because if the project was fun and exciting to work on, there would be no reason to bring in consultants. Most companies only bring in consultants when they are desperate.

Currently, I’m working as a Business Analyst. My official title is Senior Consultant, which translates to “A Much Older Business Analyst.” I write requirements documentation and do analysis. I take those documents and get sign-off from the business. Then I take that document and go to the Systems Programmers and translate it to tech terms. Then they say its impossible to do that in COBOL and I say, What the fuck are you still doing supporting COBOL, and they say, Its bringing us in $280 million a year so we’re not touching it. And I think, That’s fair.

And it goes back and forth a few more times, and in fact, a few more months until someone in a pair of expensive running shoes jumps in the room and yells out, Just Do It!™ And to your disappointment and mine, its not Tommy Vu!

Perhaps the hardest part of consulting is getting things to start moving. Analysis paralysis is an easy trap to fall into, and while most people think they’re being iterative and agile, rather, they are just not moving at all; only everything else around them, particularly time, is moving along quite splendidly.

If everyone by some miracle ends up happy with the requirements documents, then we start the design. The design is perhaps both the most painful and most fun part. Partially, because I come in knowing nothing about the existing system, but I’m required to come up with a working and viable solution and design document. Sweet! What about proof of concept or spiking on a task you say? What! You have just violated Waterfall process. Go back 10 paces. In this game, if you can somehow get in some coding, you probably haven’t been at it for long enough for your technical skills to become stagnant.

Perhaps I’m too jaded already for this job. Perhaps I haven’t given it a fair chance yet. Perhaps tomorrow, I will be reassigned to an engagement where I can actually use what I’ve learned the last three years and maybe even improve on it. Perhaps tomorrow, I’ll win the lottery and never have to work again. Personally, I hope I win the lottery.

Waterfall and the Advent of Agility

I’ve been following this thread at TSS: Agile Software Development: True Adoption or Just a Label?

So far its been very interesting. The most interesting is this article about Waterfall: Managing the Development of Large Systems The comments made by the readers are excellent, on both sides of the argument. I especially found this comment very insightful:

When you read the Agile Manifesto, note that it’s not about practices, or languages, or technologies. It’s about a management style, a style of leading an organization that is very different from the typical command and control, which is still frequently used, particularly in government contracting.

The Lean Software Development books do a great job of explaining this. I think it really boils down to how contracts are defined. Things like TDD and continuous integration are just lower-level details.

My experience with agile processes has been interesting, and I have started to wonder how we can possibly measure success when there are no metrics to go by. Are we doing the right thing? I’ve learned a great deal in the past few years, but mostly in terms of leadership and development practices. I’ve learned how to become a better coder, but more as an after-effect of following the Agile methodologies. I’ve become an advocate of Lean Software Development, but this can only be as matter of common sense. How do we recognize the need to be lean or to continue with “whatever works”? Perhaps in a few more years, these will become clearer to me (though I wouldn’t bank on it).

Coding Standards

Bob Martin has written a lucid article on his idea of what Coding Standards should be. I agree with most of his points, especially his ideas on the value of pair-programming with the team lead:

Nothing is quite as persuasive to a young programmer than pairing with the lead programmer and hearing him say: “We don’t do things that way; we do things this way.”

With our new eComm team, I have set aside 1-2 hours each iteration to sit with each developer and pair-program with them. I drive for half-an-hour, and then they drive for half-an-hour. Coupled with empathy and tact, the hard-nosed coder will relent to doing things The Right Way™; for the greater good, and the greatness of the team.Once the team gets enough experience, I hope to have them start pair-programming with each other. When new recruits join the team, they spend some time pair-programming with the Team Lead. When they get comfortable, they pair-up with other members of the team occasionally.Achieving a level of consistency and fluidity to the code, brings out a certain enjoyment and pride for development. Though I understand the plight of the team lead in which there is rarely time to catch up on work, let alone spend time reviewing code, or even sitting down and pairing with them, I sincerely believe it only takes 1-2 hrs to reap years of benefit.

Neal Ford Talks About DSL vs. API Design

Following up with Bloch’s presentation on Effective API design, I would encourage those that are interested in programming languages to look through Neal Ford’s slides on Language Oriented Programming, which does a brief comparison on DSL vs. API design, along with how to construct good bases for DSLs in Java.

I found this presentation invigorating, and it got me very excited. This is a refreshing new way of looking at software design, and would address many of the ugly legacy design patterns that we have inherited specifically due to J2EE. I look forward to seeing more Java frameworks evolve towards a design similar to JMock, which accurately captures behaviour, rather than function.