Software Aesthetics 748
cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.
complexity (Score:5, Interesting)
The bridge analogy you mention is frequently quoted. And I agree, standards in software design & implementation need to improve - particularly in the shrink-wrap world (I happen to think that in-house bespoke systems are generally better). But the standard response to your standard analogy is that any non-trivial application is hugely more complex than a bridge.
The design of a bridge is basically the extrapolation of a few well known engineering principles to the scale you want. It has 2 requirements : (1) It must reach from one side to the other and (2) it must not fall down. You may have noticed that software is not like that
I remember reading a quote from a famous software scientist (I forget who, maybe Turing?) who said (and I paraphrase here) that we shouldn't be teaching our your computer scientists maths, physics, engineering etc, but rather art and biology. Because programming is an art, it's the creation of something from your own imagination, not like engineering which is simply applying rules. And once created, any large application behaves far more like a living organism than a machine, it grows, it evolves and (often) it gets ill. I always liked that idea
nice, but welcome back to the real world (Score:3, Interesting)
The bottom line is, software isn't a bridge or a house, people don't trust their lives to my software. If I made software for the medical field or something like that, yes, I would have a different view. But the fact remains that you should only make it bullet-proof when you need to, because you never have time to make everything bullet-proof.
Re:I Can see the point... (Score:1, Interesting)
some suggested resources (Score:5, Interesting)
This article is very interesting; the idea of code as an art form isn't new, but this article certainly is aggresive in encouraging it.
But what about "Extreme Programming" - doesn't it encourage the same thing, in terms of self-commenting code? Or does its specific nature essentially negate that aspect?
If you ask me... (Score:1, Interesting)
And BTW, did anyone notice that this guys code snippets are in Basic? That's enough to dismiss the article right there!
virtues of programming? (Score:2, Interesting)
From the article, describing building a new VAX program from scratch:
In each case [of rewriting an existing feature in VMS] our reason was hubris, ignorance, or laziness to learn more about the computer we were using.(emphasis mine)
Unfortunately, the first thing I thought of when I read this quote was Larry Wall's infamous quote describing the Three Virtues of a Programmer: laziness, impatience, and hubris......
(just a FWIW, NOT flamebait!)
Good software takes time (Score:2, Interesting)
Of course it also depends on your staff, if you don't have the expertise to begin with this process will either take a lot longer or may never happen if it is so poorly designed in the first place.
Wow, good one (Score:2, Interesting)
Listen, most people wouldn't know good design if it bit them in the ass. Ask people if they think the design of a Ford Explorer is good. Probably you'll just get a shrug, "Yeah, I guess." Maybe someone a bit more knowledgable will give you somewhat more detail. So don't go with the "laypeople will be horrified" bit. It's obviously not true for other industries -- why would it be true for software?
Of course, probably most cars *are* pretty well designed. Why? Because it's EASIER to find faults, AND there is legal liability if you screw it up. The second is obviously not true in the software industry, and of course design is HARDER in the software industry if you are trying for any kind of interaction with other systems: i.e., you have to live with whatever design faults are in the stuff you have to talk to, there from the last software fad.
Therefore, you're left with the fact that good design only happens: a) when it is possible, b) when it is mandated, and/or c) when the programmer/designer (usually the same person) WANTS it to be that way.
I always try hard in code that I write to do the proper thing, but employer's don't care about design, by and large: hell, most of them don't even care about maintainability -- they want a working executable yesterday.
Sure, some developers are lazy, and some don't make the push for a clean design when they could probably get one. But until the public starts *demanding* reliable software, don't expect any of this to change.
Remember, all pressure has to come from the customer -- the best designed, coded, debugged, and maintained software I see is the embedded code in missiles: it HAS work, and well, or else. There are design documents, requirements documents, official documentation of bugs, simulations, etc., all to make sure that things will work correctly when they must. This means no six month product cycles, though -- time is what is required for all good products, including software.
Re:software is incredibly complex... (Score:3, Interesting)
Not CS fault. (Score:3, Interesting)
I would hate to buy a cpu designed by a software engineer. But apparently buying software built by non-software engineers is ok.
I have found that very few software companys hire only CS majors for software jobs, you look on monster and it says, "Computer related degree required". That's bullshit people.
Beauty is the code (enhance, embrace, and extend) (Score:2, Interesting)
Computer programming is not only about making it work, but making your program work well and be maintainable. Sloppy code and poor structure makes maintaining, enhancing, embracing, and extending the code a royal pain in the @$$.
Don't fall into the trap of thinking that you are the only one who can fix your code. Someone else has already written it before you and doena better job. Everyone is replaceable. Besides why not make great code and do it well. How much time does it take to make clean and structured code?
Litmus test of a website. Read the source of the first page. Is it clean, does it have extra lines, are there mixed case tags, is the formatting consistent?
These are the ways to judge the results.
Masters make the simple easy and the difficult simple.
Re:software is incredibly complex... (Score:1, Interesting)
A better look (Score:5, Interesting)
Richard P. Gabriel [dreamsongs.com] (whose essay on "Mob Programming" was recently discussed on Slashdot [slashdot.org]) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site [dreamsongs.com], or Google's cached text version [google.com].
Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge'
Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book [fatbrain.com], patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.
a saying... (Score:1, Interesting)
There is a chasm
of carbon and silicon
the software can't bridge.
Programming Languages (Score:2, Interesting)
A tool like C++ would never be tolerated in the world of bridge building. Too prone to invisible screwups.
Eiffel is an example of the sort of tool bridge builders might use. Eiffel will never succeed, though, because of the perverse nature of the programming tools market.
1) Programmers love the mental challenge of mastering systems of arcane, complex rules. It's a macho thing. They don't automatically reject monstrosities like C++, as bridge builders would, because to do so makes them sound wimpy. ("I don't know what you're talking about, it's not hard for *me*....")
2) Also, if programmers were to lose their careers over a single "crasher" bug, as bridge builders would, even they would reject C++ and go for something like an ubersafe Eiffel.
3) There's tremendous language inertia in programming languages (though not as much as in bridge building technologies.) There may be thousands of programming languages out there, but most are virtually off-limits for practical projects. That's why things like C++ grow so much tangled hair. It's easier to learn one more round of gotchas than to learn a whole new language, buy and master all new tools, and change jobs to a company using the new language.
If I created a really great new language, would it become popular? I'll take the 1 in a thousand risk of being wrong and state flatly "No."
As long as we're programming with the languages we use, we'll have the level of bugs we have.
It's still a flawed analogy (Score:2, Interesting)
1) Materials science changes only slowly, in small increments.
2) The working principles of structural engineering scarcely change at all.
3) The practices and processes by which bridges and houses are built evolve only slowly, and incrementally, over decades.
4) The fundamental purposes for which houses and bridges are built never really change.
Contrast that with the practice software engineering where everything, beit language, paradigms, principles, practice, materials and even purpose change radically within very short timeframes. Programmers are expected to track all these changes, and what's more, they have to deliver quickly and efficiently.
In conclusion, I would assert that if architects and structural engineers were obliged to work in the conditions and culture in which programmers do, they would not succeed in building anything at all.
You've never seen how a house is built, have you? (Score:3, Interesting)
You've apparently never seen how a house is built. While the exterior finish looks very nice to the final occupants, the construction process and actual "code" (if you will) of a new home is quite sloppy; easily the equal to typical ugly code.
Tract housing, in particular, are built as quickly and cheaply as possible. Wires are run rapidly, without much care to particular placement. Builders leave lunch trash inside wall interiors. Finishes are half-baked, details are of little concern. The materials used are the cheapest possible.
Just like a program, what the buyer sees is the outside finish, and that's basis for their purchase decision normally. But look at how they are actually built, and you'd be afraid.
People cut corners if they think they get away with it, be it bridges, houses, or programs.
time to rant (Score:2, Interesting)
"those who can't do, teach"
you read this topic, "software aesthetics", and you begin to understand why this saying is so apt.
i'm sorry, but scenic pastoral allegories about bridges and houses makes me want to choke. has the author ever actually worked in the business world? you don't have 3 months to look at a business problem like it were a chess position or a game of go and wax and wane philosphical about "internal beauty". you have 3 days to give it a heartbeat and stick it in front of an end user and then wrench it's guts around 5 different ways while the end users completely mess around with the spec.
if i do this, and some guy is going to criticize the loss of mathematical symmetry in my choice of algorithms to solve a particular problem i'm going to punch him. oh my gosh! i could have written the entire app stateless rather than stateful? i could dimensioned this array to use 10% less memory? these variables are redundant? WHO CARES!
so go compose hiaku about the beauty of software or write code IN haiku, or whatever floats your boat about the serene inner symmetries about math and logic, and leave the real work to the real people in the trenches.
sorry folks, but this is total bullshit! (i know, i'm not talking about systems that help my mother's surgeon operate on her heart, or trade my stocks, or send the next space probe mars-wards, but this criticism of inaesthetic code, applied to the 95% of programming that is not so death-defying, is inappropriate)
look, as long as hard drives grow in capacity like weeds and moore's law on processor speeds holds true, software bloat is the only game in town. maybe in the days of the 6502 and 4k of memory, writing clear, concise, elegant code was not only kewl but necessary. but nowadays allocating 20k of memory for an object that, as used in code, is the logical equivalent of a boolean, is, well, a moot point!
so let the greybeards look down on us and scowl at our waste... we can waste! it's OK. you are still an "alpha geek" or whatever you feel you have lost by not revealing the beauty of prime numbers in your code for the shipping company's bike messenger route tracker. oh dear!
in fact, i'd rather see a discussion on the modern trend of "skinning" apps, or at least the gui in general... that is where developers REALLY have to pay attention (boy have i seen some doozies). the gui is where smart coding really does make a difference and where most programmers really do drop the ball awfully. the gui is where a discussion like this really can make a difference, i think.
note: if you want to flame me and you don't work in the business world, please temper the thought with some empathy for us dilbert-esque programmers who report to dilbert-esque bosses. (that's the REAL source of my passion on this topic.) thanks
Check your premises, something is wrong (Score:3, Interesting)
Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame.
I'm sorry, Michael, but I must disagree. This weekend I had two wonderful counterexamples.
We had our house built, in fine detail. That included making decisions about such seeming trivia as the knobs on the closet doors. It was a pain in the ass. But we got a helluva well-built house out of it.
One part of this detailed process was selecting a builder. We knew from wandering thru unfinished houses that there were some real corner-cutters out there. It wasn't that their houses didn't meet code or fell down, but there's the letter of the rule, the spirit of the rule, and (best) is the urge to do it right. Our builder did it right.
But he's the exception, not the rule. Open up the drywall on any house (or better yet, try to install some paneling) and you'll be surprised how much your house is out of true. We all get it, we all live with it.
Even as well-done as ours is, tho, there are still some things that are hard to do. Like the pain we had this weekend running 10-baseT cable and coax to my teenagers rooms. Too damned many solid things in the way. Yeah, we didn't think of it in advance -- and twenty years ago, who did? Is this a design flaw? Nope, even the best of houses has errors.
The other example from this weekend is building a computer for my sister. She doesn't need much; an older system will do the trick. So I went down into the Eschasi's Basement of Dead Computers and started scrounging stuff together.
You know what? The mechanical design on most legacy PCs is light years ahead of their more `advanced' cousins, the workstation. My SS-10 is much harder to work on than the average PC. And let's not think about some of the other old systems out there...DECStation 3100, anyone?
Why are PCs relatively good? Because they're designed to be cheap to assemble, and because economies of scale have helped made components standardized. So you get simple parts that plug together simply. For a counter-example, look at any automobile. It doesn't use standard components, so parts are custom-designed for ease of assembly.
A modern PC, in spite of idiocy like the BIOS and DOS's legacy, is a thing of technical beauty. And so is some of the software we write.
What distinguishes the good from the bad is (as so many have pointed out here) is (a) what you have to work with, and (b) what you're incented to do. With good tools and good standards and an environment where the software lifecycle is understood, good code is written. I do it damned near every day.
Re:complexity (Score:2, Interesting)
even though I hate microsoft bashers, thats an interesting point. when you build a bridge, you generally support it (no pun), and when it falls it is the designer of the bridges fault, not the car driving over it. Bridges even tollerate more then what they are designed to.
Why don't software companies support and back their products when they make boo-boos? Why do we expect them not to because we clicked "OK, I Agree" after reading the first line and realizing it is only a bunch of legal mumbo-jumbo?
What is "elegant" code anyway? (Score:2, Interesting)
1. Massively documented, heavily object oriented code with lots of reuse, designed for ease of enhancement and maintenance, etc?
2. Tight, fast-executing code which, while it may be difficult to figure out at first glance, is powerful, resource-sparing, and generally cool algorithmically? Of course it is well documented, designed carefully, etc.
3. Other standards of elegance?
There are jobs for which (1) is the definition, and others for which (2) is a good definition - although my own bias leans toward (2). Note that systems built with (1) as the definition tend to be resource inefficient, but in many applications, this doesn't matter. Are you writing code which glues together a bunch of legacy db's and other apps or are you coding an OS or filesystem? To borrow a phrase from architecture: form follows function.
development price... (Score:3, Interesting)
The fundamental goes about development costs. The article descripes the problem very well in software people can't see inside like in houses or bridges. Okay with OpenSource they can, but still most users won't
The matter is as a project making super stable software is far to expensive to be compatitive. Software for airplanes and for nuclear powerplants is tested with other means than 'normal' software. These software is usually tested with a kind of profiler support, until it is taken sure that -every- branch of the software has at least been taken once, and every loop has at least looped 3 times during the test. This requires high qualified testers, beeing able to read and understand the source, and more important time, time, time, time, which is a lot of money. For high security systems this pays of course of. But again people cannot see how the bridge is constructed, say you will be buying a bridge, and it's a black box for you, you can't see it's fundament, you can't see how it's pillars are constructud, it's just a path from one shore to the other. Now for which of the two will you decide? Okay you'll evaluate both, and ran on both bridges a few times up and down, maybe send or two a cars over both. They're stand you're test, and you can't see the one that's build with super high quality means, build of concentrate and secured with steel cables, and the one that's a chaotic assembly of wood added and added to it until it did no longer break if the builders tried to walk over it. Now the first costs 10 times as much, which one will be bought? (remember you can't see the wood vs. steel)
So for software, everybody wants graphics, GUIs, 3d, easy click and features, and features, and features, nobody wants a plain but constructed very carefully but boring/simply interface. Your costumers will need the features, are at least think they can't live without and leave you for featurefull wood bridge.
OpenSource at least eases a little, since people -can- look how the bridge or the house is constructed, but really take yourself, did you ever looked in example at the sources of xfree, gcc, bash or any of the applications you use each day?
In example when exploring the sources of the linux kernel I've a subjective of course safe feeling, most of the stuff looks nicely constructed, and is not super complicated. On the other hand other (opensource) software I looked at, you shudder, but think, well it runs aster all so I just better wont touch it. I'll not call names for this catagory since this would be just a flame, and maybe only because I didn't understand some stuff. But trust me for a quite some closed applications if you could look at the source (supposing you know C(++)) you would never want to start that application again
In this case the construciton engineer would investigate and proparly discover it's some kind of harmonic vibrations that cause it to fall down, but for the (commercial) software enginner there is no time or money for this, he couldn't explain his chief they used up 6 weeks to find out why a plank more changed the harmonic oscillations, he just adds a plank and the problem vanished, so the problem is finished within the available resources.
Re:Beauty for beauty's sake makes crappy software (Score:3, Interesting)
That's an expensive "{"
:)
Millenium Bridge (Score:1, Interesting)
Otherwise known as the wibbly wobbly bridge. Top architectural firm, key site across the Thames, modern computer software, and they forgot to take into account the 0.5Hz horizontal impulse generated by a crowd walking; only the 1Hz vertical impulse was designed in.
So they have to redesign it, adding dampers to the bridge so it doesn't shake...
So no, we still don't know everything about how to build a bridge.
$0.02 (Score:2, Interesting)
I) Design it to death
Take a few weeks to write specs that describe every nitty-gritty detail. Reduce coders' individual freedom to a bare-bones minimum.
Advantages:
- Client knows exactly, beforehand, what a piece of software will do and at least to an extent what the cost will be.
- Programmers know exactly what their job is.
Disadvantages:
- Constant micromanagement is required to find out if the programmers in quiestion aren't cutting a few corners to meet their deadlines/to show off.
- For a huge amout of time, no progress is visible, since everything is planned in advance. This could lead to a seizure or two when the deadline is there and the resulting software doesn't meet requirements.Also, tests can't really start before the project is completed.
I suppose this method works best if you have a team of inexperienced coders and a rather large architect force.
II) XP
Together with client, draw up a list of requirements. Then hand out this list to all programmers who divide the work out amongst teams either made by themselves or by management. Make them develop on a shared, simulated test-implementation environment.
Advantages:
- Huge cost cuts are made in the design.
- Obviously, since there is a shared, 'real-life' testing environment, testing can be done at any given time.
- Kent Beck could give you about a thousand more
Disadvantages:
- Requires a lot of independence from the programmers themselves. Independence some, if not most programmers simply do not possess or even _desire_.
- Assumes a good design will sort of 'come naturally' out of a joint team effort. I do not believe this notion will ever hold true, maybe only for small teams.
- If one little cog in the XP wheel is missing, like continuous deployment and testing or constant peer-reviewing, the whole thing comes crashing down like, well, a badly built bridge because -guess what- the DESIGN is missing!
XP works, I've seen it work, but only in small teams, on small to medium projects done only by REALLY good programmers.
Conclusion: The old-style, Systems Development method of doing a software project is certainly up for a revamp, although I think XP is too 'Extreme' for most real-world situations. My clients generally _want_ to see solid design before they OK a project, they simply aren't content with just turning in requirements, and most certainly do not want to put one of their own tech people on the project (why else would they have come to us).
I personally believe that there is a more elegant solution to the dilemma, which is combining the design phase of old with both generative programming and the development phase of XP. It may seem a bit bulky at first but with generative programming a lot of bulkiness is taken out of development, and people can start 'dumping modules' into the test environment almost instantly after design has finished.
It's amazing how everyone knows the answer... (Score:2, Interesting)
Part of the problem is the languages people use: modern functional languages virtually force you into a safer, cleaner programming style and these days don't require you to compromise on efficiency; most imperative and OO languages lack any real facility for abstraction and in many ways just make you stupid. There is some hope: if you want the best of both worlds use OCaml - it's often faster than C with all the OO, abstraction and type safety you could ask for. It's imperative, to boot, if you have to think that way.
Market forces place universities under pressure to just teach people Java/C#/C++/whatever is being used in industry at the time, rather than teaching students how to use abstraction to solve complex problems (as opposed to just ad hoc hackery). The debate isn't going to get anywhere, however, because people who demanded and got this sort of bricks-and-mortar-but-no-architecture degree don't want to hear it. They're in the majority and managers know what they're hiring, even if experience shows time after time that the results are bad.
What unadulterated rubbish (Score:3, Interesting)
Software is in better shape than this dumb article suggests. You can get better software, but you have to pay for it and folks don't want to. Pay in open source terms means have less software around than you need with developers concentrating their efforts on fewer projects.
Bridge Building (Score:2, Interesting)
Engineers of Dreams at amazon. [amazon.com]