There are many, many parallels between software development and various types of janitorial work. Whether it’s cleaning up a disgusting mess of an inherited codebase or doing plumbing work in the form of a big sloppy data migration. For years I have been teasing our sales people for bringing in too many leads that consist of my team having to do the often soul-crushing, but nevertheless critical job of “cleaning up the messes of others”.
Yesterday, at home I started to apply these concepts to household chores, and tie it in to Joel Spolsky’s recent post “The Duct Tape Programmer“, an article from last week that I found to be incredibly insightful (how could you expect anything less from the man behind StackOverflow). It’s also worth checking out Jak Charlton’s take on Joel’s article, which is quite good.
I swear this is going somewhere good, continue reading after the jump! And no, it will not include sample code for creating firmware for a high tech japanese toilet…maybe for part II!
When Cleaning My Bathroom, I Made These Realizations
- 50% of the effort gets the bathroom about 75% as clean as the “cadillac of cleaning jobs”.
- The “50% job” get’s it done now when I have time, and the earlier it get’s done the more people can benefit from it’s cleanliness.
- That “50% job” is not sustainable in the long term, every few weeks I need to get in there on my hands and knees and go to town.
How this Parallels Software Development
- (More effort == More time) == More money. We generally don’t write code because customers want code (some do). They want their business problems solved, and they want them solved as effectively as possible for a reasonable amount of money. It is certainly possible to deliver Pizzas in a $500,000 Bentley Automobile. Is it any more effective than an ’04 Corolla? No. Which do you think is a better business decision? (This bathroom analogy is getting old, I’m going to switch to pizza because it’s lunchtime and I’m hungry.)
- A 50%-good solution that people actually have now solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. (Quote: Joel Spolsky quoting Jamie Zawinski in Peter Seibel’s book “Coders at Work“). Think about it, you have a backlog of pizza orders and the ’04 Corolla is parked outside. On the other hand, you can wait until next week when you could get the loans to go through for the Bentley. Sure, your delivery guy and your customers are likely to be very impressed by that smooth Bentley. But, if their pizzas don’t show up until next week it doesn’t do anyone a lick of good today.
- Software can get “hairy” over time. (Joel has written extensively about this subject too.) The more “quick fixes” you pile on over time, the hairier it gets. This is what refactoring is for. Every now and again you jump in an beautify the code and right the architectural wrongs.
To Be or Not to be a Duct Tape Programmer
On our team, speed is crucial. Our clients consistently want more features for less money. The longer a project takes, the more energy and momentum it saps from our entire organization. The effect on morale can even reach out and effect other projects. To a large extent it is a project management issue, but finding a middle ground on the development team is how we can balance the “now” needs of our clients and project managers with the long term maintainability issues that can eventually grow out of control and get us later down the road. I like to think that our dev team is comprised of a good combination of pragmatic “Duct Tape Programmers” who have what it takes to get the job done now, as well as “Serial Polishers” who have what it takes to engineer and elegant solution the first time around.
If left unchecked, the Duct Tapers might check in some code that is a little bit too kludgey for comfort, and those Serial Polishers might spend weeks over engineering something as simple as a contact form. However, when when they put their heads together they can usually find the sweet spot.