Software Has No Shape
Software Has No Shape(CategoryAntiPattern: Another one of those AntiPatterns; comments extremely welcome!)
I'm confused; JimCoplien said software has no shape in 1994, before he made his comments below on this page, but there's no indication from his comments nor elsewhere on this page that that's the case, or that he may have originated this term. What's going on???
I'm referring to "...one of the team members said, ``software is like a plant that grows,`` and Coplien interpreted this team member's comment like this: ``You can't predict its exact shape, or how big it will grow; you can control its growth only to a limited degree``"
A house has a shape, as does everything in it. It's possible to make a drawing of a house, or `subsystems' of a house (electrical diagram, plumbing diagram), so the shape of the drawing corresponds naturally to the shape of the house. Such drawings should be fairly realistic, or they don't feel right. (A bubble chart showing which rooms are connected to which other rooms conveys some information, but it's wrong.) TheMapIsNotTheTerritory, and treating the blueprint as the building can be taken too far (see ArchitectsOnBlueprints); but when used appropriately, blueprints are right.
Subway systems and electronics have literal shapes, and topological shapes. A subway map can look like any other map, or just show connections. A schematic can show all components, or the relationship between subsystems. (EE's do a much better job at coupling and cohesion than programmers!)
English prose has no shape. It has form; the parts have relationships among and between themselves. But there is no `picture' of a sentence or a paragraph that captures the essence of what's there. (Yes, you can `diagram' a sentence. Two sentences with the same diagram have little more similarity than two sentences with the same length. `Shape' is not a meaningful description.)
Software has no shape. There is no diagram, no drawing, no picture, that can capture as much of what's going on in a software system as a blueprint, subway map, or schematic can. If you're lucky, you might find part of your system that has a shape, just as the plumbing in a house has a shape. Just don't expect the shape of that aspect to be as similar to some `shape of your whole system' as the shape of a house's plumbing is to the shape of a house.
THEREFORE:
Don't try to `draw' your software system!
In particular, use CaseTools to capture some of your thoughts, to help force you to think about what you're analyzing or designing... but not to `draw a picture of your software system.'
(Or maybe this means we're doing everything wrong? That there's some description of `what a computer should do'that does have a shape? That would be lovely, but I'm skeptical. Some activities human beings do, including most writing, have no geometry.)
`Gentry was convinced that cyberspace had a Shape, an overall total form. Not that that was the weirdest idea Slick had ever run across, but Gentry had this obsessive conviction that the Shape mattered totally. The apprehension of the Shape was Gentry's grail.' -- WilliamGibson, MonaLisaOverdrive?, chapter 10, `The Shape'.) ISBN 0553281747
-- PaulChisholm
I think there is a reason that software diagramming attempts do not match the preciseness of many physical designs such as blueprints: software can transcend physical reality (at least of the "common world"). For example, in the old days we used the Dewey Decimal System to group publications. It was pretty good, but not perfect. For instance, it could not handle publications that connected multiple diverse categories very well. But now we can index and search on multiple categories and attributes. The physical representation of such indexes would be too messy to bother plotting physically. It would be a hair-ball. We thus have to abandon organization approaches that worked for physical designs and try other approaches and/or multiple approaches instead. -top-
Software has no Shape in the physical world. However, software can have shape in the mind of the designer. The extremely hard part is trying to represent that shape in terms that our mind can cope with.
An Art analogy: Architectural, mechanical and electronic visualizations live in the domain of Realism and Impressionism, while Software visualization is firmly rooted in Abstractionism.
Can we come up with general guidelines for interpreting Abstract Art?
-- ToddCoram
(No, we can't! And I contend most software has no shape even in the designer's mind. -- PaulChisholm)
This is terrific ! What is happening here is the drawing of an ancient argument: the apollonian versus dionysian, or, rather, whether software development is a discipline of the left hemisphere of the brain, or a playground for the right. That's the attraction, isn't it? Chemistry that is still part alchemy, science that requires art, description that begs for poetry, light that is sterile without shadow.
-- DonOlson
Perhaps the Shape argument is really one of representation and presentation. Rather than admit that Software Has No Shape, I would be more inclined to say SoftwareCannotBeModeled. (But, that would be flame bait..)
-- ToddCoram
Actually, not to go super-mystical on everybody, but this concept of no shape is pretty fundamental in Buddhism. In Buddhism, the idea that form is a completely human creation is the source of much suffering. That software development reflects this is probably no surprise...
What is Parts(tm), if not a picture of software, in much the same way that a blueprint is a picture of a house? The blueprint says "a door goes here"; it says "the electricity runs from here to here"; it says "the light comes from here".
Parts says "a listbox goes here"; it says "the click runs from here to here"; it says "the answer comes from here".
A common software model (should I write SoftwareCanSoBeModeled?) is the prototype. In particular, the "human factors prototype" has the purpose of communicating between people what the system will look like.
Merging the ideas of human factors prototyping, and incremental development, we get VisualProgrammingSystems.
-- RonJeffries
Of course software has shape! (In 3D - no less!)
Seriously, once I understand the patterns of a system I always "see" the software in my minds eye. The location of one component relative to another (in my mental image) depends on the degree of coupling.
The problem is how to make someone else see what I see.
-- ShalomReich
To me, non-OO, procedural programming has a 1 1/2 D shape, rather like music. 1D down the page, as sequential lines, 1/2D across the page. I, personally, can not visualize either music or standard programming well, but I know people who can, and very naturally. OO-programming to me is like hardware design - a 2D flow across and around the page. This I visualize very well and feel comfortable with it. I can see the computation and communication flow. So, yes, sw has shape.The original thought, though, dealt with shape as in, static 2D picture one can put on a CASE tool. This is less likely, but does not mean sw has no shape. See also SoftwareCannotBeModeled and WhatIsaModel.
Could you describe this better by chance? To me, OO is a BigSoupOfClasses with no pattern consistent from developer to developer.
See CategoryPattern for patterns used by many developers.
Many of these are OO-specific, or have relationial counterparts. I prefer the relational version in most cases. They are more dynamic, virtual, and compact IMO.
Many of them are found in object oriented software. I thought you just said object oriented software had no pattern consistent from developer to developer and was a big soup of classes. CategoryPattern is (for the most part) patterns that are consistent from developer to developer.
Are you implying that OOP was no good before patterns were documented by GOF? But one problem with patterns is that there are no decent rules for when to use what. Sure, the patterns have names, but very little documentation about exactly when to use them. For example, there are many approaches to MultipleDispatch. Is Visitor always the right pattern for multi-dispatch? If not, is there a concensus for when it is not? OO patterns are often just navigational schemas for the most part. One could give a name to every combination of schema layout, but that just creates names, not consistency. Naming alone does not result in consistency. [Perhaps this belongs under PatternBacklash or the like.] --top
I like this. Traditional musical notation, and the (commercially available) computer programs for creating music are analogous to procedural programming. See MusicShapes, because I'm wandering off topic. --Eric Moon
I have not yet met a CASE tool (although I have only used two) that allows me to build/draw what I see.
I am able to see multiple views of the same system but I haven't been found a CASE tool (yet) that allows me to do this.
I am not sure if the fault lies in me or in the tools I have used.
-- ShalomReich
If it lies in you then it lies in me too.
I usually have at least some aspects of a system that are to me are what the system is all about that cannot be described in the tools I have tried. Having studied the underlying language the tools are supposed to let you use I think the language (UML or whatever) is also is incapable of saying what I mean.
My problems usually arise when the crucial part of the design I wish to document is one of those transitive things that is both temporal and topological, and class generic, and object specific.
Damn straight, software has shape. The more defined shape it has, the more reliable and robust it is too. Functionality and efficiency are also substantially derived from the 'structural clarity' metric. If it's a soup that's just because your people wrote the OO equivalent of spaghetti. (Tomato with alphabet letters?).
UML is the problem. (Not just the infernal Rational tools). Having had several years use of diagramming tools and complex architecture I've ended up ditching the methodology. My conclusion is that UML is really a complete failure. Specifically it suffers from being an inefficient and mistargeted representation of the 'static' model and being misfactored/ inefficient/ awkward to represent the 'dynamic' interactions.
For a modelling tool or methodology to be useful, the Number 1 requirement is that you can model the dynamic collaborations. These are the most essential and most difficult to get right. If this can be achieved, all the other tasks are simple by comparison.
Relational is good (great). But I still want interfacing and inheritance features.
Software has shape. Yes, it does. I believe it errs in the other direction. (And even if I'm wrong, this should stir up trouble.) It has too much shape.
Unlike a blueprint, subway map, or electrical schematic, the standard software descriptions suffer. They suffer because a blueprint, subway map, or electrical schematic conveys (almost always) almost all of what one needs to know in order to think about the house, subway or circuit in question. For these, what one needs to know is almost always static in nature.
Software has not only a static shape, but in addition a significant dynamic shape. If you don't understand a program's dynamics as well as its statics, you have missed much of what you need to know.
The only sense in which I can believe that software has no shape is if one requires a static description to deliver a complete understanding for something to "have shape". Because software has no such reasonably encompassing static description, under such a (limited, in my view) definition of "having shape", one could claim that it has no shape.
So, sure, software has shape. In fact, the sucker fairly wriggles with shape. Galileo was right, it moves. -- ChuckSiska
Tesla is known for having been able to visualize the science behind his engineering models. He built devices, mostly lightning generators, the scale of which has hardly been duplicated. What he pictured, in his mind, was not the physical form of the device but how the device could be created so that it's physical properties would give rise to the dynamics of the process that made it and do something interesting (i.e. create millions of volts of static).
Creating software is a similar process. It is multi-dimensional, having "n" directions it can be measured by. Software captures, stores, and manipulates information that is (most always) representative of something outside the context of the software itself. Its shape, therefore, is always an attempt to mimic the original within the confines of the available tools. A flight simulator is a good example of this, a computer program has little to do with actually flying a plane, by allows you to explore the real experience through a modeled, controlled representation of the real flight.
-- Brent Van Allen
I think whether software "has shape" may have more to do with the developer than with the essence of software. I used to have mild synesthesia (I saw music as colors, attributed gender & personality to numbers and so on). I still see some ideas as shapes; one of the ways I define a design as "elegant" is if the design's "shape" is simple. I'm confident that the shapes I see in software would mean nothing to anybody else.
Fred Brooks, in the expanded MythicalManMonth (p. 217 of the 20th Anniversary edition), argues that a good developer will have an immediate, instinctive answer to the question "Where is next November?" I make no claims to superiority, but I do have the instinct he describes; my answer is "Down and to the right."
Hmmm, this mental/spacial mapping stuff is really popular in one of the pop psychologies; perhaps NLP. Or maybe it's just Jungian. One dimension is past versus future; I don't remember what the other one is, maybe recall versus fabrication.
The quadrant is further parameterized by personality type: through-time people organize time in their heads spatially left-to-right, and in-time people map it back-to-front. Through-time people roughly correspond to monochronic orientation; in-time people roughly correspond to polychronic orientation (well, these are words that Alistair likes to use). These, in turn, map roughly onto some MyersBriggs personality types.
I might have a lot of the details backwards, and if you know better than I, you can change things and delete this sentence.
There are pseudo-psychoneurologic indicators you can use to explore this mapping, like asking someone a question ("where is next November?") and watching their eyes move ("down and to the right"). (I had a battery of neuropsychological testing last January and, though the stuff is spooky, it all has a widely accepted, recognized and sound basis and is an amazingly powerful diagnostic tool.)
And, by this model, I can well believe that next November is somewhere on the right, but I don't remember whether it's up or down (which probably says something about some neuropsychological scrambling along that axis somewhere inside me :-) )
By this model, I don't know if software has shape, but I'll bet that most people attribute at least some parts of it with at least some spatial orientation.
-- JimCoplien
I absolutely agree with this one. The comments above have ranged all over the proverbial map, so let me add one more: SoftwareHasNoShape because _life_ has no shape. A software system "lives" in the mind(s) of its designer(s). It's no coincidence that new programmers have to "get a feel" for a software system. Having fulfilled the role of "chief designer", and having had to try and communicate the design of a system to others, I have come to the conclusion that the design of a large software system does not completely exist on paper, nor even in the complete body of code. The design of a large software system exists in the mind of the designer. Views of it can exist outside the mind of the designer, and these views can be given shape, but it's impossible to give the entire design a shape. -- James Clover
SoftwareHasShape. --RonJeffries
Whether software has shape depends on how you define the terms it seems. Kinesthetically, developers can have a subjective feeling of shape; metrics can be projected from finished or in progress software as shapes; psychometrically you can extract a "shape" from the minds of the programmers perhaps. But software isn't blueprintable, which was the original assertion; you can't create a shape and say "here is the software's shape; go write it" in the sense that you can with a blueprint say "go build it". Software's shapes are derivative and descriptive, not generative and prescriptive. Except perhaps for the one in the developer's mind; that may tell us that there could someday be the potential for software blueprints. --Dana Anthony
If you look at what it really takes to build a house, there is generally way more than one blueprint. And a house is infinitely less complex than nearly any piece of software.
There's the elevation plans showing what the house looks like. There's the floor plan; the electrical plan; the plumbing plan. And don't forget the building codes, which are included by reference in all blueprints. And most people don't blueprint the decorating plan, they just nod at the wallpaper selections.
My son is a brewer. He's helping his company build a new brew pub.
The pub is being built in an existing building. No one noticed on all the plans that the drawings for the building were two feet wider than the building actually is, until the builders started having trouble getting the rooms to come out right. They had to refactor the design.
When the Primary School I was refactored (lots of extensions and the like) we got copies of the plans and as a year long project we got to make scale models of the school. As above the side elevation made the building longer than the top-down blueprints did. What is the lesson we have learned? ThisHappensAllTheTime?
No one noticed on all the plans that there were no utilities planned for the brewhouse. He noticed when the other utilities were roughed in that there were none in the brewhouse. They had to refactor the design.
I would far less expect one diagram to define a software package than one diagram to define a house ... but I would expect that diagrams could be drawn that defined as much of the software as one wanted.
The diagrams will be easy to draw and easy to understand to the extent that they reflect the "true shape" of the software. Because SoftwareHasShape. --RonJeffries
Software has no shape. Shape is about how the beholder partitions their experience, not a property of any experience. I see this same issue played out by the folks trying to manage stuff- like projects. They produce (often secreted in a closet) a perfectly understandable project plan, which represents the shape of the undertaking for them. The plan, however, confuses others more than it informs. This is a Gestalt concept. Shape-finding is an act of discovery. Those involved in the discovery get it. Those not involved (or not indoctrinated in the shaping language don't get it in the same way. And they can't. [1] -- DavidSchmaltz
One of the conceptual watersheds in the Renaissance was Alberti's way to show 3D scenes on a 2D painting or drawing so that the eye was fooled into seeing 3D. In a word: perspective.
One of the key developments in engineering was the discovery by Monge of (1) a way to show 3D things using 2D paper and (2) a way to use compasses, set squares etc as an analog computer for 3D shapes. Add an array of specialized glyphs and conventions. From this came a whole discipline of mechanical and technical drawing.
I've spent most of my career looking at notations that might have a similar effect on the analysis and design of software. A key question is finding ideas in software that correspond to spatial dimensions in hard engineering. This would make layout (shape) significant. Rob Witty in the 1970's had a key thought and produced working tools in the 1970s.He used one dimension for time and one dimension to show parallels/alternatives. http://www.csci.csusb.edu/cgi-bin/dick/bib?from=SoftwareHasNoShape&search=Witty77b
I prefer three dimensions: sequence, selection, parallel. It gives a definite shape to software but I have no evidence that it would help anybody but me. Even I find drawing and changing 3D diagrams time consuming. --DickBotting
What about sequence, selection, iteration (the canonical structures used in NassiShneidermanDiagrams ) ?
Some people claim that SoftwareHasNoShape is the reason that computer languages that use plain text source code are currently so much more popular / useful than GraphicalProgrammingLanguages. People that claim SoftwareHasShape explain that fact by saying that will change once we develop good graphical editors.
-- DavidCary
I think we're playing semantic games here. I would tend to agree with the original statement if it were rephrased "Software Has No Intrinsic, Single, Objective Shape" (or something like that). Some folks don't "see" a visual/spatial aspect to software; others do, in a wide variety of different ways. There is no right answer, and it is counterproductive for one group to argue that the other is "doing it wrong."
Personally, I am very visually oriented, and work better when I can use a variety of different visual tools and forms. But I see this as a stylistic preference, not a panacea, and I also strive to make my code and text documentation clear and concise. -- AndyMoore
The shape of software is Just A View?
Software has no smell either, but that doesn't keep you guys from smelling it. --BruceIde
Shrek: For your information, there's a lot more to software than people think. Donkey: Example...? S: Example?? Ok....Umm, software is... like ogres! D: It stinks?? S: Yes! - NO! D: Oh it makes you cry! S: No! D: Oooh, you leave it out in the sun it gets all brown and tart sproutin' little white heads! S: No!! Layers! Software has layers! Ogres have layers! Software has layers. Ya get it? We both have layers! D: Ooooh, you both have layers.... ... You know, not everybody likes ogres... Cake!!! Everybody loves cakes! Cakes have layers! S: I don't care what everyone likes!!! Software is not like cakes...
Just about every piece of software can be represented as a huge graph (network) of interconnections (although a graph may not be the only way to represent it.) If we actually drew such a graph, it would be far too complicated to be useful for a vast majority of software professionals. Thus, we need to form ways to navigate and/or understand the system without having to simultaneously grok the whole shebang. One approach is to look at different aspects for different uses or viewpoints. A flow chart might show one aspect, an EntityRelationshipDiagram another, etc. Another approach is to follow specific development methodologies. If we know that system X follows methodology Y, then we have an idea of what to look for and how it is organized. The "graph" will follow a certain pattern or set of patterns. Each different aspect view and each different methodology will have a different "shape". -top-
All software can be represented as a square wave. -- bottom
Not a literal infinite unmodulated one, it can't. Maybe you mean a variable duty-cycle square wave?
I think he meant in the sense any waveform can be produced by summing square waves of the proper amplitude and frequency. (Questioning glance to original author)
EwDijkstra faulted us all (maybe himself too) for imprecise language, using anthropomorphisms, etc. And what's a drawing, after all? -- BobBockholt
The time it takes a ball to drop from a height has no shape, yet we impose a shape on it, a parabola. The position of a valve in a control system reacting to a temperature change has no shape, but engineers graph all sorts of Bode plots when talking about it, that have lots of interesting shapes. The head loss in a pipe doesn't have a shape, but the Fanning Friction Chart is embedded indelibly in my brain.
On more of a software of a software tangent, we can sometimes present a physical database as a stack of table definitions, or we can put up an ERD. I find that lots of times I can stand about four feet away from an ERD and see operational characteristics of the system from the shape of the diagram. Similarly, I can often see the general intent of a software system from the shape of an UML. A given peice of software doesn'thave a _single_ shape. There are lots of potentially useful shapes in a system.
There are useful graphical representations of lots of things, including software.
-- SkipSailors
SoftwareDoesHaveShape?. Beautiful or ugly as it may be.
See also: LifeIsaBigMessyGraph
EditText of this page
(last edited December 10, 2014)
or FindPage with title or text search