What my Xbox taught me about agile

I have spent a large portion of my career trying to develop new code faster than before. This sounded like a really easy goal to accomplish. I guess my original plan was always flawed. The more I tried to develop fast, the more I needed to fix bugs. When something from 6 months past becomes a problem, things would come to a really frustrating halt.

The first time I played Forza Motorsport 2 on my Xbox 360, I drove as fast as I could crashing into every wall. This caused my car to get turned around backwards and start driving in the wrong direction. The game seemed impossible. Then I tried something crazy. I slowed down!!! What slow down in a video game. I did and do you know what happened? My time was significantly better. Eventually I was able get better control of the car at higher speeds. Still I needed to control how fast I drove, you can't go through a hair pin turn at full speed.

Why am I talking about video games?? Well we can learn a lot about software development from this same problem. If you are constantly pushing out as much code regardless of the quality, you will hit walls. You will need to stop what you are doing and rework code. The addition of new features will take longer because things are not stable or testable. Fixing defects requires hours of debugging sessions.

I realize no one wants to create a mess, it just happens. The faster you go the more technical debt you build up. Does your manager have sleepless nights about the debt you are building? I doubt it, this debt is usually very hidden. It only resurfaces in defects or the inability to make changes to existing code. I can assure you that you will spend more time fixing the mess then it took to create it.

One of my favorite techniques for delivering quality code is automated tests. Unit testing are the safety net that we need to prove what we are doing. If you are practicing TDD you are proving that your intentions are realized in code properly. Think back to before you had these tools. Has anyone wasted a day looking for a solution to a boolean expression of (variable = false). Yes it is an assignment not a boolean expression and it will always come back true. Unit testing is important.

So why FasterSlowerBetter? I think it says a lot about how I want to develop software. I want to be faster, but experience has taught me how to get my goal accomplished. Going slower and having better deliverables sets you up for a more productive future.