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?

  • 1
    Code that isn't scalable? If your hosting provider was going out of business in a month and you needed to migrate the production environment to new servers would it constitute the need for a software release and general emergency panic? I think you know the answer...
    – maple_shaft
    Commented Dec 13, 2011 at 17:29
  • 1
    Wow, that sounds like a report generator app I wrote about 12 years ago. Well, except for the lack of a config and hard coding. The archiving could be a legal requirement like it was for me, useless but required anyway. Performance was poor at first but creating a properly optimized separate reporting DB made that went away. Running reports on a highly transactional DB is the start of many bad ideas.
    – jfrankcarr
    Commented Dec 13, 2011 at 17:54

3 Answers 3


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.

  • 3
    I've seen this before (ok ok I see it almost every day) but I never new the name of it.
    – Kevin
    Commented Dec 13, 2011 at 17:27
  • 3
    Thanks. I had never heard it called that. I usually refer to the pattern as the Winchester Mystery House.
    – jfrankcarr
    Commented Dec 13, 2011 at 17:56
  • @jfrankcarr: I like your name better. very clever.
    – Kevin
    Commented Dec 13, 2011 at 18:01
  • I don't think this is what Lava flow really means. The idea is that code that is no longer used has congealed like lava over the landscape of the real code. In the case the code is still used, it just probably would have been better to do differently in the first place.
    – psr
    Commented Dec 13, 2011 at 18:09
  • @psr - The section ""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." is much inline with what has happened. Commented Dec 13, 2011 at 18:12

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).

  • +1 Many good points. You may be right. I've seen the process repeated several times at this particular place. So, thats my motivation for describing it as an Anti-pattern. Rather than to fix this particular issue. Commented Dec 13, 2011 at 18:26

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

  • +1 - Thats an interesting comment. Ill keep this in mind. The service needs to stay then. Though the performance is horrible. 1 minute to generate a spreadsheet with 5 columns and less than 100 rows. Theres 100 spreadsheets... Commented Dec 14, 2011 at 1:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.