"What do you lack that they have? A diploma." -- The Wizard Of Oz
What do engineers have that we don't, but wish we did?
Two things that I really envy civil engineers:
A common understanding of acceptable practice. You don't get to be a civil engineer unless you persuade working civil engineers that you know what you are doing and can be trusted with other people's lives. I have no idea how to certify software competence; every attempt I've seen has certified platform knowledge [$$$], at best. I don't think we understand what we're doing well enough to certify it yet.
Review boards. When a building falls down, a review board is called in to figure out why and update the acceptable practice so that it doesn't happen again. In software, we bury our mistakes; when a $10-million project is cancelled after coming in 2 years late with unusable deliverables, everybody says "That's software for you" and moves on to do something else. But is it possible to have a review board before you have a common understanding of acceptable practice?
Something external and objective to test ideas against. See Discipline Envy. Most software engineering metrics are too closely tied to psychology, and psychology is a very immature discipline compared to chemistry and physics. See Most Holy Wars Tied To Psychology. -- top
I think that we, as a discipline, are missing an invaluable learning opportunity because we don't have formal Post Project Review(s) on all projects, successful and unsuccessful.
Credit: This idea first came to me when reading Why Buildings Fall Down.
Discussion:
Is it possible that these two things are easier to bring about in disciplines with more stable user expectations? I may be very wrong here, but I feel that the answer to "What can software do?" has changed rather significantly over my lifetime, but the answer to "What can a building do?" has stayed much more stable. If a civil engineer stumbles across this page, I'd be very interested in their thoughts. -- David Saff
One thing that software does not have is recourse to natural laws - a civil engineer can always make a beam slightly smaller, and s/he knows that it will behave almost the same as the thicker one. Software seems at times to be chaotic - slight changes in the initial conditions have great and unpredictable effects on the outcome. And few customers of a building want as many structural changes as software customers want - they know it's hard to change concrete, but software is Only Ones And Zeros.
-- Pete Hardie
Exactly, because software can only simulate a beam of light...provide a metaphor for light by exploiting a video monitor. The simulator is not the beam of light, so it acts unpredictably. It does not have the nature of a physical beam of light. However, we can write software that controls a real beam of light, but even that method of control will be another metaphor for some phsyical kind of controller. The software can never be the phsyical entity it models. It will be cool when software starts creating new constructs that aren't even based on the physical world. This has started but is still in its infancy. -- rad
Yikes, no! Small changes in engineering can have radical effects on not only the structure itself (how about that bridge that collapsed, simply because they added a small windbreak for the pedestrian traffic?) but things around it (an entire city situated on an island, connected to the Oregon Coast by an isthmus disappeared when the Army Corps of Engineers put up a seawall for a neighboring harbor). Oftentimes these civil engineers don't know what their changes will produce, of course these results may be the most dramatic, and thereby get books written about them, whereas software crises seem much more common. I think this whole discussion misses the point that we can never be like civil engineers, everything we do, succeses and failures, rarely is even widely known within an organization, let alone to the world. -- anon
One thing that software does not have is recourse to natural laws... -- Pete Hardie
Isn't information theory subject to, or even part of, natural law? And don't we regularly exploit the continuities of that discipline? I'm striving to put my finger on just where software departs, and I know that it does. Can anyone help me?
Everthing we develop in software is metaphorical. Every software system is representative, symbolic, or analogous to something else physical. This doesn't mean it has to look like something else, just be a level of indirection to it - an interface or a conduit. This is the essential difference between Software Engineering and almost everything else in Civil Engineering. Software must be metaphorical. Other mediums, can be, but don't have to be. When a Civil Engineer designs a bridge, it is a real and tactile bridge and people can move across it. It is not a metaphorical bridge or a representation of a bridge. It does not symbolize a bridge. I went off on this for a while in Architecting Word. For example, Quicken provides a metaphor of your checkbook (i.e. your actual Checking Account not the timy pieces of paper that are themselves an indirection). A Wordprocessor provides a metaphor for writing a document. Even a real-time control system is metaphorical of the system it is controlling!! For me, this is something that is very unique about software, maybe its most unique attribute. It is always indirection. Software inhabits the machine. It is never tactile but it may control something tactile - indirectly. It may enumulate, be analogous to, or mimic something tactile (even as much as in Virtual Reality) or not, but it is still an indirection. The software system itself is never the entity or process it is representing - software is never the final intention. It is always the metaphor of something else, like a payroll system or a 401K plan. This doesn't mean it has to look like or emulate a traditional payroll system or 401K plan. That misses my point. The point is that you can look through the software to the payroll system. This is the really wonderful thing about Software. Software is allegory. Here, allegory refers to characters, user and programmer interfaces, and expression that represent abstract ideas and concepts. -- Robert Di Falco
A computer program is a blueprint for a virtual machine. The computer automatically translates that blueprint into a machine. The machine obeys the physical laws of the computer. What makes software seem different from a bridge is our repeated misunderstanding of it - we keep thinking that the software is the machine itself. -- Anonymous Donor
This is exactly why I say that software is allegory. We can't even describe it without entering into allegory. This is why we say virtual machine, it's not a real machine - only the hardware is a physical and tactile machine. Software by definition runs in the allegorical world - its home is metaphor-land and its strengths are indirection!! Cool. If we build a bridge in software using a Bridge Pattern or are making a virtual bridge in a game - two VERY different things - neither is tactile, a person cannot walk across it. Both are created to represent something else. To provide a view on to some other concept. Only ideas, objects, or virtual characters can span our software bridges. This is cool, something to be embraced. Software is always a tool. Nothing else resembles this aspect of software in that it is only used for indirection. I can't think of a single entity in the software realm that is not symbolic - that is not a concept. If we think about the hardware that runs software, we can find reality, but not in the software itself. It's just ideas. I almost prefer to use the analogy of allegory or the analogy of metaphor but both work well for communicating that idea of indirection. -- Robert Di Falco
Always expect what I write to change as I refine my wording and ideas... I don't have my mind made up about anything and am constantly evolving my points of view. -- The Empty Rice Bowl
Robert, I think you're close with this, but I'm still missing something. While it's true that Quicken used to be a metaphor for my checkbook, it now is my checkbook. The difference is just some network links. And while a real-time control program may use an internal model of its environment, I believe the control mechanism is just that, not a metaphor for a control mechanism. But I definitely see the rampant use of metaphor in what we as a programming community tend to do when we ply our craft (and talk about it). I wonder: is the metaphor essential, or is it maybe a large part of what stands between us and credible engineering?
Thanks for your generous contribution.
I understand The Map Has Replaced The Territory, but this isn't the case in Quicken. I'm going to attempt to peel one layer at a time since there are so many ways to view metaphor and something like Quicken actually uses them all! First, is the most outer layer - the relationship between Quicken and the look and use of a traditional Checkbook. Most of us use Quicken with our Checkbooks. We haven't ceased to write any traditional checks, just fewer. Even when Quicken does completely supplant the Check Book and move on to not simulate the Check Book in its user interface, there are still other, even more important metaphorical attributes of Quicken. The next level to this is the balancing of our checking accounts. Quicken has indeed replaced the manual way of balancing your checkbook with a paper and pen. However, that doesn't stop Quicken from being a metaphor of your checking account. We have to go in another layer to see that even the tradition paper based ledger it replaces was already just a device we could look through to see what is at the bank. So, Quicken did what commercial products sometimes do. They replaced an existing metaphor with a much more powerful, software based one. Unfortunately, they chose to emulate the old metaphor in their User Interface. However, the important point I'm trying to make is that while Quicken may base its look and workflow on your checkbook - both the check book and Quicken are really just metaphors of your banking data. Go to the next layer and we find that what is at the bank (their software, databases, and paper ledgers) are just a layer of indirection to paper money. Is there yet another layer of indirection? Of course. I'm sure everyone has guessed it. It is the paper money itself! Money is simply a symbol for the exchange of goods and services. So, even if we go to a system devoid of paper money, even the electronic records will be markers and not the final layer. Just a different metaphor. Just a better way to represent the exchange of goods and services.
It seems to us like a real-time control system is more than just a way to interact with (i.e. monitor and control) physical sensors and actuators. But no matter how complex the control software becomes, it will never become the physical sensors and actuators. Software will always be a level of indirection to something else. There may be fringe cases, but as a rule, software only exists to model or provide a way to control something else. For me the best software designs are those that recognize this and view themselves as allegorical - lots of symbolism, characters, and events - instead of a world unto themselves. -- Robert Di Falco
..is the metaphor essential, or is it maybe a large part of what stands between us and credible engineering?
Walden, I'm not even sure what this means. What is credible engineering? Do you mean good software engineering? I have no idea. However, I think what stands between programmers and great software systems is ignoring the metaphorical attributes of what they do. Don't confuse this with Architectural Style's, System Metaphor, or even the emulation of real-world entities. This is not what I mean when I say metaphor or allegory. Most software developers get so caught up in what they are creating that they loose sight of the fact that they are creating a conduit. They begin to think their software is the finality. Loosing sight of the fact that they are providing a representation of something else, like a 401K plan or payroll system, immeadiately hurts the user. The user does not care about your software, they care about what your softare allows them to do. This doesn't mean that a word processor must look like a piece of paper. That's missing the point. Rather, it means that the designer of the word procesor should understand that they are not writing a word processor but are designing a tool for writing - something that will serve as a conduit for the human process of writing. -- Robert Di Falco
Robert (Rob?), up above, you said "Nothing else resembles this aspect of software." But here (just above) you've discovered that monetary systems have been that way for a long time. I'll go with your later discovery; software systems are not unique for their generous use of symbolism.
A generally accepted and modern definition for "engineering" is "the use of science or scientific method as applied to building things". The fact that software developers are "building things" is not worth challenging, but the use of scientific method certainly draws doubts. The Tarot reader recently pronounced that "everything will be okay" in my family, but I don't put too much stock in that. The reading, by the way, was based on level after level of metaphor, most of it well beyond my intellectual or spiritual means.
I think what I come away from this with is as follows. Much of what we build computer systems for is stuff where human thought reigns without any solid mass to evince it. The fact that someone walked through my front door five seconds ago is a critical piece of information to the home alarm system, but go look for some physical state that that represents, and you won't find it. We imagine the concept of time, and create symbols for it. Human symbology is imperfect, and subject to perversion by minds that insist on "seeing" things in a way that suits the current (often survival) purpose. This is just a human condition, not a computer thing...
Enter the computer. What do we use it for? To record transactions, count how much time elapsed since a particular sensor was activated, etc. In other words, we use it to extend our own memories and temporal awarenesses, stuff that's already a sea of uncertainty. When software developers talk architecture bullshit (some do, admit it) they're doing the same thing the Tarot reader does, but directing it towards the building of software. I repeat: Is this necessary?
"All the world's a stage." That's metaphor. The speaker didn't build the world, nor did he build the stage. He just equated them. You make a distinction between the software and the computer, the computer and the sensors and actuators. What are we talking about here, just software? If so, software alone is not a metaphor for anything. And at best, when Quicken pretends to be your checkbook, that's purely intentional on the part of the Quicken builders. So it's not metaphor, it's "metaphor". Know what I mean?
Thanks for an interesting discussion.
Robert (Rob?), up above, you said "Nothing else resembles this aspect of software."
I prefer Robert, thanks for asking most people don't and end up calling me Bob (which is fine for some Roberts). First I should have said - nothing else in Civil Engineering. Most of my initial comments were meant to be compared with traditional engineering and architecture. But even so, what I meant is unique is not that software systems can be representative, it is that indirection is an immutable attribute of software. Anything can be used for indirection to something else. Software is unique in that is almost always is this. (Clearly, I'm not talking about electronic pulses here.) I think as designers we too often mistake our software for the final subject matter instead of a representation of it. As Tom points out, a great analogy for this is mistaking money for value. -- Robert Di Falco
...but go look for some physical state that that represents, and you won't find it
Actually there is and it is staring us right in the face! It is someone walking through my door. That is the state the software of your alarm system is representing. -- rad
So it's not metaphor, it's "metaphor". Know what I mean?
I'm not sure. But I do NOT think that metaphor, symbolism, or indirection means that a software program for playing CD's needs to look like a Stereo System. Not at all! It does mean that a good software system for playing audio will do an excellent job of symbolizing the users interaction with the audio stored on that CD. Further, it will understand its role in this. Because it understands this, it may even do such a good job that the user forgets the audio files and the CD altogether. This is what I meant when I said Quicken isn't representing your ledger, its representing your account activity. Is this what you mean by "metaphor" as opposed to metaphor? -- Robert Di Falco
Well I'm confused. A couple of thoughts:
Computer programs are real, they have physical existence as electrical potentials in circuits. We may 'think' in metaphor when we design and build software but the software still has physical reality. I assume this is not really the reality under discussion. Certainly most software development models a system. In many cases this modelling is so important that the software 'becomes' the system, this can happen in other metaphorical systems, too (The confusion of 'money with value' led to the collapse of the Spanish empire).
So we are talking about two relationships with reality:
Software's physical reality (electrical and magnetic fields in circuits and media) and its metaphorical reality as a metaphor? The first is not interesting to most software developers except for performance and sizing exercises - The last 'make it fast' stage of software development - or the odd pissing match. (I think Robert missed this one; his description of software seems almost dualist.)
Software's metaphorical reality or how well it models something for us.
I think the problem with most software development is that it's a metaphor for a metaphor for a metaphor. Layer upon layer of systems built by arbitrary decisions before the software engineer gets a look in. A payroll isn't real (it's just a load of squiggles in a book that maps to another metaphor, monetary payments. That's one of the reasons that it is so hard to become a domain expert and why so many users don't know what their system should do.
That may also be why real-time mechanical control developers and business system developers have so many communication problems. One works with maybe two levels of metaphor, the other with dozens.
My head hurts now. -- Tom Ayerst
Tom, you took the words out of my mouth with that last bit about real-time mechanical control. I was thinking as I was writing above that these systems have something special, as compared with the rest of software systems, and you've explained what that is. -- Walden Mathews
To take the thought further this may be why some programmers like languages such as C and C++ where they can drop into 'close to the metal' mode. In this mode they stop having to worry about interpreting someones interpretation of a business metaphor. Building a better threading library is hard, but the victory conditions are more obvious than understanding the implications of reimplementing soft-dollar vs hard-dollar charging regimes in a pure-agency, correspondent trade flow (to take an example close to my heart).
I'm tempted to make some comment about Smalltalk developers managing this better but I won't. ;-) -- Tom Ayerst
Off-topic request for info: what is "Quicken" and what is the "balancing" of a cheque-book?
See What Is Quicken
There's much discussion above of metaphor. Bringing this back to the topic Engineering Envy, it occurs to me that in other engineering fields, it's possible to dispense with imprecise, metaphorical reasoning when deemed necessary, and I'm not sure we can do that in software, but I wish we could. The metaphorical application of software-based products (like thinking of Quicken as your checkbook) is not the issue. The issue is whether we allow fuzzy, metaphorical thinking to crowd out semantically precise specifications when we're making software. Precise semantics is harder, so our bias should come as no surprise. Please see What Is Metaphor.
Much of the discussion above should probably be moved to a different page, or deleted. Tom and Robert, would you care to summarize?
Discussion has lapsed. I may be restating some of the thoughts above:
In an increasing number of cases (typically Real Time environments) software is being used in a real Engineering sense. If the firmware used to control a car, pumping station, or other critical system is screwed up, then you get the real life equivalent of collapsing bridges and falling buildings (differing only in scale).
Yes, Software Is Modeling, and software is really only an abstraction of the related reality, but because of the "leverage" provided by electronic controls (think servos and relays), the amount of First Domino voltage is at or below TTL. This means that the signal resulting from a "store" (or "out") instruction can cause real life events (open doors, raise/lower elevators, open/close valves, etc.), making it the unique case of map-controls-the-territory.
Consequently, it becomes necessary for programmers (some, at least) to think and behave like engineers.
I currently write firmware that gathers and relays data in Near Real Time. It's not mechanical control, so if I screw up nobody dies, but my employers or their customers stand to lose substantial sums. The risks are "only financial" but clearly it's worth adopting an engineering approach to counter those risks.
Some software has no real world risks (e.g. games - never mind impacts on vision and tendonitis), while some has fairly low risks. Some software companies recognize that it's possible to draw credible causal relationships between their software and real world risks, and so write ponderous disclaimers as their way out of that.
As software becomes more and more embedded in the real world, its practitioners must become engineers, if not in name, then at least in practice. Some common understanding of acceptable practice is, or will be, an unavoidable requirement. I understand (first hand) the problems in defining the complete set of criteria for validating given software, but when it controls your car's brakes, you need to get it right.
Like I stated above, if a bridge falls down, everyone knows, it's on the news, in the paper, etc. If a software project fails (or succeeds) many, many times, hardly anyone knows. Everything must be hidden behind a cloak of intellectual property, copyright, trade secret, and Non-Disclosure Agreements (or another country's equivalents). We can never have the same accountatbility, or even work the same way as civil engineering while we function in this way, so why bother trying to make the comparison? I'm asking a legitimate question here, if someone knows a valid reason that engineering is a good metaphor for what I do (my resume and job title say Software Engineer after all), I'd love to hear it.
Wow guys. Great discussion. I'm not a regular visitor to this site so I don't know if I'll be able to read any of the follow-ups to this post, but wanted to add this.
Remember, we could all be brains in a jar!
As a software engineer, we manipulate the states and rules that define our cyber-worlds just as civil engineers manipulate the states and rules that define the "physical" world (though generally they have less control over the rules). But of course the physical world may just be someone else's cyber world. There's no way to really know and I don't think it really matters. We *know* that both worlds, what we call physical and what we call cyber, exist. They are sets of rules and states of quarks/electrons/bytes, and that state is held in someone's computer or someone's mind or someone's space-time manifold or elaborate system of strings and pulleys; which in turn may be hosted in some other mind/computer/space-time manifold.
You suggest that the work of a software engineer is less important and visible than the work of civil engineers. This is generally true, probably because the world of buildings and bridges is still so important to people. But in the future what we are currently calling the cyber-world may become more important that what we're calling the physical world; as more and more important stuff, such as bank account balances and google page rankings becomes housed entirely within the cyber world. We may end up spending more and more time in virtual reality, hooking wires to our brains. The singularity may arrive and every bit of matter in the world may be refined and converted into a sort of cyber-soup in which intereseting things like people and bridges are represented much more efficiently as arrangements of light and electrons instead of the gross old-fashioned way of representing things as arrangements of atoms and molecules (such a waste of space!). Or we may find a way to hack into the computer that is hosting our physical universe and learn to program bridges into existence.
See original on c2.com 