In the beginning, there was the flowchart...
Software diagramming - a warning from history
Ensure Ease of Recovery with Asigra’s Agentless Software
Stob
Those who can, do. Those who can't, make those who can draw a picture
My first effort in instructing computers, about 30 years ago, was drawing a flowchart. Here it is as I remember it, albeit without the smears and crossings-out with which my 14-year-old self doubtless decorated the original.
We were unconstrained, in those far off days, by such piffling issues as web interface, unit tests, or code efficiency. Nor did we have to contend, as did some of my luckier contemporaries, with complex systems where punched cards were sent off to a local bureau.
The fact was we simply had no hardware at all, unless you counted the clear plastic stencil that had to be bought from WH Smith's. The only opportunity we got to exercise our "code" was by slogging through a "dry run", a notably unsatisfactory exercise involving an imaginary computer. It was, to borrow a crisp, vulgar phrase from Robert Robinson, "...like losing one's virginity without having the f*ck".
When a school micro finally did arrive, a year or two later, those of us who had been bitten by the programming bug gleefully threw our inky stencils aside and proved we could tackle non-Radox problems without diagramatic props.
But after that uninspiring formative experience, I have tended to be suspicious of those who would oblige me to make pretty pictures when I should be banging out code. This article is a record of how those suspicions have panned out.
Again with the flowchart
Flowchart worship persisted long beyond the point where even British management might have been expected to spot they were rubbish. In the mid-1980s, I watched from a safe distance as a colleague attempted to code up an entire application from a flowchart specification. This massive document, beautifully hand-Rotringed on best engineering paper, was hundreds of pages long. Its pages all looked something like this:
Only much bigger and scarier. Any sense of structure of the original program had, naturally, been entirely suppressed.
My colleague operated a dual coping strategy to deal with this monster: during working hours she wept delicately and persistently; during the lunch break she scanned the job ads. I don't believe the port was ever completed.
During the late 1980s, the flowchart was at last jeered out of software development. A host of alternatives competed to occupy its throne, usually proprietary and usually associated with an expensive CASE tool. Although some approaches really hit the spot - for example relational database schema design - a lot of other diagramming techniques just left you with the sensation of being lectured at.
For example, there was something called the context data flow diagram. The version I was taught comprised a single circle, surrounded by labelled arrows. A hypothetical clearing bank system would look like this:
Other not-terribly-good diagrams I was obliged to draw at around the same time were structure charts (I think these were just function call hierarchies); thread diagrams (dull short stories expressed as data flows) and, a little later, class hierarchies.
These last I believe were a hangover from Smalltalk, and when first introduced (always as an IDE feature called a "class browser") were thought to be a vital prerequisite to any OO development. It took a while before it was noticed that nobody used them. This realisation may have coincided with Borland releasing a version of its C++ framework called "OWL". Previous class libraries had displayed as elegant inverted "V" shapes. But this particular version of OWL, the first to make extensive use of multiple inheritance, looked like a basket of wool that had been romped in by an exceptionally lively litter of kittens.
It was enough to put you off your templates.
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Next page: State of the art
COMMENTS
Agree that state diagrams are useful
I recently blogged (at http://outofthetriangle.wordpress.com/2007/07/25/learning-uml/) about finding state diagrams to be one of the most useful parts of UML and I’m pleased to see that I’m not the only one that feels this way. I also agree that, beyond a certain level of detail, diagrams cease to be useful as you might as well write code!
To Simon
I didn't say you could understand design by reading that paper. I said you could understand the relationship between design and code by reading that paper.
The source code is a design document. You have a stereotype of what that belief means, but it is simply a valid way to look at the software design process. Why should an untestable and unvalidatable way of representing a design be taken as an absolute?
I never claimed that source code was the whole design. I never said that learning to code is learning design. But you have a stereotype of programmers that implies that simply because we often treat the code as a design document (whether we see it that way or not) we can't have any clue about design. That's absurd.
Truth is that most programmers have learned the limitations of the usual design documents. They too are, of course, part of a good design method, but to insist that they are accurate and complete without any real attemp to test them is just stupid. It's something that no other field of engineering would tolerate.
As it happens, I have worked in an environment dominated by hardware engineers. I was struck by how many prototype-test-redesign cycles there were. How many arguments there were about unreadable and confusing design documents. How the way those documents got that way was, essentially, from many cycles of debugging. And how, after going through all that, it would often be the software guys responsibility to work around the bugs simply because there was no time for another hardware design debugging cycle.
In other words, if you allow that the source code is a design document, you suddenly find that what programmers do is exactly the same as what engineers everywhere do. Create designs, and go through cycles of testing and refining them, sadly being forced to stop short of perfection by time and economic pressures.
Obviously a language reference manual tells you nothing about how to create a design, just as the autocad user guide tells you nothing about good design. But then, the vast majority of professional programmers know that too.
As for binaries being design representations, of course that's simply not true. Though assembler can be. The point is that a design document must contain human readable design explanations and rationales. Compiler output obviously doesn't achieve that, but any half-decent programmer spends a lot of time adding information to the source that only benefits human readers.
Code is Design?
A program listing is a document that represents a software design. Compilers and linkers actually build software designs.
Jack Reeves
A program listing is a set of machine readable instructions written in a 'computer language'.
If a program listing is in C++, Java, C# et al is a design so is a listing of assembler instructions whether it has been written by a human or been disassembled from an anonymous binary.
So a hex dump of a binary in a text editor is a design?
So using Jack Reeves 'suggestion' we can conclude that:
The compiler and linker are only translating one representation of a design into another representation of the same design.
If a UML model representation of a design is a machine readable design document that can be directly translated to what a CPU can process then the MDA brigade have reached home.
It is so easy!
All that is required to 'really understand' a subject is to read a paper.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
