Most developers will tell you that the code they work on is a mess. When this happens, Joel Spolsky has elegantly explained on his blog why rewriting a working software is almost always a bad idea. Why does the software get in the mess in the first place? Most of the time, it is because the software has expired.
There is one key characteristic of software expiry, which merits special attention:
- Software expiry is a continuous process, not an instantaneous one: Unlike milk or eggs which expire on a certain date, software expiry is a continuous process – it expires slowly, but continuously. Certain modules of your software may expire early than the others and architecture of your software may become obsolete over time, but these events don’t happen on a single date – they typically happen slowly over a period of time.
But why does the software expire? The main reasons are below:
- Requirements change: The most important reason for software expiry is that the requirements change over time. Say for example, when you first wrote that web application, you were expecting 100K page views per month. But now, you are getting over a million page-views, and you may need to change your architecture, or optimize some modules that initially didn’t need any optimization.
- Technologies change: Hardware as well as software technologies change over time. May be, when you wrote the software, hadoop and/or pig were not available, and so you wrote your own custom code for distributed computing, but now it causing you a ton of maintenance overhead. At some point, it may be cheaper to move to hadoop and/or pig and reduce the ongoing maintenance overhead.
- People change: A lot of software in this world is poorly documented, or even worse, has misguiding documentation. As people working on the software change, it is very likely that the new developers are not fully aware of all the assumptions behind certain design/implementation decisions. Add to it the fact that software is easier to write than to read, the entire software project degrades over time.
So, how does one cope with this and extend the expiry date? A few key principles need to be followed:
- Accept that the software expires over time: The most important thing to extend the expiry date is to accept that the software expires and watch out for which modules or architecture choices are expiring. Key indicators are the number of bugs found per module, the time it takes to implement a simple feature, etc.
- Work on extending the expiry date continuously: You need to assign some percentage of development time to code refactoring, documentation, rewriting some modules that have lots of bugs, etc. The exact percentage depends on what stage your software project is, but it is certainly non-zero unless this is Day One of your project.
- Write self documenting code: Self documenting code is the best way to make sure that the documentation and code do not get out of sync. Make sure that you use variable and method names that are self-descriptive, have plenty of useful comments, etc.
