Following your fiberglass manufacturing example. It sounds like you've identified technical debt as it applies to physical engineering.

In all likelihood, somebody on the 'business end' made some very bad decisions that were penny-wise/pound-foolish.

Long-term sustainability for mechanical systems require paying extra to maintain the design.

A lot of business decisions involving engineering are completely reactionary. Changes are usually required when some unforeseen event happens (ex something breaks, market changes, etc). Poor budgeting will lack a contingency plan to cover these costs.

Even with a full-time staff of engineers, their role is usually limited to daily operations. Future updates usually require contracting outside support, at a premium cost.

When it comes time to do the work, it's in the interest of the business decision makers to reduce the impact on the 'bottom line' as much as physically possible.

The work will need to be done on a short schedule to reduce the impact on production. As soon as the changes are complete, it's in the business' best interest to send the outside support home as soon as possible. As a result, design/documentation updates are left undone.

Technical Debt:

Over time, physical changes accumulate whereas the design stays the same. When the design/documentation is unreliable, the cost of future changes grows dramatically with each additional update.

Technical Bankruptcy:

At some point it gets so bad that the design/documentation isn't worth the paper it's printed on, nobody knows how the system works, the implementation becomes fragile. Nobody is willing to accept the risk/cost of a significant engineering redesign. The system runs until it fails and the business writes it off as a loss.

There are some parallels that can be drawn. Complexity, is inherently difficult to maintain in the long-term.

You could choose to favor:

- Traditional Design:

Monolithic architecture w/ deep-coupling in software vs monolithic engineering designed for production not maintainability.

Everything is delivered as one big ball of mud. Even with good test coverage, the sheer complexity makes it difficult to make changes.

- Black Boxes:

External libraries in software vs COTS components in hardware.

The internals are opaque, if it breaks the only option is to replace it. If it becomes obsolete and/or long-term support is cut, good luck.

- White Boxes:

Internal well-tested libraries/modules in software vs modular/pluggable well-tested designs in hardware.

White boxes solve the long-term support issue but require significant resources to maintain/develop.

- Gray Boxes:

Open source libraries/modules in software; open hardware designs.

May not be feature-complete or include sufficient test coverage. The upfront cost is dramatically reduced but there may be license/communication barriers that prevent changes from being made.

There are trade-offs and risks that come with each approach. Monolithic designs require better language-level architecture and internal separation of concerns. Modular design require better system-level architecture and external separation of concerns. The only constant is, the greater complexity the greater the cost to maintain.