Is there a formal anti-pattern to describe the scenario?

Question

Some code is written to generate Excel Spreadsheets (Office Interop).

• The code performs very poorly.
  
  • A subsystem is designed to generate the files at night. Performance isn't a concern at night.
    • A function is created to pick the correct file from the 100 different files available depending on a chosen set of parameters.
    • Because physical files exist, an archival system is added to backup these files (There is no reason to archive. These files should be generated on the fly).
    • This system doesn't include a configuration file, instead it has a hard coded "server picker" function that simply reflects upon the server the code is running upon.
    • A scheduled task is necessary to support and run this service.

This boils down to a single problem. The original code performs far too poorly to run in a production environment.

Had the performance problem been resolved, the subsystem and subsequently archiving system, "file picker factory function", hard coded failure point and the maintenance of the scheduled task and its added point of failure have no need to exist.

This is a "cascading failure" if you will. The original problem led to more bad code, more bad solutions and unnecessary overhead. Is there a formal anti-pattern or general term to describe it?

Answer 1

Lava flow?

In computer programming jargon, lava flow is a problem in which computer code written under sub-optimal conditions is put into production and added to while still in a developmental state.

From the Perl Design Wiki: Lava Flow is "when code ... spews forth and becomes permanent, it becomes an architectural feature of the archaeological variety. Things are built atop the structure without question and without hope of changing what is beneath them. The existing code is seen as an historical curiosity."

Often, putting the system into production results in a need to maintain backward compatibility (as many additional components now depend on it) with the original, incomplete design.

Lava flows are often exacerbated by changes in the development team working on a project. As workers cycle in and out of the project, knowledge of the purpose of aspects of the system can be lost, and rather than clean up these pieces, they are worked around, increasing the complexity and mess of the system.

Lava flow is considered an anti-pattern, a commonly encountered phenomenon leading to poor design.

Answer 2

I'm not sure this is an anti-pattern. As with all anti-patterns, we have to take your word that whoever thought it was a good idea was mistaken, but in this case that sounds plausible and I'll take your word for it, so that's not the problem.

The problem is that to be useful an anti-pattern needs to describe some sort of general pitfall and how it can be avoided. In this case, I guess that would be finding a work-around for code that performs badly when you could just have made it perform better.

The problem with that as an anti-pattern, IMHO, is that knowing about it seems unlikely to be of much value. Whoever did this presumably already understood that it would be nice to know how to make it perform better, so they must not have known how to do it. So having heard about the general situation as an anti-pattern wouldn't really have helped.

As far as a general term to describe it, "cascading failure", as you suggested, works pretty well. The term I like for unqualified people off on a mission that didn't make sense in the first place is snark hunting, but that seems too harsh for this situation. (But I'll somewhat gratuitously throw the link in anyway, since it's the best depiction of a doomed enterprise I know).

Answer 3

Not certain if this helps, but office automation is often a special case:

Office automation is usually done this way if it must be automated off a user desktop (esp. for .net websites because the office automation docs correctly warn you that there will be bad leaks in office interop tools if they are run headless. When I was forced to write headless processes to generate office docs with that toolkit we called the sacrificial services because you had to murder them periodically to get the memory back.

Other than the archiving what you are describing is unfortunately a best practice in some cases.

Link: http://support.microsoft.com/kb/257757