The Argument for Architecture: Refactoring your Legacy Solution
Today, the typical ISV’s development department is facing huge challenges.
In addition to the traditional ‘joys’ of having the sales and marketing teams driving large feature sets on ever tightening deadlines, most of these development departments are being force to deal with both legacy and emerging products simultaneously.
Universally, folks are working long hard hours just to keep up.
Unfortunately, this often leads to a ‘just get it done’ mentality.
In this kind of environment focusing time and effort on software architecture is often viewed as a luxury that cannot be afforded.
I would like to pretend that I have not felt that temptation myself; however, up until recently I worked for a large ISV. We faced all those pressures. The temptation to just get it done is huge! Unfortunately, this is exactly the wrong instinct.
In most circumstances, a significant part of the problem faced by ISV development departments today is the architectural sins of the past. Software architecture is a developing discipline. Most legacy systems that ISVs are maintaining today and sadly some of the current systems do not have strong architectural underpinnings. Their architecture was not planned and executed but rather evolved as different development projects were stitched together. These ‘accidental architectures’ are often cumbersome. They can be difficult to maintain and are often very time consuming to enhance by adding new features and functions.
These systems are often viewed as lost causes. There is a belief that nothing can be done about the problem. This is almost always not the case. Refactoring components of an ‘architecturally challenged’ system can often be an effective strategy for reducing cost of maintenance and incremental development on that product.
While providing a complete guide to this kind of effort is beyond the scope of this article, there are a few simple thoughts to get started with:
Before beginning it is important to take a hard look at your existing system. In most cases not everything is broken. It is usually easy to identify a small number of areas of the architecture that are causing significant pain. It is often beneficial to examine trouble tickets to see which areas are most often listed as problematic. My favorite approach is to the check source code control/change control logs to see which pieces of code is being changed the most often. This is almost always your best indicator of where the trouble is.
- Prove it is worth the effort
Once the problems have been identified, I would strongly suggest doing a small amount of analysis. Spend some time looking at the effected area. Try to estimate the amount of pain the structural defect is causing and if possible estimate the cost to your organization. Develop several refactoring approaches. Determine the cost associated with each approach. In most cases it should be possible to demonstrate the return on the refactoring investment. My personal rule of thumb is that if the refactoring project does not provide a return on the investment in 12 months, the problems stays broken.
If you get nothing else from reading this article, you should at least feel that you are not alone. Many folks in many organizations face this problem. I am often surprised how little it is talked about. (Is strongly suspecting it this has to do with our tendency as developers to focus on the new ‘shiny’ stuff).
Despite of this lack of general dialog I would recommend one great resource on this subject. There is an emerging line of thought among architectural illuminati known as ‘Anti Patterns’. The basic thinking is that ‘Patterns’ are common software needs or scenarios that have been documented and have standard solutions. Anti Patterns are commonly occurring defects/problems that get built into software. These Anti Patterns have standard refactoring approaches. There is an excellent book on the subject (Anti Patterns: Refactoring Software, Architectures and Projects in Crisis by William H. Brown, Raphael C. Malveau, Hays W. McCormic III, Thomas J. Mowbray (publisher John Wiley & Sons, Inc) ISBN 0-471-19713-0)
Our focus on ‘Just Get it Done’ leads to doing much more work over the long haul. While it is not prudent to try to solve every problem, it is always worth while to spend a small amount of time to examine a system looking for areas that are refactoring candidates. A small investment in refactoring can often lead to a decrease in defects, increases in productivity and most importantly an increase in customer satisfaction.
