Software Cannot Be Modeled Old Version

(This page copied here from SoftwareCannotBeModeled Oct 99 as a test of RefactorByCondensingConversation. I expect to delete this text in late Nov 99 - AlistairCockburn So soon? This is such a rare example of UseRealExamplesForWikiOnWiki. Keep it for a further decade or two?)

Influenced by SoftwareHasNoShape.

Can software be captured in diagrams on paper or any other medium but the actual instance of itself? The question is: Can Software be modeled? I think the answer is No.

Software is its own best representation of itself. No matter how well you have attempted to diagram, explain or model software, the truest representation of functionality lies within the code itself.

Of course, we try to manage the complexity of software by documenting the design, but you cannot expect to get the feel of a system until you see it yourself.

An architectural blueprint of a building is NOT a manifestation of the building design. Only an actual building can represent itself. (See ArtHouse)

This is even more true in object oriented software development. We may go through a complete Analysis, Model and Design using CaseTools or documentation systems, but we end up changing the objects and their relationships during implementation. (Of course, we go back and revise the design docs when this happens. ;-)

Good ClassBrowsers? are great for walking through software buildings. They are not a substitute for design docs which may attempt to give the big picture, but they are great for letting you roam about. You want to really understand a software system? Browse it.

-- ToddCoram

I don't think it's a question of whether it can be modeled. Many people model software. The pertinent question is: why bother?

"All models lie; many models are useful." CRC cards are a software model: a particularly good and dynamic model. They don't model performance or memory requirements particularly well, but they are still useful. ("If you want to understand a system, be the code").

BertrandMeyer relates that he has long been intrigued by the industry fascination with CaseTools. Why would anyone in their right mind want to build abstract models, when there is so much to express in the code, and learn from the code? One morning, while shaving in front of the mirror, it struck him: bubbles and arrows don't crash.

Blueprints are models; they serve a purpose. I wouldn't use them to evaluate aesthetics. If aesthetics are important to you, you want something other than a blueprint.

There are many who believe that software should "model" the real world; this is one of the themes of the OO camp. I agree only in small degree. TerryWinograd has strong sentiments against this perspective, based on his work in cognitive science. There are deep hermeneutical issues at work here, too: can you look through a Window to the outside, or pull down a shade or close the blinds on a Window? Why, when you close a Window, does it go away, and when you open it, it comes back into being? There are many dangers in this "inverse reification", particularly for the growing programming populace that lacks training.

-- JimCoplien

My original statement (last line of 1st paragraph) is a bit too strong... JimCoplien is correct in pointing out that people do model software (I do too). I still stand by the overall flavor of my post, but I want to restate it as:

Can Software be accurately and faithfully modeled? I think the answer is No.

-- ToddCoram

Software can be modeled to a point . Once again, it requires judgement, experience, and occasionally luck to determine just how much modeling is sufficient to support the next development step. With the right people, it all seems to happen in such a seamless, fluid manner that we all continue to crack our skulls over exactly how we can refine it into a series of steps that are guaranteed to produce perfect software, first time, every time. Are we perhaps forgetting that even a discipline as old as architecture requires refinement at every stage, and that occasionally entire walls, or plumbing sections have to be torn up and redone by the construction crew despite the detail of the design? Hasn't there been at least one sewer system, which despite the best hydrological modeling did not respect the fundamental fact that shit runs downhill? Someday we will accept that there is no substitute for judgement, and that the degree of modeling will be flexibly based on the complexity of the problem, the expertise of the team implementing the system, the tools available, and a dozen other factors that only human experience and intellect can evaluate.

Tangential thought: read the chapter, "The Psychology of Machines" in Norman Mailer's Of a Fire on the Moon. His thesis is that beyond a certain point in complexity, no machine can be completely comprehended and its behavior must be considered psychologically rather than mathematically. Something like that.

-- DonOlson

Yes, we can model software "to a point". But modeling only reproduces its archetype "to a point"; to do moreso would cause it not to be a model.

I think it is not a question of faithful, but of complete. Tautologically, a complete model is not a model. We use quite faithful models of telephone network performance to do traffic engineering. They are faithful to the real thing, but they abstract (unimportant) details (unimportant to the modeling objective).

