Like many people, over the last 6 months I’ve become a huge fan of American Chopper, a TV series on the Discovery Channel about Paul & Paul Teutul’s Orange County Choppers. If you haven’t seen this show, it chronicles some of the goings on at a father-son custom motorcycle building shop. They build some very cool bikes with a lot of style; and along the way we viewers get to watch them conflict and get angry with each other due to their radically different work styles.
If you know me, you probably would think this show is pretty out of character for me. I feel that way a bit myself! After all, I don’t ride bikes and I’ve never really had much interest in them. I’m just a geek that builds software for a living. But I’ve gotta tell you, this show is great. And more surprising to me is that I’ve recently found myself at work quoting American Chopper as examples of how to build software! Am I mad? (probably) I’m sure Paul Sr would be a bit surprised to hear that there is much in common between building software and building bikes!
Its all in the dynamics of the show. Paul Sr is always Mr. Responsible. He’s furious when the shop is not clean and organized, and even more furious when bike’s aren’t getting built to schedule. Paul Jr, on the other hand, is pretty casual about schedules. He’s very creative, and always has yet-one-more-idea for how to improve the bike. But that creativity comes at a cost, and usually its his father’s frustration that deadlines won’t get met. Paul Jr says his dad does nothing but gripe and sit back with his “size twelves” up on the desk. Paul Sr says his son, who he affectionately calls “numb-nuts”, wouldn’t ever get a bike finished if it weren’t for Sr’s constant monitoring.
Well, if you can envision it, its a lot like software. Depending on who you ask, building software is considered part art, part science. I think those that went to “engineering” school really want it to be a science. (I’m one of those!) But in fact, its not really. For any given problem, there are an infinite number of ways to write code which will solve the problem. A scientific problem always has the same right answer. But there is definitely no “right” answer in software. Likewise, building a bike is part science – a lot of physics and mechanics go into engineering a bike that operates smoothly and safely. But, the custom bikes have as much art to them as science, and there is no right answer either. Because of this creative element, schedules on these types of tasks are hard to do. If it were a science (like building a car on an assembly line), you know exactly how long it will take to build. But when you are building something artistic, something never built before, how long will it take??
This is the core give-and-take of software engineering.
So, in the course of a 60 minute American Chopper show (actually they usually build the bikes over the course of two episodes), you can watch the complete dynamics of the software lifecycle! It starts with the problem to solve – either building a Spiderman themed bike, or an IRobot bike for Will Smith, or a bike to dedicate to the firefighters of 9/11. This is the requirements gathering phase. Then it moves into the design phase, where they figure out what to do with the bike. Then the team usually does a bit of bonding in the form of some out-of-work event before moving into the “heads-down” building phase. After building, it goes into final assembly, then a short test cycle, and then its done!
But what is remarkable to me is to watch the tradeoffs between Paul Sr and Paul Jr. Sr is all about schedules, business, and getting things done. He’s the one that built the shop from nothing, and really understands the value of being efficient, clean, and professional. Jr is younger and a bit sloppier with his work habit, but relentless in applying detail to making great bikes. He cares about schedules, of course, but if he comes up with a way to make the bike better late in the game, he’ll take the risk to make the change. Fortunately, the two are in constant battle with each other. Ironically, if they agreed on everything, they’d probably make bikes that weren’t half as good as they are!
Software is the same way. You’ve got folks on the team that are trying to keep things moving forward, on schedule, and consistent. There are other folks on the team who’s job is to build the product and be creative, making sure that its high quality, innovative, and as good as it can be. Sometimes, we don’t realize what the “best” way to implement is until we’ve already started. Unfortunately, the only way to fix it is to iterate on the design while in the implementation process. If you don’t do it, you won’t have great software. And if you do it, you’ll risk your schedule and possibly miss the date!
Anyway, the overlaps are amazing. If you are planning to be a software manager soon, watch this show. You’ll learn about how to balance creativity vs business, about team morale, about coaching (see their youngest in the crew – Cody), and about conflict. Its really cool.
There are some differences, though. In the virtual world of software, we sometimes crash. On the Chopper show, they have less tolerance for that.
Well, thanks for listing to my abstract thoughts on software…. Maybe I just like watching TV and calling it work.
