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.