“Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too.” – Paul Graham, Hackers and Painters

I am often brought back to this essay by Paul Graham. He often grounds us in our pursuit of perfect software by putting in perspective the nature of our work. We may not be as artistic as our tradesmen counterparts, but if we strive for a more balanced reform between technical work and artistry, we can deliver high quality and more original work, leading to innovation and greater aspirations.

Creativity is key in software development as much as it is in any other profession.

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.

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.