The Triple Stress of the Software Maintainer

First, let's face it, every programmer is a software maintainer. By maintaining I mean not only fixing bugs or adapting the software to changing environment, but also in general adapting it to new needs, new use-cases.

When you create a software module, it stays around. It is not like a bouquet of flowers you put together and sell somebody. Because software can be duplicated for free, you won't lose it when you give it to someone else. THEREFORE much of software development is just about modifying, adapting, maintaining, improving existing code.

Now let's focus on maintenance as it's more traditionally understood. There's a bug-report. The software does something we don't like. You are tasked to fix it, by yourself or someone else.  What happens? A Three-Fold Stress ensues.

The threefold stress is not caused by the knowledge that the bug exists, but by the fact that you need to fix it. Why is  bug-fixing stressful, more so than the fun task of programming "from scratch"?


The first stress is because you don't know what is causing the bug. Where is the "bug" located? Well typically it's not located in any SINGLE place, but is caused by the interaction of multiple parts of the system.  It's not like "finding a cog in a machine".  It's more about understanding why a subset of modules don't work together as intended. It can take a lot of work finding out "where" the bug is. The first stress comes from the fact that at the outset you have no way of knowing how long it's going to take to locate the cause of the problem.

The second stress comes from the fact that you also know, you don't know how much time it will take to modify the system even after you have understood the cause. You may need to  rewrite whole subsystems to get it working the way it needs to. Again doing the rewrite is actually fun. The stress comes from the fact that you have no good way of knowing how long its going to take. This is partially because once you start modifying the system, you typically break something else, which then needs to be fixed also, which ...  you get my point.

The third stress comes from the fact that even when  you've finished with the maintenance project, you can't be 100% sure whether you've actually created more problems that you've solved.

So there you have it. There are books to read about how to make your software very maintainable. But often you need to work with software created by others, or by yourself before you read those books, with no clear documentation attached.

Perhaps the best cure for this three-fold stress is the simplest: Realize the uncertainty you face, and live with it. Take a Zen.

© 2013 Panu Viljamaa