"Software Maintenance: Concepts and Practice"
by Penny Grubb and Armstrong A Takang
Link: http://www.amazon.co.uk/Software-Maintenance-Concepts-Penny-Grubb/dp/981238426X/
Reading history and reviews
Finished on 13th July 2009
An extremely interesting read, though possibly a bit over-academic and dry for many (it's essentially a text book). The authors clearly articulate many of the factors that I - as someone who worked in software maintenance for some years - often found myself struggling with. It was also interesting to read this soon after How Buildings Learn and see many of the same concerns voiced for software as had been for buildings.
One of the problems with maintenance work has been its poor image in relation to other types of software development activities - that it is boring, of low importance, and requires less technical expertise than more "exciting" work. However the authors contend that maintenance activities are vital if software is to remain viable after it is developed. They identify four categories of maintenance activity: corrective changes (fixing bugs in the design or implementation), adaptive changes (updating software so that it can operate in a new environment), perfective changes (adding new features or functionality) and preventative changes (making changes now in order to prevent problems or deteriotation in the future).
There is some discussion about how these maintenance activities are actually undertaken. A major part of the process boils down to a reverse engineering or "code comprehension" problem: the maintenance programmer must first understand what the software does (and how it does it) before being able to make stable changes. Due to the "malleable" nature of software, each of these activities requires both technical skill and careful management to avoid introducing new problems elsewhere in the system (so-called "ripple effects"). Things like documentation and code comments can help, as long as they are accurate, and other tools and techniques are also examined.
I don't imagine that most of this will be news to people who have worked at the sharp end of maintenance, however the issues are presented with a degree of clarity that helped me reconsider my own experiences. Also there is a recognition that management of software maintenance is indeed a management problem, that is to say that managers must recognise the importance of maintenance activities and allocate sufficient resources while also supporting their maintenance staff - because ultimately software needs to be maintained if it is to remain useful and effective.