Do Over or Do Not: Crucial Decisions in Software Re-development

We’ve all had experience creating something new.  It can be daunting, and your instincts tell you to sit down and plan out everything you’re going to do.  Often, though, you come to find that what you have created works, but isn’t really sufficient.  It could be because the specifications have changed, or that people interact with your work in a way you didn’t expect, or simply that you didn’t execute it in the best way possible.  Whatever the reason, the end result is the same – you don’t have exactly what you need.

The core of this problem is complexity.  As a task becomes more complex, it becomes harder to predict the output based solely on the inputs.  Software development is so complex that it is impossible to predict the outcome.  Despite all the planning and designing, the plan is going to change.  Of course, this isn’t news to anyone; it’s a common occurrence, and not only in software.  Life is full of complex problems with complex solutions.  So if making software is a complex process, and everyone understands that complex processes are impossible to predict, why is so much time spent trying to plan and design software?

There are many reasons for an emphasis on planning and design, but the primary cause is a resistance to redo completed work.  Teams don’t want to rework tasks or features because it doesn’t feel like progress, and if a team is not progressing, it’s not succeeding.  To avoid having to redo a task, a team will try to predict exactly what is needed for that task.  But as we’ve all experienced, this prediction is impossible.  Your best effort will only get you close.  A team is better off starting their work right away.  Later, they can take any time they would have used for design to iterate on their initial work.  This time spent on rework will prove to be more efficient because it is happening when the team is more knowledgeable about the task.  The beginning is your least knowledgeable point, so it is the worst time to make plans or designs.

One of our latest projects, Big Win Blackjack, has been a fine example of the value of reworking.  Big Win Blackjack began life as Blackjack Cheater and has gone through several revisions.  Many times during that process we were faced with the choice of reworking a feature to improve it or moving on to the next feature.  For example, our sponsored casino had problems with card layout.  They were not show-stopping issues, but they looked sloppy. To fix these problems, we would have to rewrite the card layout logic.  That’s a scary sounding task, and it meant delaying new features.  But in the end, the game is better off with nicer card layout, and no amount of time spent planning would have come up with a better solution.  In every discussion someone raised the concern that reworking would take too long.  You see, our Blackjack projects were taking longer than we had anticipated, and we wanted to release a new version.  But every time we decided to rework the feature, the result was worth the time spent because we were able to make improvements we never would have anticipated.

I’m not trying to suggest that reworking a feature is always the best option; a decision has to be made for each feature.  But I do believe that the cost of reworking something is almost always overestimated, and that the cost of planning is likewise underestimated.  Don’t be afraid to jump in and start working.  Use your planning time to improve what you’ve done; you’ll most likely know better what needs to be done.