Slashdot Mirror
Software Aesthetics
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.
My software is so ugly it's beautiful. I'm coding in Perl these days. :)
kind of like the innards of a biological organism.
Ever disected anything? It's MESSY.
-... ---
- Meet user requirements
Which doesn't necessarily mean it has nice and pretty code. If you have time, you are doing yourself a favor by designing it, but you can't lose track of the purpose of what you are doing, which is to get something working.Most techniques for designing or building software (e.g. patterns, processes) all serve to help you avoid bugs, which is to say more efficiently build software that meets user requirements.
http://www.naildrivin5.com/davec
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
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
I don't get paid to create beauty, especially not internal beauty. I need it to work, not look good.
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.
room101 -- how much can you stand before they break you?
(they always break you eventually)
Personally, I found Donald Knuth's Literate Programming as well as the Practice of Programming to be wonderful resources for writing better, more beautiful code.
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?
I can't tell you how many software packages I've looked at that are ABSOLUTELY HIDEOUS on the inside (and open source isn't exactly immune to that either. Anyone taken a look at the code of SSLeay? Good package thou).
The problem being, however, that once you have money entering the picture, and/or time, then the first thing to go is code quality. Mind you, combine that with the fact that a few years ago anyone who had the patience to sit down and read "How to program in java in 21 days" suddenly became a programmer. Here at work we have a very large codebase that we originally contracted out someone else to do, then took over once we got more funding. They preferred the "copy/paste" approach to doing loops, and tonnes of other hideous hideous things. I've done things like cut down 2500 lines of code to 1100. In fact, the company here could save money in the long run by hiring me to do nothing but optimize, by the cost of additional hardware that they would have had to buy to support this. ugh.
Unfortunately, in the land of "80% complete is good enough" and where "as long as it works" is a good philosophy, and in a land where "visual basic" is a professional programming language, we're not going to see this improve any time soon. Even Java works squarely against the goal of "efficient". Give me C++ any day.
I think that another part of the problem is people just not caring about their code, not having pride in what they accomplish. That and people simply not knowing what the hell they're doing. (Not that I know ANYONE like that around here... nope nobody...)
Argh. Ok sorry, I'll end my rant now.
If God gave us curiosity
Typically, the user interface to software is supposed to look good. This corresponds to the visible stuff in a house: the walls, floor, fixtures, etc.
But does the wiring look pretty? Or the plumbing? Or the unfinished basement/garage? Or any of the stuff that actually makes the house work?
Hell no.
Does the engine of a car look pretty? It's covered in grease and all kinds of crap is sticking every which way, and it doesn't make sense to the non-initiated. Function is more important than form when it comes to making the car go.
I'm getting tired of these calls for purty code. I like an elegant piece of software as much as the next guy, but my manager could give a crap as long as it works, and in fact won't be willing to give me extra weeks to make it look nice on the inside. Particularly when you consider that I'm probably the only person who's really ever going to look at my code.
Monkeytreats
That's the truth. I know every time I have to show someone my working code, I have to do a parental-visit-strength clean-up before letting them see anything. Of course, we should keep it clean as we go....
Attempting to compare software engineering to building a bridge or constructing a house is flawed. The reason bridges are built to such exacting standards is because if they aren't, they FALL DOWN. They cease to function. 100% failure. Poorly built software, on the other hand, can still work well enough to be usuable. It may imperfect at some tasks, but perform adaquately at others. If it were true that anything less than a perfectly engineered piece of software would simply fail to compile, then we'd all be writing perfectly engineered software.
An additional flaw in the analogy is this: The function, or use, of a bridge is quite clear: Extend a roadway over an otherwise impassable divide, such as a river. Simple as that. But deciding what the function or use of a piece of software is much more difficult and complex. Software is told to do many things, and the things it's supposed to do changes over time.
I'm all in favor of well designed software. But his vision is more utopian than useful.
It's because managers seem to think that any computer related degree means you can design and write software. I'm not being mean here, but if you have a degree in maintaining networks or creating circuit boards, that does not mean you can design software.
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.
That is why we have advanced software engineering techniques like eXtreme Programming. Through it's constant refactoring it makes sure that code is always the best it can be for the task at hand, and constantly improving.
The only reason that so much code is ugly is that most people do not know about and adopt XP. XP closely resembles the reality of Open Source programming in its implement-now mentality and constant addition of features. If everyone used XP, the software world would be a better place!
Even Slashdot wants to hide some things
I think a problem here is getting to a common definition of art. If a master craftsman pours his soul into a work, how is that not art? Just because the emotions a work may convey cannot be easily categorized and labelled does not mean they are not valid feelings. There are many pieces of "craftsmanship" out there that evoke such feelings. I have felt them myself. Would you deny me that?
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
Tim
Very perceptive...coding software is like crafting a cabinet. However, designing a cabinet is art...and so is designing software.
Try expressing an emotion in C++. It cannot be done.
jesus->loves(you); // Sarcasm, for the humor impaired
Regardless, art doesn't just express emotion, it inspires emotion. And trust me, I've had (mostly other people's) C++ code inspire some pretty horrific emotions. ;-)
Good design and coding, on the other hand, can truly be things of beauty, regardless of language.
Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
Spoken like someone who just doesn't really comprehend software design, or why one design might be more elegant than another. I suppose you don't think mathematics is beautiful either...
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")
... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.
Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) 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, or Google's cached text version.
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, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.
Stupid job ads, weird spam, occasional insight at
One can certainly succeed in meeting the user's initial basic requirements by writing a pile of spaghetti, but that doesn't make the writing of such sloppy code the preferred approach, at least in the general case.
Unless you're writing one-off programs for your customers (and how many of those end up being used over and over again?), the long-term maintainability of your code must be kept in mind at all times.
There's (usually) no guarantee that *you* are going to be the one maintaining the code in the future, at least many settings, and the people who will have to figure out how it works in order to maintain or enhance it will be extremely grateful if you lay your code out clearly.
So will your users, as they will have to wait a shorter amount of time before that bug is fixed or the new feature added.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
The key is to format the code so it looks like an ASCII figure of a bug. The viewer, if he is hip, will appreciate the irony.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
It comes down to time and person-power. I think the biggest failing (from personal experience ;) )of most software/system design comes from either a lack of time or a lack of planning for time. The promise of "Technology" is here and now, but the bedrock is a sandy beach.
The other important consideration is person power. It's not necessarily a lack of intelligent and capable people, but rather poor management of their time (either by themselves or from project managers). For example, working long hours in "crunch time" or being forced into the 9-5 cycle. Unfortunatly, my brain does not work on the 9-5. Sometimes I'll work for hours on end in an outpouring of inspiration while other times I'll be staring blankly at an equally blank screen.
Another thing that corrupts software is the idea of "catch-all" systems. That is, does your web-browser _really_ need an IRC client? or, for that matter, an e-mail client? I think it would be helpful to break software down into individual, streamlined components that does one job - and does it really well, instead of doing a lot of jobs poorly.
Just my 2 cents.
Price, Quality, Time. Pick none. What, you thought you had a choice?
DISCLAIMER: this is not a cheap shot at interns: it is a shot at managers failing to properly groom young hackers into veteran hackers with the humility to focus on the what's best for the project, rather than deft coding tricks.
i've seen dozens of interns and new hires come in with 1 or 2 semesters of C, and write lots of code, sometimes important pieces of code. management seems to think that if you throw enough newbies at a problem, it's the same as one or two really good programmers. this is a huge management oversight. interns and new hires need good solid mentors and time to develop and hone their skills, and project management needs to enforce design rules. unfortunately, newbies are very reluctant to code to design rules, I know because I always wanted to do stuff my way as an intern (eight years later I'm writing design rules... irony). the result is like a meatgrinder on full speed: code spewing everywhere that all looks different, and is not being tested, regressed or reviewed.
I've seen projects with strict design rules and rule checkers plus a technical guru/godfather for the project owner: results, fewer bugs and fewer people needed to support the code, and i'm talking about million line simulators.
solution: mentoring by veterans with large program experience (the really mean veterans, they are the best people to surround yourself with); and a strict adherence to design rules and revision control; and regression/coverage testing!
https://www.accountkiller.com/removal-requested
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.
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.
ShoutingMan.com
Gee that's a very tough problem. I'm sure I could say something meaningful about but I can't cover it in the allotted time or using the money you're paying me to do it.
Why does quality suck? Why does performance suck? What kind of quality are you talking about? Functional, aethetic (I guess you mean elegant though), fixable, manageable? Those are all different axes of quality that represent different things, having different values and are achieved through different means and methods. The reasons they fail are myriad:
1 Management doesn't have a clue
2 Programmers don't have the skill
3 No one cares if it's shit
4 The customer is insane
5 The customer is cheap
6 There are too many changes
7 There is no difference between success and failure
8 The technology is crap
9 Poor program/project management
10 Cult of the hero
11 A preference for predictable mediocrity over accidental brilliance
12 The arrogance to believe that what you do is art but what everyone else does is 'engineering'
13 No accountability for problems
14 No time for design
15 Thinking a packaged solution can be installed as-is
16 Inability to create useful requirements
17 Scope creep
18 No test plans
19 No QA
20 Poor cost and time estimates
Those are just the ones I saw today.
Two, software that is not conceptually clean is hard to extend. People often talk about maintainability, but it rarely gets priority during implementation. Why did Netscape's browser finally lose? Not because they didn't have good ideas for new features, but because it was internally such a mess that they couldn't improve it fast enough. This is not uncommon.
So, even when we feel the very necessary pressure to get our code out the door, we need to push back in order to give more attention to beauty. We will benefit.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
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.
For a particularly good book describing the problem and situation (fabulous for understanding the flaws in most businesses software design methodology, and more importantly for convincing managers that this is the case) then you should read The Inmates are Running the Asylum by Alan Cooper, the 'Father of Visual Basic' and also author of About Face: The Essentials of User Interface Design .
It's light on concrete solutions (although the foreward addresses why that is the case) but still a useful primer to read even if you want to solve the problem, since the first step to solving a problem is properly understanding it. It's so fabulously refreshing to see in print a rather respected person describing the problem as I know it to be true, and especially providing big-business, big-name, concrete examples to point to and say, "SEE! IT REALLY DOESN'T WORK TO SET ARBITRARY DEADLINES AND TO START CODING WITHOUT PROPER SPECS!".
This issue is just a little bit important to me :)
I just started a job recently where the previous developer of software that I'm modifying did NOT use warn or strict!!! How the hell do people justify that? I just don't get it... Not only do these tools speed debugging, they make your programs less succeptible to bugs.
;-p
If anyone reading this does NOT use warn (invoked by putting a '-w' after your perl interpreter call, ie: #!/usr/bin/perl -w ), or strict (invoked by putting this after your perl interpreter call or package definition:
use strict;
then please do!
You'll have to make sure your variables are scoped correctly (ie: my $scaler = 'whatever';), which may seem like a bitch but is HELPFUL!
hehe, ok, enough of this. Hope you all are having a fun day.
-japh
p.s. I don't have a tv either, I recommend this if you don't like being brainwashed/desensitized,
Hmm I fear posting so late nobody might read this, but well I'll post eitherway ahead.
:)
:o) With source comments allied to the bridge example, /* we added this plank here, since if not the bridge will always fall down when poked 3 times in 1 second distances, we don't know why, but with it vanished. */
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.
--
Karma 50, and all I got was this lousy T-Shirt.
But you have to know what to look for. I've often found a badly designed user interface to be a real tip off that other parts of the software are crap. I'm not talking about pretty pictures and cute icons (which, unfortunately, is what a lot of people in the free software community think constitutes usability), I'm talking about whether widgets are laid out in an unambigous manner and whether operation of the interface is efficient and cognitively sound. If a company designs one part of the system in a very half-assed manner, they'll most likely do the same with the other part, too.
If software were a bridge you'd use it to cross an otherwise unpassable gap between two points, and NOTHING else. There would be 2 or three basic designs which nobody deviated from and nobody would have seen much innovation in decades if not centuries.
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.