Maintenance Takes So Much Time that We Can't Get Our Development Done!

Tenberry Home

InstantC Home

Our current users comment

InstantC FAQ

Tour of the Software

Purchasing Info

Order on-line

* * *

Shorter schedules!

Fewer bugs!

Master Existing Code!

Reduced Costs!

Works on Your Code!

Augments Microsoft C

Easy Startup

Most managers or project leaders responsible for the maintenance and enhancement of existing applications feel frustration. They know that if they could just get the new version of their program finished, they could solve lots of problems. But responding to those problems can be what prevents the new version from being finished!

Why Is Maintenance Such a Problem?


Most of us are rewarded for putting our programs into production use. The rewards are greatest where there is a large improvement in the work the computer is doing for the user. Similarly, the punishments for not getting new software deployed can be large and painful. On the other hand, the pressures to update an old application can be great: just look at the year 2000 hoopla!

If you're like most of us, your boss remembers when you promised to have the new software ready. He (or she) is not so likely to remember the time spent updating the old application to handle an upgrade in operating system or network software.

In addition to the external (boss, company, market) pressure, most programmers get psychic rewards from seeing our programs put to use, but find fixing bugs and/or making small improvements psychically unrewarding, for a variety of reasons:

  • Lack of control -- maintenance is usually reactive, and isn't conducive to the sort of planning that programmers like.
  • Old technology -- it's less "sexy".
  • Code that someone else wrote.
  • Poorly written code (even if you wrote it in an earlier day!).
  • Start-up time to become familiar with the code (even if you wrote it!).

In short: no fun.

Why Does Maintenance Take So Much Time?


In addition to programmer reluctance, the following specific problems all contribute to the high cost of maintenance:

Unfamiliar Code:
When doing maintenance, the programmer is most often working on unfamiliar code, which s/he either didn't write, or wrote so long ago that s/he doesn't remember it. The code, written in an unfamiliar formatting/indenting style, is actually hard for the programmer to read. Both the unfamiliarity and the reading difficulty make it hard for the programmer to understand the overall structure and design of the program. Since the programmer doesn't have familiarity with the code or design, the coding decisions s/he makes take longer and are more likely to be wrong (buggy) or inappropriate.

Changes made by programmers who are unfamiliar with the code are much more likely to be patches -- small sections of code that deal with the symptoms of an issue, rather than the root causes.

Bad/missing Documentation:
It's rare for an existing system to be well documented. This documentation may be written, but more likely is stored in the head of the original program author: "Go ask Joe, he wrote that." At many organizations, old application documentation simply doesn't exist. Even worse, the documentation may exist, but be out of date and misleading. This missing or bad documentation aggrevates the problems caused by unfamiliar code.

Fragile Code:
Even if a program wasn't fragile to start with, after years of maintenance by unfamiliar programmers, a program becomes fragile. A fragile program is one where there are numerous and undocumented interconnections, so that when an improvement is made in one area, bugs are introduced in other-- sometimes seemingly unrelated-- areas of the program. Programs become increasing fragile as they are "patched" over time. Each patch weakens the structure of the program, thereby increasing the interconnections and making it harder to understand.

Induced Bugs:
New bugs created while making changes to a program are one of the major sources of maintenance headaches. If you're lucky, the bugs are found during testing, so they just add time to the project. Sometimes, however, these induced bugs make it into production, often precipitating a new crisis.

These induced bugs arise from several sources:

  • Programmer misunderstandings -- the programmer just didn't understand the structure of the program well enough when making the change.

  • Hidden interconnections -- inappropriate interconnections (often the result of previous maintenance) are hidden "land mines" for the maintenance programmer. Each of these interconnections creates additional constraints on any future changes, and these constraints are neither documented nor logically follow from the program structure. As a result, the maintenance programmer has little chance of preventing a bug when making a change involving a hidden interconnection.

  • Incomplete testing -- maintenance programmers often fail to test fully all the parts of a program affected by a change, for two reasons: first, they may not understand the program structure well enough to know all the areas affected. Second, they may find it too difficult to test a particular part of a program, particularly if it is a deeply nested or widely called routine.

New Engineer Startup Time:
As programs get bigger and bigger, and as the program structure becomes more and more obscured by changes over time, it takes longer and longer to bring a new engineer up to speed -- to reach the point where s/he is creating a day's worth of results for a day's worth of work. Many companies report delays of three to six months before a new or reassigned engineer reaches full productivity. The reasons include hard-to-understand code, missing or incomplete documentation, and fear of making a mistake.

