The Big Re-write
It happens to most applications. Eventually, the time required to implement new functionality becomes so long that it can’t be justified in terms of cost. This leaves the customer with two options:
- Put the application into RTB (Run The Bank) mode. i.e. keep the existing functionality but don’t add any more. “The new things I wanted weren’t that important anyway.â€
- Keep the application in RTB mode whilst embarking on The Big Re-write. “I need more than I have so I suppose we should start on Version 2.0.â€
In either case we fail to deliver what the customer actually wants. Even worse, The Engineering Trade points out that embarking on The Big Re-write is selling the present to buy the future. Considering that the customer only wanted a small addition in functionality this is terrible, they’ve already waited for the application to be written once.
Clearly it’s never possible to write an all singing, all dancing application that guessed all directions the customer may choose to go in the first version. However, I can’t help but think that we in IT aren’t good enough at using a few basic rules to avoid The Big Re-write.
Make sure you actually know what the customer wants
Spend time understanding what the customer actually wants. It’s far too easy to assume the customer needs more than they are asking for. There’s a good chance that the most complicated parts of your application are the bits catering for requirements that didn’t exist. By never creating these complications in the first place, the application will last longer.
Write your application with well defined components & interfaces
- Make sure you create well defined interfaces around and within your system. Doing so will allow you swap out the bit that doesn’t work or scale anymore, more easily.
- Understand that the interfaces on these components will change and create a development environment that supports this:
- A team that isn’t scared of change.
- Lot’s of automated tests.
Components, like applications, will have the life-cycle depicted in The Engineering Trade. However, a set of components that pass well defined data between each-other should be easier to replace at a lower cost than replacing the entire application.
Monitor the functionality
As an application gains stronghold with it’s users you’re on a roll. You’ve gained some kudos and want more. Requirements that don’t really fit the application come your way but what the heck. How bad can it get? Stop! If a new requirement doesn’t really belong in the application, find somewhere that it does. Trying to have the most comprehensive application in town won’t work in the long run.
Creating an environment that allows the low cost introduction of new, small applications will benefit all.
Evaluate what you have without bias
Before embarking on the The Big Re-write, stand back and do a proper evaluation of what you have. Try to find ways to separate what appears to be a monolithic application into components and then replace the problematic ones.
It can seem all too easy to re-write an application when you’ve been complaining about it (well the original designers anyway) for so long but the stigma alone shouldn’t be a reason. I’m not convinced that enough of us are prepared to try and properly understand what we already have in-front of us.
Don’t get me wrong, with all the above, re-writes will be necessary and you can’t create hundreds of applications that each service one function, requiring the user to start them all to do their job. However, if applied in right way, these practices minimize the number of re-writes at no functional cost to the customer. Therefore, surely, they must be a good thing.
The opportunity cost involved in “selling the present to buy the future” is not an option IT should present to the customer. It is the job of IT to deliver software that meets this requirement.
