Visual Studio/C++ and graphical data analysis apps
Lessons Learned from Rebuilding a Legacy C++ Graphics Application
Between late 2005 and mid-2009 I worked on a graphical application designed to provide airport security personnel with an interactive 3D view of baggage and its contents reconstructed from an array of X-ray tubes. This was a maintenance programming assignment—I did not write the application originally—but by the time I inherited it, the software had deteriorated to the point that virtually every modification had become difficult and risky.
The application itself was capable of impressive results, but the architecture behind it was another matter entirely. In case after case, the original developers had been presented with a choice between a straightforward, maintainable design and one that would create technical debt. More often than not, the wrong choice had been made. The result was software that became increasingly fragile as additional features were added.
The purpose of this article is not to criticize the original programmers. Every programmer eventually inherits someone else's code, often under impossible deadlines. Rather, the goal is to point out several architectural traps that are easy to fall into and which can make a large C++ application progressively more difficult to maintain. Microsoft may have improved some of these areas over the years, but the underlying design principles remain the same.
- Choose the Right Application Architecture
One of the largest structural problems was that the application had been built around Microsoft's Document/View framework.
Document/View is an excellent model for applications such as word processors, editors, or CAD systems where a document is the central object. A baggage viewing station, however, is not a document editor. It is essentially an instrument panel containing image windows, buttons, controls, status indicators, and operator commands.
Trying to force an instrument panel into a Document/View architecture complicated nearly every subsequent design decision.
Rather than rewriting the application from scratch, I found a way to re-base it onto a dialog-oriented architecture while preserving the majority of the existing functionality. Once this was done, many other problems became much easier to solve.
- Design for Dynamic Screen Sizes
The original application had effectively been designed around a single screen resolution. As larger monitors became common this was inconvenient. When customers wanted the software to run on laptop computers, it became nearly unusable.
Instead of manually repositioning every control, I created an STL-based layout table describing each widget by its control ID together with its relative position and size within the main dialog.
Whenever the main window resized, a single routine traversed this table and recalculated the position and dimensions of every control.
This eliminated hundreds of lines of repetitive resizing code and made support for different screen resolutions almost automatic.
Today nearly every modern GUI framework provides some form of layout manager, but at the time this simple table-driven approach proved both flexible and reliable.
- Replace Low-Level Graphics Code with Higher-Level Abstractions
The rendering code had become increasingly difficult to understand because it manipulated OpenGL directly throughout the appliReplacing much of this code with the Visualization Toolkit (VTK) dramatically simplified the graphics architecture.
Instead of managing low-level rendering state throughout the program, the software could work with higher-level graphical objects while allowing VTK to handle the rendering pipeline.
The resulting code was cleaner, easier to maintain, and somewhat surprisingly, faster as well.
General Lesson
One of the recurring themes in software engineering is that complexity grows much faster than functionality. Every shortcut taken today eventually becomes someone else's maintenance problem.
When inheriting an existing application, it is often tempting to continue adding patches simply because "that's the way the code already works." In my experience, carefully improving the architecture first frequently reduces both development time and long-term maintenance costs.
Good architecture is not about writing clever code. It is about making future changes easier than past ones.