Why Are Software Tools So Primitive?

Some years ago, I was working with a software architect on a data flow diagram for a system at the TMX. It was a pretty diagram and very complex. I was trying to use it to trace the effects of a component failure on other components. Past a straightforward single failure, it got complicated.

What I couldn't understand is why there wasn't a tool that would automate the process. It's not like the data flows were complex in themselves; into one component, out to one or two on the other side.  In this case, it didn't matter what the data was; I was just trying to trace the effects of things like component failures, network crashes, and so on.

It seemed to me that there should have been a modelling tool that would work live. Disable a connection in the diagram or a component and see what else breaks.

The developers described in this article have been thinking along the same lines.

There is an analogy to word processing. It used to be that all you could see in a program for writing documents was the text itself, and to change the layout or font or margins, you had to write special “control codes,” or commands that would tell the computer that, for instance, “this part of the text should be in italics.” The trouble was that you couldn’t see the effect of those codes until you printed the document. It was hard to predict what you were going to get. You had to imagine how the codes were going to be interpreted by the computer — that is, you had to play computer in your head.

Then WYSIWYG (pronounced “wizzywig”) came along. It stood for “What You See Is What You Get.” When you marked a passage as being in italics, the letters tilted right there on the screen. If you wanted to change the margin, you could drag a ruler at the top of the screen — and see the effect of that change. The document thereby came to feel like something real, something you could poke and prod at. Just by looking you could tell if you’d done something wrong. Control of a sophisticated system — the document’s layout and formatting engine — was made accessible to anyone who could click around on a page.

Victor’s point was that programming itself should be like that. For him, the idea that people were doing important work, like designing adaptive cruise-control systems or trying to understand cancer, by staring at a text editor, was appalling. And it was the proper job of programmers to ensure that someday they wouldn’t have to.

I learned later, working with other software architects, that there were tools that could do what I wanted; we just weren't using them at the time. I do hope that in the future more companies will. Otherwise, as the article points out, the consequences could be significant.