I loosely use the term "model" for performance models, reliability models, and other system perspectives that can be captured using mathematical formalism. (I'm not arguing for a standard definition, just conveying my personal use of the term). Stuff like CASE tool diagrams, I call specifications. As the name suggests, they are specific. Specifications leave many dimensions unarticulated; I think this is fundamental to any specification of a non-trivial system. The code itself is the most specific specification. But it may be a lousy model.

-- JimCoplien

We make models for two reasons, I think: to understand relationships, without having to dwell in details beyond what is minimally necessary, as Jim states above; and to avoid being distracted or discouraged by the immensity or complexity of the actual system, building, spaceship, social organization, economic system, whatever. Models are a way to gain confidence. So, sometimes we model in text, sometimes in diagrams, sometimes with prototypes, sometimes with CRC cards, sometimes with all these and more. Due to my less than rigorous engineering background, I have never had the faith that it was possible to model a system to the point where it yields the system itself, although in my years in software I have heard innocents speak of marvelous tools and methods that will do such things (See the BigRedButton story). To me models were things I created to wrap my wits around those problems I lacked the confidence to tackle head on. They were an aid in discovery by seizing my attention so that I was not continuously terrorized by the enormity of the beast.

-- DonOlson

Okay, friends, now we will all take turns editing the following sentences until we have a good summary of this page ...

A model is a spoof of the original, like the thing but not the thing, designed to be faithful in some areas and deceptive in others;

We build models to examine specific questions we have about the system. This justifies our abstracting and removing "irrelevant" things. "Irrelevant" means things that do not contribute to the examination. (see WhatIsaModel)

Software is not always a model of the system in which it resides or with which it interacts; it is part of that system, and as such, there are limits to its function as a model of that system; but,

Models are limited in fidelity, because abstraction always loses information. When the properties of interest are sufficiently manifest in software itself, further modeling is inappropriate.

Models are worth preserving because they keep clear, through many variations and many generations of maintainers, the the aims and principles on which the software is built.

Models are safe to monkey with because they do not bear the burden of the expectation of success or financial gain.

-- WardCunningham x 2 & JimCoplien & AlanWills & DonOlson & ToddCoram & AlistairCockburn & ...

I am not sure how to add to the previous Ward & Jim & ... section. So I will add this new section.

I take the view that software *is* a model. I may have other separate models of my software because...

My software may be incomplete, but I want to show what I do know. Or my tools may not allow me to view my software in multiple ways, but I don't want to show all the details all the time.

Ideally, there is one instance of my software and multiple ways to present it. As I know more about my software, I add to it. But ideally, I can still view it many ways.

As I add to it, there may be ways to "execute" it. Execution may tell me things that help me add to my knowledge about it. Some types of execution may be sufficient such that I do not need to add to it. I can stop adding to (for awhile, anyway) and perhaps give it (or sell it) to someone else.

I hope this obtuse message communicates something about how I view the analysis/design/implementation distinctions as something to be avoided.

-- PatrickLogan, patrick_d_logan@ccm.jf.intel.com

I agree with JimCoplien's statement that a complete model is no longer a model. However, I believe that you can model software. You do this by creating a complete model where the interfaces to the realworld are unchanged when you use the model as a model verses feeding the model to a machine to create a real world application. In this case the model is also then a specification for the exact application that it models.

Consider this point and extend the concepts to an arbitrary 'language' for model specification. If the language is capable of specifying everything except the interfaces to the real world, it might become quite complex. One might then be tempted to just use the language of the system where the real world interface exists.

What I am trying to bring out is that your program can be considered a model if it can be used with the real world interfaces stubbed off. If you wanted to then replace those interfaces with machines, you could model the real world.

The fundamental issue for me is if you can not mechanically (and in some automated fashion) move your model representation into an application representation then you have no model.

Humm, did I say anything different than what has already been said? I think I said that if you call something on paper a model, it can't be (that was said above). The point I think I made was you can model software if the subset of the real world application that you call the model can be mechanically transformed into the application. There are many code generating case tools which purport to do such things. I don't know how many actually let you create models of the real world interfaces that would allow you to not have to 'rewrite' the interfaces to the real world when the model was transformed to a real application. whew...

-- GreggWonderly

I think we have once again been bit by the computer industry's appropriation of the word "model". Above, we used the term in its sense of reducing the complexity of a real-world phenomenon. On the other hand, in the context of, say, object modeling, or business process modeling, or even model-view-controller, we mean something different, I think.

DouglasHofstadter goes into this at great length in GoedelEscherBach, where he talks of isomorphism and its relationship to information and meaning. I think that when I create a "data model", I create a software entity that is isomorphic in its environment to the real-word entity that I am modeling. I try *not* to simplify, if possible, but instead to describe. While some simplification is inevitable with today's systems, I think that that is an implementation artifact rather than part of the fundamental semantics of the process.

If we accept that, then I see no reason why software can't be modeled - the model and real life happen to both be soft when I do. The existence of the model allows me to capture and manipulate the structure of the software that is otherwise more difficult to discover. Consider, for example, the rule that all VisualAge identifiers contain the "Abt" prefix. In fact, because the model and the phenomenon being modeled are both the same medium, in some sense the model can be more faithful.

When the model and the software being modeled exist in the same environment, I have a reflective environment. This allows me to, for example, discover that a method has only one implementer and compile away the message dispatch overhead. I can't do that unless the system has a *model* of objects, messages, and execution.

The environments that I'm most interested in, like Lisp and Smalltalk, are *causally* reflective. This means that they not only contain a model of themselves, but a change to the model causes a resulting change in the system behavior.

So I think that not only can software be modeled, but it's actually *easier* to model than ugly real world stuff like mass that spins, fluid that flows, and storms that cause snow.

Finally, I think that the essence of successful application building is successful modeling. When I work on software tools, such as compilers, browsers, pattern editors, and so on, I model software. So I certainly hope that it's possible!

-- TomStambaugh

Yes, software can be modeled, since a model simply exists to allow a question to be examined (from WhatIsaModel). I have a whole lot of questions I want to examine about software - performance, load, fanin, fanout (aka coupling), ownership, changes, error rates, etc. So I want a performance model of the software, a coupling model, an ownership model, a error model, etc. All of these are valid models, satisfying the notion of "a model of software" as distinct from "the software itself". None of these models generates the software, which was somehow the implication in some of the original comments.

I have a rule of thumb for HighLevelModeling.

-- AlistairCockburn