Analogies for software development - Embedded.com

Analogies for software development

Click here for reader response to this article

December's issue of MIT's Technology Review (see the picture on page 55) has a dramatic full-color diagram of the Insulin molecule, an exquisitely complex amalgamation of 843 atoms. This, though the simplest of all proteins, only slowly yielded its secrets due in part to the power of electron microscopy.

I was struck by biotech's ability to image and create two- and three-dimensional models of the microscopic world that's far beyond our human senses. Scientists developed tools that morph a molecule's structure into these strangely beautiful and (to a chemist, I guess) very descriptive views. The ability to see, rotate and manipulate the models leads to insight and understanding.

We in the firmware world also manipulate tiny, unseen objects. The 843 atoms of Insulin make up a giant of truly gargantuan proportions compared to the mere handfuls of electrons that form the bits we laboriously. . . what? Create? Not really; the electrons flow out of the wall socket. Move? No, transistors gate the flow of current. Maybe “organize” is the operative word. But even “organize” implies a process of sorting, which implies there's something being rearranged. One might argue that a program actually exists as charges embodied in Flash memory, or magnetized areas on a disk, or a stream of bits poring over a 'net connection. Yet none of those are essential elements of software; it's a fungible non-commodity perhaps best described by not-terribly enlightening word “enthalpy.”

Our job is to reduce entropy, to struggle against the Second Law of Thermodynamics. Put that way it sounds pretty noble!

So we're building, or organizing, things of enormous complexity that don't really exist. And we're doing that with extraordinarily crude tools. Microbiologists can look at a picture of Insulin and even build a 3-D representation. They can see exactly how a ketone, for instance, might bond to the molecule.

But we're single-stepping through source code, perceiving only five lines at a time of a mega-LOC monster.

Architects build scale models of their proposed buildings so the customers can see exactly what they're getting, and the designer can visualize the structure in something close to its ultimate reality. Civil engineers do the same; they'd never plop a foot-thick structural analysis on the mayor's desk. Aeronautical engineers use 3-D representations on the computer screen to find parts that interfere with each other.

Where visualization techniques don't exist the problem is usually poorly-understood. Neurologists' MRIs and PET scans produce only macroscopic, blotchy patches depicting blood flow. They can zoom in on individual synapses, axons and dendrites with an electron microscope, just as we can completely understand a gate. But such Descartes reductionism hasn't taught them much about how the brain functions. They're still pretty clueless.

Code, of course, is generally incomprehensible and our attempts at abstraction mostly pathetic. Flow-charts, data flow diagrams and even UML drawings are not pictures of a program; they're analogies, different ways of expressing the ideas embodied in the software. But analogy is indeed all we have.

I've tacked the Insulin picture over my desk to remind me of the poor state-of-the-art of software development, and continue to search for other analogies that can more graphically illustrate the meaning of our code.

