House of Cards Design Anti-pattern

I’ve had this anti-pattern in my head for years.  It’s an observance of some projects and methodologies that I’ve witnessed over the years.  I believe it’s a form of Voodoo Programming, Programming by coincidence, and is often a side effect of Cargo Cult Programming.

Anti-Pattern Name
House of Cards Anti-pattern

Problem
A problem occurs when software is written that works in a specific observed scenario but no one knows why it works in that scenario.  Observation of "working" is taken as enough evidence of completeness.  It is very often not enough to observe something working in one scenario for the software to be considered "correct".

This is often a result of continual hacks in sole response to correcting bugs without consequence to design or maintainability.  Repeated hacks (cards) are are placed on top of other hacks until something has the appearance of "working" then all development on it stops and no one wants to go near the code again for fear of breaking it.

At the very least, House of Cards design is fragile, hard to maintain, un-agile.  Worst case it’s is of low quality and prone to error and data lose.

This is a general sign of cowboy coding.  I means there is no acceptable methodology, and no real management.  There’s little development direction, and likely no development leadership (at least none with any meaningful experience).  Features are generally driven solely by an external source that communicates directly with developers.

Symptoms

When reviewing code or questioned about code, developers respond with comments like "don’t touch it, it works", or "we don’t want to change it because it works".  There’s a reluctance to change the code because no one really knows why it works.  The code stagnates, new features are slow to be implemented, and there’s a general un-assuredness about the code.

The code is generally procedural, although following object-oriented syntax.

Refactored Solution

Establish experienced development leadership.  Establish a development methodology that separates the stakeholders from the developers.

Invoke Agile methodologies to manage the requirements of the project and begin Agile redesign of the code employing unit testing, refactoring, patterns, etc.  Aggressively refactor the code adding unit tests to test for specific problems as they arise, until the code is robust and reliable.  Mandate adherence to SOLID principles: classes adhere to Single Responsibility Principle, Open-Closed Principles, Liskov Substitution Principle, Interface Segregation Principle, and uses the Dependency Inversion Principle

Digg ThisDotNetKick This

8 thoughts on “House of Cards Design Anti-pattern”

  1. This sounds in many ways like the project I’m working on at the moment – which started off as a Greenfield project and hasn’t even been released yet. At least I can now describe the concern that has been sitting at the back of my mind for a few months now.

  2. This is painfully familiar. But here’s my question.

    How do you sell the refactoring effort to management?

    I’ve tried to explain what the condition of the code-base is and what are the consequences when you try to maintain and/or extend the code (reliability, time needed to understand the code, bubble gum fixes etc). The management is always very understanding, but come the next project, the refactoring needs always get second priority. How do you convince management that “observation of working” isn’t evidence of completeness?

  3. @Rubio. Generally you have to re-iterate the concerns they should already be having. They should have quality concerns, they should have turn-around concerns, etc. Explain how refactoring will help in there areas. If they have none of these concerns, it’s much harder to sell the fact that things need to change. If it’s “upper management” you’re trying to sell to, you’ll almost always fail. Refactoring is just a part of iterative design that you must schedule. If you’re trying to sell to your development manager, there’s likely a disconnect there and you may never be able to “sell it”. In cases like that, I would simply include refactoring in all time estimates for development (i.e. time to implement feature x would included refactoring and unit testing effort); and maybe start looking for another employer.

  4. Wow, as other’s have said, this sounds familiar. One of the issues that our development team deals with it is not the Cowboy Coder mentality, but the Cowboy manager. Thus causing the anti-pattern.The manager will send out requirements and come up with “rules” for fixing issues without even consulting the developers. Then the developers will be told, you need to code it this way because we’ve already told our partner how it needs to be, and it’s going to be easier for them to code this solution. Yuck.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>