What Does Software Look Like?

I am reading the book, Engineering in the Mind's Eye by Eugene S Ferguson. The book is an in-depth discussion of the design process as found in many areas of engineering. And the focus appears to be on how those forms come to exist. He frequently cites the many paper models of the project to be created. And he stresses the visual component of how the designer tries to document what the finished product and its components look like. But how do I apply that to software engineering? If I am going to specify a system, what images help? What does software look like?

The difference between the surface appeal of a product and the inner workings is not unique to software of course. Something like a motor presents the user with a largely inscrutable object which turns an armature. But we all know that the inner workings of such an engine, or pump, or even an auto are complex. At the extreme we have the computer which has a relatively trivial surface appearance with a screen and a keyboard. But we all know the enormous complexity that exist under the cover. By analogy it is not much different than having a modest cottage that has all the inner workings of a large modern skyscraper. The appearance belies the complexity.

It is not as if the surface appearance does not matter. Quite the contrary. Working out the human-computer interface is a very important part of the design process. Not even as much because of the importance of that interface for the successful operation of the product, but because it is the way that most users can most easily explain the expected behavior, and the complex inner state transitions that are expected.

Some software product however have no human-interface design at all. Embedded systems have an interface of course. But that interface has no user perceived behavior. It becomes a piece of the infrastructure like the plumbing that we never want to deal with. And as long as it works, we don't need to.

Yet these are all important applications of software technology. And we must find a way to understand how to specify the software we need and communicate that to those who can build that for us. And much is the design literature leads us to believe that this division of designer and implementor is something artificial even while scale may require some specialization by skill.

So in this book I am hoping to find the start of some answers about what software looks like. When I engage in creating a blueprint for a software system, what should that look like? What should be visual? Are UML diagrams the right way to communicate intentions? What must be tabular? or do we need new extensions to computer languages to capture the information that right now seems to imperfectly flow from designer to builder in the processes we use today?