Mike's Blabberings

I was over at my buddy Chad’s garage again tonight tinkering with his 1958 Chevy pickup. Chad bought the truck when he turned 16 and planned to restore it and drive it all through college. Ten years later, the truck still doesn’t run. To an untrained eye, there’s little different from when he bought it. What’s wrong with this picture?

Chad had high hopes early. He bought the truck on a whim and, without too much inspection, figured it’d be a few month job to get it on the road again. Needless to say, months passed, and it was still in his dad’s garage. Life (and college) got in the way, and the truck sat abandoned for several years, with only an occasional wrench gracing it’s steel.

He’d buy new parts from time to time, and store them away to be put on at a later date. He’d spend the occasional weekend tearing something off, grinding on it, patching, and welding. Tearing off one part would show deeper damage. This was Chad’s baby, and he couldn’t simply mask that damage, so he’d plan to fix the next issue before continuing, or order another new body panel. Little visible progress was made, but lots of hours and dollars were invested.

Finally, 3 weeks ago, after lots of pressure from his friends and family over the last few years, Chad took the truck out of storage at his parents 2 hours away and brought it to his own garage. He’s got a reinvigorated passion to get this thing running, and I’m excited to help him.

Some of these challenges sound familiar to software veterans, but are any analogies actually relevant?

Consider for a moment that you’re assigned to a project that requires you to migrate an existing web application from Java+Oracle to PHP+MySQL. Doing rewrites of applications can often be driven by a desire to consolidate platforms and reduce costs, and there is often a fixed timeline. The project is locked and loaded, and you haven’t had time to do technical due diligence.

You dive right in without much planning, and before you know it, you’ve passed your deadline. You got hung up digging into the guts of the old software. What little new code you were able to write relies on features that your new database doesn’t have, but you didn’t realize because you were testing against the old one.

What has agile software development taught us that can right this project-gone-bad?

It would be a stretch to suggest the core tenets of the agile manifesto are entirely applicable. There really aren’t any processes/tools getting in the way, he’s not held up by a desire to document everything about the truck, contract negotiation doesn’t matter, and he really doesn’t have much of a plan that would inhibit responding to change.

However, the principles behind an agile team can be very useful to this situation.

• Rapid, continuous delivery of a useful software truck.  Don’t worry if, for example, the interior dome lights aren’t working right away.  But let’s get it running, and make sure it’s poised to keep getting better.
• A working software truck is the principal measure of progress.  Not how many new body parts got ordered off ebay, or how cool the sketch of flames on the doors might look.
• The project truck is built by motivated individuals, who should be trusted.  The friends that help need to be committed to the goal.
• Continuous attention to technical excellence and good design.  Don’t rush it.  And avoid duct tape.
• Simplicity.  One of the beautiful things about old cars is how few moving parts there really are under the hood.  Don’t ruin it by adding flamethrowers to the exhaust or an automatic transmission.
• Regular adaptation to changing circumstances.  Expect that we’ll uncover a few unanticipated problems, but be ready to figure them out and keep charging forward.

Chad is a perfectionist, and he’s not in a rush to get this thing done. However, we have made some progress already in the last few weeks. Here’s where we are now: most barriers to working on the truck have been removed, we’ve started a “spike” of work to get the motor close to starting, I’m going to help put together a prioritized list of features (similar to user stories), and we’ll identify incremental milestones along the path to winning car shows.

With any luck, we’ll get the motor fired up after our first sprint. And maybe, just maybe, I’ll learn something along the way that can help us develop better software!

Photo courtesy of chicanerii on flickr