Jeroen’s weblog

The maintainability of software depends on a lot of different (quality) attributes of the code and related documentation. But what’s worse, instead of just maintaining a piece of software, evolving a piece of software (which includes implementing brand new requirements) has even steeper demands. One of the key things is the integrity of the software architecture: if that is compromised, the ability to evolve the software to perform more advanced or new tasks will be lost as well.

Recently, while performing maintenance on a .NET application I came across an issue that seriously compromised the software’s architecture. The application is a desktop application split into several components: a framework component that contains the general application functionality (or business logic), a GUI component that contains (one type of) presentation and several plug-ins that implement analysis methods that users can choose from. While using the application to reproduce some of the bugs that had been reported in the previous period, I came across a progress bar during the execution of a plug-in. This seemed odd, because I didn’t remember that the framework provided an interface to the plug-ins to report their progress, so I couldn’t exactly figure out where this progress bar got its information from.

As it turns out, the plug-in itself was instantiating a WinForms dialog with a progress bar in it. As far as my previously mentioned quality attributes are concerned this violates modularity: the application no longer works correctly when another presentation component is used, so it has effectively turned the entire system into a monolithic WinForms application. If you’d want to migrate the default presentation to another API (say, WPF), then modifying or replacing the WinForms GUI component will no longer do the trick. It also damages consistency since plug-ins no longer contain just the implementation of the algorithm: at least one of them is also doing something entirely different.

Why did someone think this was a good idea? Well, the problem is that I’m sure that whoever made this modification didn’t think it was a good idea, but he or she probably decided that it would be too much work to modify the interface between the framework and the plug-ins to allow the latter to communicate progress information to the former. This is common in maintenance: sacrificing architectural integrity for quick results and short-term stability (since this change requires less testing, at least in the cycle it was performed). Besides hampering the software’s maintainability and flexibility, it will also cause the system to lose the entire modular approach in successive maintenance cycles, since developers won’t have a reason to keep making other GUI changes only in the GUI component: the plug-in(s) already depend on WinForms anyway. This is known as a Broken Window and should be repaired as quickly as possible.