Fear of Making Mistakes:
Faced with all these problems and with mounting pressure to get an issue resolved quickly, programmers doing maintenance often chose the smallest possible change that resolves an issue. The main reason for this is the fear that more induced bugs will be created as more code is changed, and that "doing it right" will take too long, both in understanding time and debugging time.

Unfortunately, choosing the smallest possible change, while perhaps a valid way to resolve the current issue promptly, often leads to future maintenance problems. The smallest change is usually just a patch, and serves to weaken the program's structure, increase inappropriate interconnections, and increase a program's fragility.

We specifically desgined InstantC to help with the issues of C program maintenance. However, remember that no tool can solve all your problems -- for more on this, read No Silver Bullet.

How InstantC Will Help You With Maintenance Pitfalls:

Unfamiliar Code?
InstantC loads all the source code of a program at the same time. The recursive, visual browser makes it easy to follow down all the references to a symbol. At any level, the programmer can start a new browse to answer another question ("Well, who calls *that* function?"), and then resume the previous exploration. InstantC links the source code together in a manner similar to hypertext.

InstantC's "view" facility will show the prototype or declaration for any data, #define, type or function -- without having to wade through dozens of references as with a typical IDE's browser.

InstantC's source code formatting will show the code to each programmer formatted in a way that s/he finds easiest to read and understand.

By letting the programmer immediately execute C expressions, particularly function calls, in context and repeatedly, InstantC helps the programmer understand how the code works. It's fast and easy to try alternative solutions to a problem to see what works best.

Bad/missing Documentation?
InstantC's design is to make your source code its' own documentation. After all, you do still have the code for your application, right? By automatically formatting the source according to programmer-selectable options, the code becomes clearer for the programmer to read and understand.

By showing the prototype or declaration for any data, #define, type or function, InstantC serves as a reference guide for the application.

Best of all, all this documentation is guaranteed to be up-to-date, since it is generated automatically by InstantC from your source code.

Fragile Code?
InstantC's extensive run-time checking helps catch fragile code as it breaks. The recursive browser and immediate code execution aid program understanding to help prevent changes that make the code more fragile.

Induced Bugs?
InstantC help prevent induced bugs in several ways:

  • Run-time checking -- because all code executed in InstantC undergoes extensive run-time checking, many common C errors are detected when the program is executed. The programmer usually has prompt feedback when a misunderstanding leads to an induced bug. Because this extensive run-time checking is always active, traditional testing becomes much more effective. Even bugs in seeming unrelated areas caused by hidden interconnections can be caught.

  • Recursive browser -- InstantC powerful browser and program structure displays increase programmer's understanding of the program's structure.

  • Immediate mode execution -- by allowing the programmer to call functions in context, InstantC makes it easier to do full unit testing of changed functions, making testing more complete. Because the programmer can execute any part of the program at any time, s/he is more likely to understand how the program works and to catch the effects of hidden interconnections.

  • Incremental compilation -- InstantC's incremental compiler lets the programmer make changes while the program is running, which allows alternative implementations to be very quickly and easily tested.

New Engineer Startup Time?
InstantC directly addresses the challenges of facing an unfamiliar program, by means of the recursive browser, program structure displays, source code re-formatting, and immediate mode execution. InstantC is designed to make the source code be a program's documentation, reducing the stress of bad or missing documentation.

New programmers on a project using InstantC frequently report increased confidence in their programming because of the increased understanding aids. Even more strongly, they report that the run-time checking provides a "safety net" for their programming. The immediate mode execution also increases confidence, since the programmer can easily try out new code before making a change to the source.

Fear of Making Mistakes?
Because of the safety net that InstantC's extensive run-time checking provides, programmers feel more confident and are less likely to "take the shortest patch possible."

The immediate mode execution allows a programmer to easily do more testing, so that s/he can be more sure that a change s/he is making is the right one. In addition, the immediate mode execution allows the programmer to try out different solution implementations, again increasing both confidence and correctness.

The incremental compiler's fast cycle time, and its ability to make changes to a program while it is executing, also encourage trying out different solution implementations, causing the same boost in confidence and correctness.

Order InstantC today!

Return to the main InstantC page.


[InstantC] * [Tenberry] * [Users Say] * [FAQ] * [Tour] * [Order] * [Support] * [Links]
Last modified 97.5.16. Your questions, comments, and feedback are welcome.