Design Never Stops
When was the last time you wrote a new class?
I left my management position at a highly toxic work environment in June this year to start at a highly reputable software shop as a senior support developer. Support is an entirely different discipline to project development: its primary point of involvement is after a piece of software has shipped. Often it involves working with technologies that aren’t necessarily on the bleeding edge and – more often than not – the most common task is one of maintenance and bug-fixing rather than enhancement and evolution.
Typically when developers are in a maintenance role – or even seconded to a maintenance project – they don’t find themselves adding new classes very often at all. They’ll add new methods to existing classes or refactor old methods because the design phase “is over”. I’ve worked in various types of support development roles over the years and it’s an unfortunate fact of life that in most cases once a product has shipped, the design phase is considered to have been completed way back in the early stages of the application’s life cycle. The client has spent the budget they had alloted to the solution, there are other solutions that need to be built or there just isn’t time to continually revisit and refresh the application.
So the maintenance phase becomes less about keeping the solution up-to-date and supportable and more about functional preservation and ad-hoc enhancement. Michael Feathers (author of “Working Effectively with Legacy Code“) asserts that design is a continuous process: never completed. You should always be creating new functions and new classes.
I’m supporting (among other things) a VB6 applicationright now that uses a bit of Classic ASP thrown in for good measure. I am actually enjoying this because I can identify lots of areas where the design can be evolved and improved. The hard part in these situations is convincing the client that it’s a worthwhile investment. More often than not the general response is “Well, it’s working just fine as it is right now so I don’t really see any need to fix something that isn’t broken”.
As an application grows, evolves or ages the fear of making changes and especially deploying those changes into a production environment grows with it. This situation is exacerbated by not having any unit tests but the crux of the problem really comes down to two areas: cost and fear of change.
Fear of change is a valid concern in some respects. If you haven’t updated your application for some time or it’s a business-critical system, you’d be justifiably concerned about introducing any unnecessary risk to your systems. However the flip-side to this argument is that you would also – as a responsible business – want to ensure that the stability, availability and continuity of your applications was as assured as possible and a good way to ensuring this is to release regularly and often. The metaphor of a medical or dental check-up comes to mind where prevention is the best cure. Leaving problems untreated until they’re real hazards is both costly and risky when regular maintenance and selective modernisation would have likely avoided these situations altogether.
Investing the time and relatively low amounts of money in the ongoing design (i.e. paying back your software mortgage) is good business practice and better value for money than leaving your application neglected and unloved until age and technology advancements mean more serious problems arise.
