A design trap of the maintenance phase

Clarity on roles the key?

By Rick Jelliffe
August 19, 2009

After all the excitement with designing the prototypes and reworking it into a stable maintainable state, system development projects slip into a maintenance phase. We like to to think of this as a well-oiled machine, where requests for enhancements come in and get dealt with.

But there can be a design trap at work.


  • It comes because frequently it is a junior or middle-level programmer who has to deal with the enhancement, and they are supposed to do it in the framework of the current design. But the senior programmer (designer, analyst, team leader, whatever they are called) who vets the enhancement request may be using a very limited criterion: is this a change that fits in with the current design or not?.
  • Indeed, in some workplaces, the enhancement may go directly to the programmer who is acting as agile client-liaison: the boss's idea is that the programmer tries to implement the change in the context of the working system, and only escalates the problem to the designers if they cannot do it. A recipe for shoehorning.

Both these approaches have a trap in them. The junior programmer needs to have a very clear idea of the various roles that are implicit in the design.

  • For example, a request for enhancement comes in from the client to apply a transformation to a certain element before it gets output—say to correct the serial numbers on a set of part numbers. So the developer adds code for this to their XSLT or Java or .NET or Python, and the client is happy.

    But the developer should have considered the roles and responsibilities issue: is it really his job to correct data? Quite likely this something that should be done at the data storage side, in the XML or database. Doing it in the application complicates the application, is extra re-development work when the system gets replaced eventually, and may need to be done for every parallel process that works on the incorrect data. And the customer will come to perceive it as complexity and clunkiness of the application.

    The junior programmer may be thinking oh, this relates to business logic, so of course this is my responsibility or it is not my job to tell clients what they need. But they are mistaken.

  • Lets take another example. A client makes a request for an enhancement to tweak a page in certain cases. It is trivial to do in the XSLT and everything goes ahead apparently smoothly. But next time the stylesheets are revised, this exception has to be tracked down and re-implemented or coped with.
  • And here is a third case. The software is implemented using a third-party open source library. A change request means that the library needs to be augmented to cope. The junior programmer does this, but it effectively forks the code and means that any upgrades in the library need to have the changes ported to them. Often this translates to only upgrading the libraries when there is a show-stopping problem: the quality that Eric Raymond talked about from the thousand pairs of eyes is stymied.

In all these cases (and apart from any other organizational improvements), the trap can be mostly avoided if the junior programmer has a strong understanding of, and commitment to enforcing, the various roles and responsibilities.

In the first case, the junior programmer needs to have said "This is a data issue, not mine: we need to liaise with the data capture people." In the second case, the junior issue needs to have said "This is a style issue, not mine. We need to liaise with the web designer." In the third case, the junior programmer should have said "This is a library issue, not mine; we need to liaise with the external library people."

One feature of all these, is that the data capture, style and open source library people are all likely to be in different offices or orbits from the junior programmer. There is no chance for informal or watercooler chat.

So why is this a design issue? Because the slow addition of these little inappropriate fixes is like the growth of barnacles on a boat's hull: eventually you are not sailing a boat but sailing a rock. The initial stable design is made with great clarity as to the roles involved, but the junior programmer may not be aware of how important this issue can be: they don't see themselves as designers, and they may try to shoehorn all enhancements into the running system without considering the accumulated impact on the system's design.


You might also be interested in:

News Topics

Recommended for You

Got a Question?