I recently read an interesting research paper titled Metrics and Laws of Software Evolution – The Nineties View by Lehman et al in the 1997 proceedings of the Software Metrics Symposium that discusses eight laws of software evolution. One set of graphs within the paper jumped out at me: they show the incremental growth of two systems over a series of releases. The graphs shared a common pattern: releases with higher than average incremental growth tended to alternate with one or more releases with lower than average growth. What are the implications of this commonly observed behavior for developing and using software? How can we use this pattern to our advantage? Read on to see my answers to these questions.
Posts Tagged ‘maintenance’
If you are a software developer and have not maintained operational applications with real users hammering away at it, then you are missing some important lessons. You might not fully appreciate the operational challenges facing the maintenance and support team, particularly when the software in question is suffering in the areas of reliability, performance, or [...]
The maintenance team for a typical enterprise business application must make ongoing changes to the application. In the effort to fix defects, revise existing functionality, and add enhancements, little thought may be given to the process by which these changes are deployed from development through to testing and then the production environment. However, this process [...]
- Add Comment
- No Comments
- Permalink
My previous article talked about the importance of maintainable software. In this article I provide some recommendations on how to create software that is maintainable – easy to change with minimal risk and impact. What are the specific challenges facing developers maintaining software? They probably did not originally develop the software, and may not even [...]
- Add Comment
- No Comments
- Permalink
I’ve heard that a typical enterprise business application spends at least 80% of its time in maintenance (versus development). I don’t have a reference for this, but if you assume that an application takes one year to build, and is in use for four years, then you arrive at the 80% figure. Why does software [...]
