A Big Ball of Mud

Via my feedburner subscription, I discovered a delightfully descriptive noun-phrase this morning, Technical Debt. Wiki describes it as a way…

…to describe a situation where the architecture of a large software system is designed and developed too hastily. The analogy to financial debt is that the poorly-written code requires “interest payments” of maintenance effort, which would be smaller or non-existent had the code been developed more carefully and with better long-term planning.

Originally coined by Ward Cunningham, it spawned related terms such as Big Ball of Mud. While these terms were gestated in software, I cannot think of a better descriptor of how most apparel manufacturing companies are organized.

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition… “Big ball of mud” systems have usually been developed over a long period of time, with different individuals working on various pieces and parts. Systems developed by people with no formal architecture or programming training often fall into this pattern.

Another analogous term is Technical Inflation which is described here as, “ground lost when the current level of technology surpasses that of the foundation of your product to the extent that it begins losing compatibility with the industry.” That brings me to the role of marketing in the mix.

…the blogs I read are written mostly by technology enthusiasts, yet the products they evangelize must be taken with a grain of salt. The open source world is a live ecosystem with small chances of survival, often not based on technical merit. This concept is common use to marketing people, but the average technical joe doesn’t give a crap about it. We should develop the instinct to choose the right product for our project, maybe guessing where we are …and where the evaluated product is. Innovation is not for everyone, and a sane decision would diversify risk…

The marketing caveat being…

Which means that all marketing people worth his salt will try to seem as they have already crossed the chasm no matter in which stage they are. Marketing campaigns are oriented to look like they have been already adopted by the mainstream, which helps very little to make the informed decision.

…which means marketing can also make it difficult for us to decide which products we design are appropriate for our customers. Or even, what’s appropriate for us in the development of our enterprises. It’s multi-faceted.

Returning to Technical Debt, there are two basic kinds.

  1. The first as unintentional. For contextual purposes, a simplistic description being that pattern is lousy because the pattern maker is inexperienced and made unintentional errors. Or, an inappropriately made pattern is rendered because a DE didn’t know which parameters were necessary to convey.
  2. The second kind is intentional. A company “makes a conscious decision to optimize for the present rather than the future”. This is what kills DE companies. You use a lesser developed or evolved pattern (as in the two piece ties pattern yesterday) incurring 40% waste ($9 per unit) because you don’t want to invest to pay for a better one, the assumption being you’ll fix it in the future -that never comes.

This site (a must read) further develops the concept in terms of the structure of debt, the key issue being one of priorities and the conflicts arising from it. Owners have higher tolerance for technical debt while technicians have none. Perhaps the solution is to make the debt more visible, it’s often hidden. This is equivalent to credit card statements; technical project debt should be similarly tallied for transparency. This author suggests these conflicts have arisen due to communication style saying

The technical debt vocabulary provides a way to communicate with non-technical staff in an area that has traditionally suffered from a lack of transparency. Shifting the dialog from a technical vocabulary to a financial vocabulary provides a clearer, more understandable framework for these discussions. I’ve found that it resonates immediately with every executive I’ve presented it to as well as other non-technical stakeholders. It also makes sense to technical staff who are often all-too-aware of the debt load their organization is carrying.

That’s all for now. I’m sure I’ll spend four more hours reading on this, back tracking to A Big Ball of Mud. I thought I’d make this morning’s procrastination (debt) more transparent (in an effort to reduce it?). In any event, maybe you’ll find it interesting too; I write too little of what I read, incurring a debt of over 400 unpublished entries at last count.

Get New Posts by Email


  1. /anne... says:

    Wow, this is my life …

    I’m a technical writer; I mostly write user documentation for software. I work on contract, because companies either won’t pay for a permanent technical writer, or will only pay peanuts. My current contract is for seven weeks. No way on earth can I update their current manual (in pattern drafting terms, no one walked the seams, there was no fit model, the sample was in a completely different fabric,…) to my standards – or probably even theirs. But, I need to pay the rent :-(.

    People, no matter how small you are, you need processes. Plan your work, work your plan, work it systematically.

    Oh, and if you’re choosing new software? Ask to see the manual. Does it make sense? Does it read well? Does it tell you how to install the software, do your routine tasks? If they’ve cut corners by getting the developers to write it, it will be obvious. A good manual suggests that they’ve also taken care to test their software, designed it properly (instead of just tacking things on as they go), and they actually care about quality.

    It’s all very well to sew something gorgeous, but if the fabric shrinks the first time it’s cleaned, or the dye runs – it isn’t gorgeous any more. Cutting corners never works.

  2. Anita says:

    /anne has it right. I, too, work on contract, but as a software developer. I’ve lost count of how many spaghetti code messes I’ve inherited. A lot of time, it’s due to something that starts small and then grows. Often, you get inexperienced people doing things the wrong way and this later gets duplicated in other places because that’s the way they did it in the other parts.

    So, the bad designs propagate and evolve into an unmanageable mess. A little planning beforehand can go a long way, but it’s hard to convince management that it’s required. They want results and they want them now.

    I really like this financial analogy. It might be a good way to actually get management types to understand the need for proper design at the outset of a project, rather than paying for the mistakes later on down the road.

  3. mc says:

    Love it.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.