We used to build software like a crappy banana split stand. Grab the banana off the shelf (which probably is about to expire), throw on ice cream, cover it in chocolate, add some cherries, whip cream, nuts, stir it up, put a spoon in it, hand it to the customer, take their money, and let them walk away.

STOP THAT RIGHT NOW!

Stop the gargantuan effort up front, stop compromising the quality of pieces that don’t get seen, stop making your customer wait til the end of the project.

Find a beautiful banana and show it to your customer. Let them take a bite. That might be all they need. Or they might want to take a small piece of it and try it in banana bread. They might not like that. But that’s OK, because we have lots of time and lots of banana left. Take the next piece and make a banana smoothie for them. Maybe add a strawberry for the next sip.

Aaron Oliver might suggest that a good time to have these tastings is right after your daily stand-up.

Let your customer be involved at each step. Let them help you make the right changes early and often. Be agile. Don’t be the hobo behind the bad banana split counter.

My favorite driver is an outspoken dutch guy. He’s quick on the wheel and if he doesn’t get the idea I’m trying to convey to him he’ll just type something to try if that works. When he does get what I’m mumbling it’s on the screen faster than when I would have typed it myself, so it doesn’t give me time to get frustrated over things not being like the would be when I had the keyboard. And that gives me time to look for exits and pittfalls.

He also dismisses anyone that tries to say pairing isn’t as effective as coding solo.

No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. … If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.

My biggest stumbling block to date has been the ratio of time driving to navigating when you’re pairing a senior and junior dev. Trying to balance productivity and mentoring isn’t always easy. I find allowing the Sr. dev to drive 2/3 of the time and Jr. dev to drive 1/3 strikes close to the optimal balance. Any more driving for the Sr and you’ll lose the Jr entirely as he rides along for the tour. Any less and you lose valuable time in guiding-by-doing.

Whether you’re the driver or navigator, take your role seriously. Share in the responsibility and help foster a mutual respect for the other.

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