Wednesday, September 30, 2009

Go faster!

Recently, a development group came to us and wanted to know how they could "go faster". Their users were demanding more and more changes, and they were having trouble keeping up. "Go faster", an interesting choice of words. Immediately I thought of a race car driver.

If I wanted to drive a car fast, what would I need? The first thing I thought of was a fast car. If I want to go fast, I'm going to need a car that can do it. What are some of the fastest cars out there? Indy cars are pretty fast, but I wouldn't have a clue how to drive one of them. So I guess I need to have knowledge to drive the car fast. I'm also going to need experience. The first time I drove a car, I wasn't driving on the highway during rush hour. I worked up to it. Alright, I got a fast car, I know how to drive it, and I have the experience to drive it fast. What else do I need? A race track would be good. I'm not going to go 200 mph around my neighborhood, nor would I want to go that fast on a dirt road.

So Car + Knowledge + Experience + Road = Fast.

What does that have to do with software development? A car is essentially a tool. When developing software, we use an IDE, build scripts, source control, and all sorts of other tools. We need to understand the problem that needs to be solved and the language we are going to use to solve it. Having a good understanding of development best practices and good software design comes with experience. Having a good process (path to follow) makes getting high quality code out the door so much easier.

So Toolset + Knowledge + Experience + Process = Fast.

There are some other interesting things to note about this analogy. You need all four things; otherwise, this equation does not work. I could be the most experienced driver on a race track, but my go kart just isn't going to win the race. I could have the fastest car, but without the knowledge and experience to drive it, I'm going to crash and burn. Likewise, if I have the car and the know-how, but I'm trying to go fast on a road littered with potholes, I'm going to have to slow down or I'll lose control.

This is true for software development, too. Not having the best toolset can really slow down even the most seasoned developer. If a newbie is handed the best development tools in the most organized environment, the lack of knowledge and experience is going to slow them down. Finally, a poor process is either going to slow down a project or completely derail it.

Happy driving.


  1. Interesting analogy, quite true. Software development takes all these things but most management types don't understand this and expect results without understanding what it takes to get them. This leads to an unhealthy divide between management and developers.

    Another nice idea I heard once somewhere is this: Good, Fast, Cheap: Pick any two. It fits well with your ideas too. You can't produce something worthwhile (good) very quickly (fast) without paying a premium (cheap) for it (whether the cost be in experienced developers, useful tools, etc).

  2. I spent all day yesterday having a garage sale and reading. I made $3.00! I was reading Coders at Work - great book. I find myself saying, "Wow! These guys accomplished so much." A perfect story talking about fast development is that of Netscape. With their backs against the wall they released in a matter of months - and they only had a handful of developers. Everyone was on the same page focused on the deadline and nothing else mattered. Of course we know that this story takes a bad turn with a later release.

    Someone would lean over your cubicle and say, "What the fuck did you checkin; that's complete bullshit--you can't do it that way. You're an idiot." And you'd say, "Fuck off!" and go look at it and fix it and check it in.

    The goal was important. There wasn't time for hurt feelings or 40 meetings to make a small decision... In the end that was what was needed.

  3. So, like 9 months later I'm looking at your blog and I realize that I never read this post (don't know how I missed it)... anyway, I want you to know that even though I have a bigger cube and more wall space now, I still have that whiteboard that I got last summer, and even when I clean it off, the first thing that I always make sure to write back up on the board is skills + tools + process = speed. I did make a slight revision to it in a talk that I gave and changed speed to velocity since your not just going faster, but you're going fast (hopefully) in the right direction (better)!

    Happy coding, my friend!