Refound your software

I've experienced first hand how making any changes to existing in use software can be a nightmare. Complaints from the business that each new change seems to take longer, cost more, and lead to new bugs are well justified. Why is this? Well scrum has taught me all about technical debt, and how this leads to increasing problems as the life of the software lengthens. So obviously, next time I'll do it better!

But for now, for all those companies with existing software suffering from technical debt, what about them? Well, I like the concept of "refounding" or rennovating them. So don't throw the software away and start over. This is much to risky, costly, and time consuming. Instead, whenever a change needs to be made to the software use the following steps to refound safely:

- create tests (most likely not unit tests) for the code that will be changed and make sure that they run (green).

- refactor the code to improve the structure and allow unit test to be created (enabling mocking is an important one here). Do this is small steps and make sure that after each step all tests as still green.

- then make the desired changes that triggered all this (be it a bug fix or a new feature etc). Of course, use test driven development here, and again make sure all tests stay green during the process.

This way, the software is improved slowly step by step, but only in the areas a change was desired anyway. So the entire software is not refounded, only the parts driven by business value. Most likely, 80% of all the changes will focus on 20% of the code. So refounding is a low risk, driven by business values approach to improving existing software. I think this will go a long way to lengthening the life span of existing software.