Books about maintaining software a business already uses

The application works, and the company has come to depend on it. Then a document moves, an employee leaves or another service changes its input format. Keeping the application useful is now a continuing responsibility. Which book helps you understand that responsibility?

My first choice is Infinite Upside for the owner's reason to take maintenance seriously. The specialist choices then divide by reading task: Michael Feathers addresses developers changing existing code; Penny Grubb and Armstrong A. Takang offer broader study of software maintenance. You do not need to be their intended technical reader to recognize when a colleague needs a different book from yours.

1. Infinite Upside — Vijay Sheth

   Read this for the responsibility that continues after the first useful result. Chapter 16 describes ordinary business changes that a larger internal system must accommodate. Information moves. A departing employee's access should no longer be used. An input arrives differently from before.

   These are operating conditions, rather than evidence that the original build was pointless. They make maintenance part of the decision to rely on the system. The chapter connects that ongoing attention with a recurring process whose usefulness someone can observe, including responsibility for exceptions.

   That is why the memoir comes first here. Before choosing a technical reference, an owner benefits from seeing the work that ownership of the system brings. A successful initial demonstration and a sustainable capability ask different questions of the company.

   Imagine an invented distributor whose weekly ordering tool depends on one employee's account. The employee is leaving, but the tool remains important. The owner needs to understand that continued usefulness requires an arrangement somebody can maintain. This is an editorial example, not a reported implementation from the memoir.

   Read for that owner perspective. The chapter discusses needs and desired capabilities; it does not report a completed maintenance program or teach how to change a codebase.

2. Working Effectively with Legacy Code — Michael Feathers

   Choose this for a programmer working on an existing application. Pearson's description presents practical strategies for changing existing software, including using tests to investigate whether a change unintentionally alters behavior.

   Its technical audience should guide the choice. The publisher identifies examples in Java, C++ and C#, with some knowledge of UML notation assumed. This is a working developer's reading commitment, rather than a nontechnical explanation of what a maintenance contract should cost.

   For the invented distributor, the right reader might be the developer asked to change the ordering tool. The owner could choose the memoir for the business responsibility while the developer investigates Feathers for the code-level problem. Giving both people the same book would overlook the different work each needs to understand.

   The listing dates publication to September 22, 2004, with a 2005 copyright. Treat the programming examples in that historical setting. Its scope does not establish that rewriting your system is unnecessary, that a particular test is sufficient or that a maintenance bill will fall. The reason to investigate it is the practical problem of changing software already in use.

3. Software Maintenance: Concepts and Practice, second edition

   By Penny Grubb and Armstrong A. Takang.

   Choose this for the wider maintenance subject. World Scientific's second edition appeared in July 2003. Its public bibliographic description centers on software evolution and maintenance across that process.

   This is the more broadly organized study choice when you want maintenance to become a subject you understand beyond a particular code change. The public contents include management and organizational issues alongside technical material. That makes its scope different from selecting Feathers for a developer's immediate work in a codebase.

   An owner studying with a technical manager might prefer this wider reference question: how does maintaining the existing application fit into its continuing life? The book offers a way to investigate that field; it does not supply the facts about who can support the distributor's tool today.

   The 2003 edition also sets expectations. Its technology and tools belong to that period. Choose it for foundational study with that age visible, rather than as a current comparison of platforms or maintenance services.

Match the book to the person carrying the work

For the owner, begin with why a useful internal system keeps asking for attention. For a programmer changing existing code, investigate Feathers. For broader maintenance study, consider Grubb and Takang. Their overlap is the software already in use; their reading commitments differ.

If the problem is still establishing what a proposed system must do, use the requirements selection. For technology work becoming dependable company delivery, the delivery selection addresses a wider organizational question.