“Code” is indeed the correct word to describe our creations, for we take a crude specification and transcribe it into a computer program using a ciphering system not unlike that of the German Enigma machine. for (i=0; i means nothing to our customers — it's a code that does somehow instruct the machine to do something. But there's no direct correspondence between even those cryptic phrases and bits in the computer — a compiler surely scrambles and optimizes the for loop into dozens of instructions scattered nearly at random over perhaps thousands of bytes of memory. Once smart developers could understand machine code, but now with RISC machines and highly-optimizing compilers that possible only with extreme effort.

The three actors in our drama — customer, programmer and machine — all speak different languages poorly bridged by inadequate tools.

The future surely must hold a different analogy for software development. Our brains have huge vision centers, which is why we understand best via graphics and visualization techniques. But those depictions have to have a ring of the familiar, as does the image of Insulin. We need a different way to visualize computer programs, something that's visceral and dramatic. Something that's a far cry from a 50 pound listing.

Someday we'll have a virtual reality environment that puts programmers into the center of the software, to illustrate data movement and real-time events. There will be a zoom control that lets customers back off from details yet clearly see the features. Managers will get a different view entirely, one that shows details of development progress, quality and costs both incurred and projected.

After all, a picture is worth a thousand functions.

What do you think? Is the future merely more dreary source level debugging and heroic translations of inadequate specs into C?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .

Reader Response


I think, there is a solution to the analogy problem, high level design/modeling tools and automated translation to machine hardware.Exhaustive testing is another big issue but that can be tackled with high level formal verification. From what I hear many vendors areworking this route, low level design is useless under modern reliability requirements.

– stefanos


The 3-D molecular model of insulin you describe is not so different from some of todays UML or state machine models of software. Both arestatic representations of very dynamic (protein or software) objects. I'm sure a biochemist has just as hard a time understanding the waya protein twists, turns, and interacts with other proteins in real time as we have of visualizing how a running program interacts withitself and its environment. One thing I will agree with though, we could sure use more attractive models of our work, incorporating colorand the third dimension. Todays stick figure cartoon diagrams are not particularly information-rich. A software model that a biochemistwould hang on his/her wall because of its beauty, rather than its meaning, anyone?

– Mark F.


Jack! I must say we have the potential. I think we are talking of tools (those futuristic) that can create tools (of the present).Considering the whole software application itself as a tool for an activity other than software! I guess optimizing compilers are just asmall step toward the future. Also expected is a tool that can provide various views for customer, manager and programmer for a verbalquery from the same (generated/handwritten?) codebase!

– Saravanan T S


All the examples of good modeling are models of actual physical entities, either microscopic or macroscopic. It's easy to model a physicalobject, but how does one model an abstract object?

Logiscope is an interestring program that at least allows someone to visualize the strucutre of a program. Other than letting someonedevelop a visual grasp of code complexity, I'm not sure of it's utility. (I'm referring to ver 1.0, not sure how it's evolved since then.)

– ed hoog


I'm not sure we'll reach the point of meaningful graphical software models. In reality, software is really an algorithm, a plan on how to respond to certain events. A graphical model of software is akin to a graphical model of how to fly a Boeing 777.

The only way that a graphical model of software could be actually useful is if that model was a dynamic “video.” Software is so dynamic that a frozen picture of it at a certain state is far, far less useful than a frozen picture of the insulin protein. In fact, a “standard” video of software might be far, far less useful that the same of the protein. After all, the protein itself is static, and responds to stimuli the same no matter what it's state. Turn the protein around, and it responds the same. The way software responds to stimuli often depends on the dynamic state of the software. A video representation of even the simplest firmware would probably be tremendously long. And exactly how useful would that end up being?

– John Patrick


I really enjoyed this article! Though I have been writing software for 20+ years, it made me think of software in a very different way.

It seems to me that the best visual representation of embedded software is through a visual simulation model, where the complexities of resource utilization and multi-threaded processing can be shown. This, of course, would require the simulation model environment to accurately represent the hardware environment. Once that is specified, the software could “run” within the hardware representation of the model. Each external event source model could simulate the external events. The simulation model would graphically show message flow and control flow through software “blocks”. Through the viewer's desire to analyze the internals of a block, each block could be expanded to show a lower level of abstraction, etc. This also seems to be an incredible way to visually debug a multi-threaded system.

I really appreciate your article.

– David G. Wright


A tool that I have been using that is in this category is Understand for C/C++ (www.scitools.com). It has reasonable graphical function-relationships, and really quite good browser abilities. The very reasonable demo policy is what got me hooked. I managed to get my boss to buy it ($500), and it has paid for itself in the past year.

– Dave Kellogg


Modeling tools have been around for quite some time, without making any larger impact. Now they seem to become popular, but it seem morebecause of the size of the project that management need to handle, people rather then software.The lower levels (Code writers only get toknow things on need to know basis to not cause problems or competition.) “Divide and counquer” Moving jobs to low salary countries. Buthopefully the boundary between Hardware/Software and a less traditional role of the developers can motivate better models(Needed forhardware mapping and software/Hardware validation.) Could take some time since the traditional tools are NOT good enough. Nooo everythingCANt be expressed with C++ and thus the optimal compiler CAN NOT be written. For now it seem that code tools will rather be likeWindows/DOS”Code generator/C++” a Giant built on mud ground. But be sure that development NEVER get stuck it will continue in some form.

– Martin Lundstrm


We can be certain that we will have highly advanced visualization tools in the future that's progress! But in the present, I have founda remarkable program called Crystal Flow for C. It can be found at www.sgvsarc.com. It's code visualization, in form of flowcharts, issuperb. Instead of seeing only five lines of code at a time, I can see the whole view of a 500-line function or zoom to see the flowchartof a 20-line loop in that function. It generates comment flowcharts that enable a wide audience to understand the program logic. Anothervisual treat is its filtered call-path display.

– Jason Taylor


For some work relative to this,see http://www.cise.ufl.edu/~fishwick/aescomputing(a good introduction is one of the videos on the first line). There is a news group as well at Yahoo Groups (aestheticcomputing).

– Paul Fishwick

Leave a Reply

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