Trash Can Part 2

In part 1 I talked about using the trash can frequently as you build new products. Use it as a way to build on what you learned the first or second time around, as you explored the solution space, to build something better. Better organized, faster, cleaner, DRY-er.

For part 2 I want to turn attention to a situation most teams face — maintaining an existing product. Existing products that sell well for an organization tend to move more in to maintenance mode than in to feature development mode. Security vulnerabilities, changes in underlying operating systems, end of life for drivers and so on become the daily routine of maintaining a product.

But, the longer this goes on, the more different people touch the code. The more the code gets jumbled up and cohesive. The harder it becomes to maintain. I learned in my early days about the importance of documentation and writing clear and easily understandable code. That was the theory. I am guilty of not following it and I suspect most people are the same.

At some point in time a team has to say enough is enough. The law of diminishing returns says it is time to trash the whole thing and start over. The dreaded re-write.

But is it really dreaded? Can something newer, faster and more modern emerge to take over where the old served so well? Of course it can.

I like to think of a re-write as a massive catch up on clearing technical debt. Convincing the business that a re-write is not only necessary but desirable is something that engineering has to do. It has to communicate to the product owner that the long and medium term benefits outweigh the sort term inconvenience. If you are in a position where maintaining an existing product is so complex there may even be a more obvious short term benefit.

Here is what you are likely to get:

  • A fully automated CI system
  • A fully automated test suite
  • Faster product based on newer technologies
  • A platform that allows for faster future iterations
  • An updated user interface
  • An opportunity to assess clearly with customers their use cases

If you find yourself in a position where most requirements are coming from specific customer feature requests, regression testing adds weeks to schedules and test teams outnumber developers then perhaps you are a reasonable candidate for a re-write. If you find yourself with a business plan that calls for an increase in development and test headcount by 50% and an uninspiring roadmap — perhaps you are a candidate for a re-write.

Challenge yourself — make date king and put a stake in the ground. Ask the team — can we get a re-write out in 6 months. What does that mean to the business.

Just dont forget to tell the business to expect to have to do it again 7 to 10 years from now.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.