I am an experienced software development manager, project manager and CTO focused on hard problems in software development and maintenance, software quality and security. For the last 15 years I have been managing teams building electronic trading platforms for stock exchanges and investment banks around the world. My special interest is how small teams can be most effective at building real software: high-quality, secure systems at the extreme limits of reliability, performance, and adaptability. Jim is a DZone MVB and is not an employee of DZone and has posted 99 posts at DZone. You can read more from them at their website. View Full User Profile
Given that most of us will spend most of our careers maintaining and
supporting software and not building something new from scratch, there
is a surprising and disappointing lack of useful information on software
maintenance, on the problems that we all face in software maintenance.
I’ve tried to put together here an index to useful books, articles and
blog posts and white papers on software maintenance.
Last updated: 2011-July-12
Maintenance Blog Posts
Jeff Atwood’s The Noble Art of Maintenance Programming
is a thoughtful post on how maintenance programmers are unjustifiably
unappreciated: how maintenance is much harder and more important than
most people, even the people doing the work, understand.
In Sustained engineering Idiocy,
Microsoft’s Eric Brechner explores how to organize your maintenance
team, and the pros and cons of juggling maintenance and support
responsibilities with new development work. Although some of his writing
is internally Microsoft-focused, his blog is worth following for
general good ideas on software development management and maintenance.
Greg Jorgensen, the Typical Programmer, shares a positive perspective on The Joys of Maintenance Programming, describing how maintenance programming can be a satisfying and successful career choice.
Steve Shaw at Intelliware wrote a short paper on his team's experience following Agile methods in software maintenance;
what practices worked (short iterations, testing, prioritization,
common code ownership) and what didn't (pairing, stories and story
cards, stand-ups, metaphor).
The Good Books
There are some excellent books and other resources on writing and maintaining code. Starting with Code Complete 2 by Steve McConnell. The definitive book on how to write good code, maintain it and debug it.
code means different things to different people. For some programmers,
legacy code is code is any code that they didn’t write. For others, it
is code that stills runs on abandoned or out-of-date platforms and
technologies. But everyone agrees that it is code that is difficult to
understand, difficult to support and difficult to change. And in
maintenance you are going to spend a lot of time dealing with it. Working Effectively with Legacy Code
by Michael Feathers lays out how to get a legacy code base under
control, and the steps on how to make changes safely and properly.
The Passionate Programmer
by Chad Fowler offers some good advice to programmers (and managers)
looking for meaning in software development and maintenance.
More on Legacy Code
are also a couple of good online presentations from the smart people at
ThoughtWorks on how they have dealt with legacy code problems. One
presentation by Matt Simons and Jonny LeRoy
covers how to get a handle on existing code, mapping the code and
identifying risk areas, creating dashboards to visualize the state of
the code base using open source tools like Panopticode and Codecity (which offers a cool 3D cityscape view of your code, making metrics fun for everyone), or Sonar
(actually, they didn’t mention Sonar, but it’s another good source
management dashboard). Then they outline different strategies for
incrementally re-writing large applications, emphasizing Martin Fowler’s
Strangler pattern, and how they have applied these ideas to different customer problems.
Another good presentation from Josh Graham at ThoughtWorks on Brownfield Software
walks through an interesting case study where his team came in to help
with a major overhaul of a large, 10-year-old core business system.
a foundational discipline for maintenance – Martin Fowler put a name
and a disciplined structure to the work that we all do, or should do,
when changing code. Seriously, is there anybody who hasn’t read this
book by now, who doesn’t follow some/most of these ideas in maintaining
Debug It! by
Paul Butcher is a narrowly-focused but useful book, about debugging,
problem-solving techniques, handling bugs, and writing code that is easy
to debug. Especially useful for programmers new to maintenance.
There are some great books on managing software development projects, like Steve McConnell's Rapid Development, and Scott Berkun's Making Things Happen. Many of the ideas in these books will help you in managing software maintenance work.
There are only a couple of books that take on managing software maintenance:
Alain April and some other researchers have put together a Software Maintenance Maturity Model,
a la the CMMI. It's obviously process-heavy and bureaucratic, but it
does a thorough job of mapping out all of the work involved in software
maintenance, and it's interesting in an abstract way.
managing a large enterprise maintenance team and working through a lot
of structure and standards, then Thomas Pigoski's Practical Software Maintenance
offers advice based on real experience - the author ran a large
maintenance organization for the US Navy, and is now the CEO of TechSoft,
an outsourcing firm that handles maintenance for other companies.
Unfortunately this book is out of date (published 1996) and predates
modern Agile and Lean methods and practices and new technologies.
Pigoski also wrote the chapter on software maintenance in the IEEE SWEBOK, an academic definition of software engineering.
Another academic book which I can't recommend for practitioners is Software Maintenance: Concepts and Practice
by Penny Grubb and Armstrong Takang. If you're already working in
maintenance, you won't find anything here that you don't already know or
that will change the way that you think or work. It's more of an
introductory text for undergrad Comp Sci courses.
Studies, Statistics and Lies
Dr. Jussi Koskinen, a Comp Sci professor in Finland, maintains a useful summary of software maintenance cost data and sources.
I want any kind of data on software development or software
maintenance, the first person that I go to is Capers Jones. His book on Estimating Software Costs
was last updated in 2007, and includes extensive data on software cost
information and statistics and trends on software maintenance and
support. Or you can read Applied Software Measurement or Software Engineering Best Practices
- all of these books are built on the same comprehensive research. You
can spend days going through this stuff - I have, and I keep finding
Some of his research specific to software maintenance and legacy software is captured in a white paper called Geriatric Issues of Aging Software.
A couple of different versions of this paper can be found on the web,
the best of them is found in CrossTalk: The Journal of Defense Software
Engineering dated December 2007.
One of the foundational studies on software maintenance is more than 30 years old now: a study of software maintenance at 487 IT organizations
by Lientz and Swanson. It's widely referenced, and still the most
comprehensive analysis of what work goes into maintenance (or at least
what did in 1978). A newer (1998), smaller, but still interesting study by Janice Singer talks a lot about bugs and bug tracking, and how unimportant documentation actually is in maintenance.
Building, releasing and deploying code
And there are some good books on building, deploying and delivering code, on Continuous Integration and source code management, all of which are important in maintaining and releasing code. The best of these is the new book on Continuous Delivery by
Jez Humble and David Farley. It’s full of practical advice on how to
improve your code build and deployment practices; and on data migration
and test automation strategies; and more far-out ideas on how far-out
you can push automation in build and deployment.
Lean and Kanban and Maintenance
If you are interested in how Lean Manufacturing and Kanban ideas can be applied to software maintenance, and quite a few people are, a place to start is the XIT case study
which explains how Kanban was first used to speed up and simplify
management of maintenance work by a small cross-application team at
Microsoft. I think there’s too much hype and religious debate around
what is a conceptually simple idea (visualizing and limiting work in
progress), but Kanban offers a natural framework for getting control
over maintenance and support work, helping to deal with interruptions
and constantly changing priorities.
Operations and DevOps
need to understand how their code runs in production, need to care
about and know about operations and performance and how to handle
failures. This becomes even more important, more necessary, in
maintenance: it’s a reality that maintenance teams face all day each
day, rather than just another set of requirements for the future. Some
smart people in the DevOps
community are trying to come up with a more collaborative and agile way
for operations and development teams to work together. Most of their
work focuses on large-scale Web Operations
problems and operations toolchains, but there is some good thinking
here on how to improve deployment, on metrics and monitoring, and on
dealing with architectural problems like scaling, and failure handling
While helpful, most of the thinking in DevOps is
being done from the operations point of view (maybe it should be called
OpsDev instead…). The best book on operations problems by and for
developers and software architects is still Release It!
by Michael Nygard. He makes clear how important it is to, and how to,
design scalable and resilient software architectures, and how and why to
build an operations view into your system.
If you are working
with Ops (especially in an enterprise shop) you should understand the
basics of ITIL, and the cost and risks of change in production, and how
to to get a production system under control. The best place to start on
this is The Visible Ops Handbook, a tiny primer on intelligent IT change management.
Dealing with Data
One of the biggest problems in software maintenance is handling changes to data and data models. Scott Ambler's book Refactoring Databases walks through an incremental approach to making structural changes to database models, and how to test and deploy these changes.
Secure Software Maintenance
with security risks for legacy systems is another wormcan, and you're
not going to find a lot of information to help you understand where to
start, other than this set of white papers on legacy systems and COTS from Cigital, available on the US Department of Homeland Security’s Build Security In portal.
Forums and Discussion Groups
I can't find any discussion groups on software maintenance or sustaining engineering.
has some interesting threads on maintenance and refactoring and other
maintenance problems. It’s one of the mainstay resources for developers
looking for advice on maintenance issues or anything else for that
would like to hear from people about any other useful books, blogs,
articles or forums that focus on software maintenance and support
problems - what resources you trust, what you have found helpful.
Published at DZone with permission of Jim Bird, author and DZone MVB. (source)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)