Code inflation – why expanding software is a problem

Code inflation is a major problem in software development: software in use tends to grow until it becomes unmaintainable. Read here how you can recognize and prevent software inflation.

Defining code inflation

Software researcher Gerald Holzmann defined ‘code inflation’ as the phenomenon that ‘software tends to grow over time, whether or not there’s a need for it’. In this paper he analyzed an extreme example: the program ‘true’ that has been part of Unix since 1979. The command true is used within other scripts and should always return the value ‘true’. The program started of in 1979 as an empty file: a file with zero commands in it cannot fail and thus returns ‘true’. Holzmann and other experts working on Unix expected the program to stay stable. It is the shortest possible implementation and it works perfectly, so what could be improved? The phenomenon of code inflation however kicked in: there is always someone willing to make an addition to something that is already working fine. The tragedy of code inflation is that even if thousands of experts agree that no addition is needed, programs can still grow based on the effort of one dissenting developer. So it happened. In 1983 and 1984 the program grew because someone felt that the program needed a copyright statement. Later on more code was added, without making the program functionally different.

The same phenomenon also occurs at a larger scale: programs tends to grow over time, because there is always one developer with ideas for new functions. A common estimate for the average growth rate is 5-20% per year. This growth leads to additional costs for many companies, as the additional lines of code have to be maintained: every time the programming languages change or new security risks are discovered, all lines of code have to be checked and potentially updated. Even worse, programs can grow to become so large that they become too complicated for one developer to understand. The system becomes an unmaintainable ‘legacy’ system that needs to be replaced or is encapsulated and covered in work-arounds.

Spring cleaning software

Just like code inflation is an old problem, the solution is also old: try to make program that do one thing only and one thing well. One of the first articles explaining this idea is ‘Cat –v considered harmful’. The author of the paper was one of the experts who realized that unix utilities like cat are most valuable if they remain small and simple: advanced needs should be met by combining multiple tools that each do one aspect well. So why does this not happen often enough? The reason is that software development is a social activity: for additional developers it is easy to make a small addition. Removing features is more difficult, as one never knows which features are truly never used. It is also difficult to know whether features are truly redundant so it is risky for developers to remove features without first consulting the whole organization. Many organizations would benefit from an annual ‘spring cleaning’ action: to measure once a year the growth of systems, determine the value of all features and throw away features that are no longer useful, and spin out features that have value but do not belong in the system.