By Jack Ganssle

Separating Functions

Published 6/22/04

Andy, responding to my Design by Clairvoyance article (http://embedded.com/showArticle.jhtml;jsessionid=CIP2AE0AW0IKQQSNDBNSKHQ?articleID=21100513), wrote:

Sometime between, say, the construction of the pyramids in Egypt, and the 19th century, the building construction industry bifurcated into two expertise domains: design and construction. Architects designed, and contractors built. And in order for contractors to know what the architects had in mind, several powerful information exchange mechanisms evolved. Architects built models (e.g.: Michelangelo's 1547 model in wood of St. Peter's, presented to the Pope), and produced working drawings. The builders then used the working drawings to accomplish the construction. No competent builder would accept incomplete or incorrect working drawings. To do so would risk bankruptcy.

We aren't quite so disciplined in the construction of software. Though the scope of work in a large project may take years to complete, the work product is mostly invisible, unlike a skyscraper. When software construction is underway, our clients see people sitting at workstations. There are no big holes in the ground, no noisy, heavy equipment, no piles of materials. Lines of code, even if there are millions of them, aren't tangible to our clients. Hence, many projects are cancelled, or are finished "late" (as defined by the original, deeply-flawed estimate), and "over-budget". The software industry needs to develop a discipline of design and construction. Until that happens, software development will largely remain, in the words of a former manager who was a hardware guy, "a thankless job."

Tom DeMarco wrote of separating the coding and debugging functions in his 1982 book "Control Software Projects." Yet two decades have passed and, in general, most software people are the blacksmiths of yore, designing, coding, debugging, testing and documenting their work. Not to mention the special joy of embedded systems: wringing out hardware bugs. Instead of specialization we embedded people try to be masters of everything, from assembly to C++ and analog to digital.

In the building industry, dividing the architect and contractor functions yields some pretty stunning benefits. They communicate by means of drawings and perhaps models of the proposed project. This documentation is a formal contract that tells the contractor what to build. The drawings arbitrate all disputes. Compare that to the standard "but that's not what I wanted" hand-wringing we hear from the 23 year old marketing droids when they first see our completed embedded system.

Though the customer probably knows little about designing buildings, the drawings and model clearly explain what he's buying. Clarity avoids contention.

It's easy to dismiss an architectural drawing as something much simpler than a big wad of code. Of course the customer can understand the project by referring to the blueprint -anyone can. But the drawings do hide a lot of critical detail. Lots of analysis not shown on the page insures that the building won't fall down, that plumbing and electrical will be adequate for its intended use.

Yet in software everything is in the code. We can't even agree on a standard for design docs. Gurus tout UML as the future, but very few embedded folks use that technology. Can your customers read a UML diagram? We desperately need a way to produce a complete design or model that's comprehensible to all important stakeholders.

Just as architects build scale models of their creations, maybe we can produce some sort of model for our inscrutable designs; something a customer can examine and critique. It's certainly possible to prototype GUIs and PC applications, but embedded systems are tougher. They may have to communicate with other machines, take data, and interact with the environment. The model takes a lot more effort than playing with cardboard and glue sticks.

And worse, a software model never looks like a model. No one has the sense that it's 1/10 the size of the real project. "It works great! Let's ship it!"

An architect's model is very clearly a mock-up.

Perhaps the most interesting part about the building trades is that everyone expects to pay the architect big bucks for a design. One that will take months, maybe years, to produce. The contractor doesn't start pushing dirt around till the drawings are done and the customer has checked every detail of the proposed structure.

In the embedded field the first question we get when the boss wants to start a new project is "How long will it take?" We have a day, maybe a week to hash out enough design to produce the usual wildly optimistic schedule and costs.

Architects don't give a price. The contractor does, once handed a complete design. For only then is it possible to figure the number of sinks, tile, wiring and labor that's needed.

Why is software different?