The Mud Brick Business

Mike Taylor wrote: Creating high-quality software is an interesting mix of art and science. At least 20 years ago innovative leaders like Brad Cox and Tom Love (inventors of Objective C) began describing a "software industrial revolution" in which the process of creating software would move from an art done manually by skilled craftsmen to an "industrialized" process that allowed high-quality systems to be built from well-tested reusable parts. This dream remains largely unfulfilled.

In 2007, Accenture CTO Don Rippert described "Industrialized Software Development" as one of eight major trends that Accenture has identified as likely to have major impact on IT over the next five years1.

This triggered this email thread on "The Mud Brick Business"

Its amazing how the Software Industrial Revolution and SoftwareIC metaphors keep turning up (but flattering nonetheless). Recently I’ve been leaning to a new metaphor that contrasts primitive (mud brick) and modern (real brick) architecture which I find useful for understanding why that “dream remains largely unfulfilled”.

The difference between mud brick craftsmanship (cut-to-fit services) and real bricks (trusted standards based products) has little to do with brick-making technology and more to do with trust, standards, business models, etc. An innovative mud brick worker can't just decide to quit hauling mud (selling services) and start making standard bricks (products). That requires a business model in which standard bricks (SoaKit components) is viable compared to selling services (making mud bricks). Mud bricks are “free”. Real ones are not.

Yet somehow that bridge got crossed in antiquity to the point that we take it for granted today. Its discouraging it is still out of reach in software to this day.

I later responded to a misunderstanding: Mud bricks are made from existing materials too (soil, straw, water) just as our mud brick workers use java.net for low-level stuff. Mainly using seldom contributing.

Our work is building custom homes with mud bricks, making whatever non-standard untrusted components we need along the way (mud bricks) from java.net raw materials, not taking the evolutionary leap to standard trusted components (real bricks) that anyone can understand, trust and reuse. The evolutionary leap isn’t to pre-fab houses; its to using pre-fab trusted components (real bricks) to build custom houses, just like real engineers/architects do it.

Concise description is tricky because software engineering has not evolved trusted components nor even a vocabulary for describing them, unlike housing where there are dozens if not hundreds of well-understood integration levels; a nearly infinitely fractal tree of integration technologies (I build the house, you build the water pump, they build the motor, somebody else makes axles, somebody else steel, somebody else digs the ore, etc). Those nouns are understood and thus trusted in ways that software nouns, terms like "Access Manager" and "Access Agent", are not.

The closest software engineering gets to a “real brick" is a computer application, with java classes a distant second. Two levels (more like 1.2), unlike real engineering which has thousands of well-understood levels. That’s where SoaKit comes in as a modest beginning. It adds one new encapsulation layer between classes and applications, with OSGI as the membrane between inside and outside.

A challenging issue for software architects is... Does a mud brick business need an architecture role? I think not. Architecture never existed until construction made the shift to using trusted components (real bricks). Before then, there was only a customer, some laborers, and someone to choose mud and straw and mediate customer needs to the laborers. Everything from there was just cut to fit. Architects only emerged when there were so many trusted components available that a specialist was needed to choose between them.