Why Rework in Agile Projects Is Key to Success

My wife and I repainted our house over the summer. We went through the normal process of painting a house, or a room for that matter; We looked at other houses, looked at magazines and talked to some friends. Finally we went to the paint store, looked at some more colors and ended up buying a couple sample containers. We took them home, cleaned up the area where we would do the samples and applied them.

The first three two we bought were just ugly – super, super ugly. The funny part is that we really thought one of the colors was the color that we would paint the house. My son ended up calling it “army green” and army green it was.

“Nope, that’s not doing it for me” said my wife.

Yesssss! I said to myself with a small fist-pump.

Round three and back to the paint store. The people knew us by name now.

“Still can’t find the right color?” the man behind the counter asked. I smiled and kept my mouth shut.

“We’re close!” exclaimed my wife, “I think we need to go with Mustang and that other one we discarded earlier” – two colors that I hated, or so I thought. I recall in my head the colors we’ve gone through so far.

• Army green
• Vomit green
• Baby bottom brown
• Some other ugly brown

With samples in hand, we left and put it up on the house. The color was found. It was Mustang. Yup, the color of my house is Mustang, and I actually like it.

Now you’re probably asking yourself why this story is on my blog, and what it has to do with software and throw away code. For that, I will show you an example of painting the house but with the mindset that is so prevalent in companies today, the mindset of getting it right the first time when it comes to building software.

Using this approach would look something like this:

• Select the paint color (remember you can only pick one, so we go with army green)
• Purchase the supplies and materials ($1,000 in our case)
• Schedule and pay the crew to paint the house ($5,000)
• Review the results

Now, if we don’t like the color, we do it again, and spend another $6,000 for the privilege to do so. We would repeat this process a total of six times, unless we quit first and said enough is enough, and we’d live with the color on the house that we didn’t like due to lack of funds, frustration, or most likely, both. This could easily cost us $36,000.

Why then would we ever use this approach when painting a house? We wouldn’t (maybe you would), but companies use this approach every day in order to get software projects delivered. Why?

One advantage to “getting it right the first time” is that you don’t have rework. Everyone knows this is a lie though. We end up building our systems by component, getting everything to code-complete or some level of done and move onto the next component. Each component is, in theory, done, however when we go to put all the pieces together, nothing works and we have painful stabilization and integration phases. Just as my wife and I could not pick the right color the first time, it’s nearly impossible to write code “right” the first time.

Another issue with getting it right the first time is that, in the end, things cost more. Why? Because you have to debug the code to figure out what issues were introduced by late integration. Just as painting and repainting our house would cost money for materials and labor, so does software.

Then, we have time. It took my wife and me approximately one month to have the house painted. This timeframe included the “hey, we need to paint the house” moment over the summer through the painters coming back to do some touchup work a week after they finished the job. The house was officially Mustang after three weeks, but I don’t want to cheat – it was “done” according to our definition of done after a month. Now, if we had tried to get it right the first time, the whole exercise would have likely taken, at best, eight weeks – double what it took – and most likely 12-14 weeks. Not bad, only three times as long.

At this point you’re probably saying to yourself “ok, ok, I get it – don’t paint your house without picking colors first!” but I’m not done.

Remember in the story where I said my wife and I probably would have quit, either due to our budget being vaporized, frustration or both? Well, when you relate this to software, it’s the same as shipping to your customers knowing it’s not the best work, knowing it’s not all going to meet their needs. You will probably feel bad about it, but what can you do? The time and the budget were expended. This is a crappy feeling; about as crappy as looking at a house that is “baby poo brown” or “army green” every day for the next 10 years.

So what can you do about it?

First, embrace throw-away code. Yup, there, I said it, throw-away code. Think of throw-away code as the paint samples that my wife and I purchased. That was, in essence, throw-away paint. We spent money on that paint realizing we would probably not like each sample, but what that enabled us to do is reduce our overall risk of having the project run over budget, over time, or both. In the beginning we had no idea what we wanted, but through utilizing the throw-away code mindset that we both have (she’s a program manager too, our poor kids), we got the project done in a timely fashion and it was actually under budget.

This means that you’ll use the XP practice known as refactoring. Refactoring in a nutshell is changing the code without changing the intent of the code. Thinking about it as working on a car – you go work on the engine, tune it up, make it go faster, but on the surface the car looks the same. This is the same thing. Refactoring means you will throw code away, and that’s OK, because what you gain is a deeper understanding of the system.