Forgot your password?
typodupeerror
Programming IT Technology

Software Aesthetics 748

Posted by michael
from the when-tidy-is-not-sufficient dept.
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.
This discussion has been archived. No new comments can be posted.

Software Aesthetics

Comments Filter:
  • by quartz (64169) <shadowman@mylaptop.com> on Tuesday September 04, 2001 @04:50PM (#2252799) Homepage
    My software is so ugly it's beautiful. I'm coding in Perl these days. :)
    • 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.

      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, ;-p
  • by swagr (244747) on Tuesday September 04, 2001 @04:51PM (#2252803) Homepage
    kind of like the innards of a biological organism.

    Ever disected anything? It's MESSY.
    • I think that's a pretty good comparison. Organisms are also buggy creatures with security holes, serious design flaws and legacy code (e.g. the appendix). But hey, life is proprietary. You know, if God/Allah/(insert your Creator here) would just release the source code ...
      • But organisms, particularly humans, are far more resilient than any software yet created. Our brains don't usually "crash" completely, no matter what you throw at them. Metaphorically speaking, of course.

    • Well, in my experience beauty of code and how efficient that code is do not go hand in hand. The most efficient pieces of code i wrote were butt ugly and needed heavy explanations to my coworkers, but they got the job done in few lines and they took up little resources to do it.

      So what we want is no beautifull code, but really efficient one, and coding beautifully often goes against it.

      On the other hand, beautifull code is easier to maintain and to share, but its always best to have good code, not code that looks good.
      • by Anonymous Coward on Tuesday September 04, 2001 @06:37PM (#2253398)
        That's about the most naive blanket statement I've ever read. "its always best to have good code, not code that looks good."

        Consider a project that lasts 5+ years. Over the life of the project, there will be dozens of developers added and cut from the payroll. Assume your "good code" gets executed once or twice a week and instead of taking 2sec it takes 1sec. You've saved 1sec (possibly 2sec) per week which adds up to 52secs (or 104secs) per year.

        Let's compare that to the human maintainer. Assume one person has to look at that code 1 time every 6 months and it takes them 30 minutes to understand it. That's 60 minutes that someone is getting paid to understand that code.

        If the person earns $80,000 US, that's about $4 (assuming 4 week vacation) that was spent on the human. It's actually less when you consider that a person's salary is not their labor rate. Over the life of the project (5 years) you've spent $83 on your "enhancement".

        Now, if the cost of up'ing the Mhz on your CPU is greater than $83 then it may make sense to implement the "enhancement". However, when you consider the price differential between a 900mhz processor vs a 933mhz processor (the argument being that a 933mhz processor could run the slow code and keep up with the 900mhz processor running the fast code) you won't find an $83 difference. It'll be more like $20.

        That being the case, humans are more expensive than computer CPUs these days. Maybe they weren't in the past, but they are today.

        Another argument for clean easily-readable and understandable code is that, if you take your argument, the entire system will become "enhanced" and no one will understand how it works. That will add on an additional overhead in the form of lack-of-enthusiasm for a project and will have financial implications.

        All in all, I've worked on XP projects where code formatting and understanding was important. And I've worked on government contracts where people hack'ed their way through to save a couple of cycles. Maintainability speaks volumes... And I'd go with readability and understandability in a heartbeat...

      • by Fortmain (469266) on Tuesday September 04, 2001 @11:10PM (#2254219) Homepage
        Beauty isn't really the issue here, it's maintainability. The current project I'm on, I 'inherited' someone elses butt-ugly code. It did the job fine, but I spent the first six months reading, re-reading, and testing, just so I could understand what the thing was doing. All told, I spent over a year just getting comfortable with the program. Meanwhile, I'm also supposed to be updating this thing for a new release every six months! Every chance I got I did 'code clean-up', fixing things that worked, but were difficult to understand the logic of, or just plain stupid (take a long, often-used routine, and make it in-line everywhere rather than use a function!?).

        Finally, after two and a half years, I get the chance to re-write the whole thing into Java. (I know, it wouldn't be my first choice, but ANYTHING beats Powerbuilder!)

        The point is, unless you are writing 'throw-away- code, your program may exist for many years, and have many people maintaining it. We need to do ourselves a favor and make sure that we can understand what we all write. Memory is cheap, so there is no good reason not to write good, clean, easy to follow code.

        And don't give me the argument that "we're up against deadline". I've been playng this game for twenty years, and I know that every minute I spend in the design phase is like an hour saved in the coding phase. Design the thing first! Make sure you know how it is going to break down into the various modules you will use. If you design it right, the code will flow, and you will make your deadline easily.

        I know, all you young hotshots out there won't listen to an old fart like me, but eventually you will either learn the hard way that I am right, or you will burn yourselves out and never want to code again. Meanwhile, _I_ get stuck trying to maintain the crap _you_ wrote!

    • by BWJones (18351) on Tuesday September 04, 2001 @05:46PM (#2253150) Homepage Journal
      Its messy if you do not know what you are doing. Just like coding or debugging.

      Biological systems are actually incredibly beautiful well structured, and in many cases optimized for their environment to a level unmatched in artificial systems. (I study vision and I see this sort of stuff all the time)

      At any rate, the analogy to biological systems sort of works and sort of does not. Biological systems are not planned, rather they evolve (valid arguments accepted for religion. However, in human experience, biological systems evolve as we do very little in the way of planning outcomes unless one is making transgenics or cross breeding. Even then we are often simply along for the ride). Software too evolves, but well designed software is thought out and planned in advance with lots of end user input, subject matter expert input, and testing of code and interface to meet the users needs. In my experience with others code and commercial products, most software goes right into the writing phase with very little forethought or planning. "We'll get to that later" is the phrase I have heard again and again. The programmers that stay and get rewarded are the ones that can plan, work with subject matter experts, and listen and implement ideas and suggestions successfully. The ones that will not work long for me are the Prima-donnas that try and force their code down everyone elses throat saying nothing else will work. The reality is that either they are too lazy, or not talented enough and are unwilling to work hard enough to become excellent programmers.

      I am seeing this more and more with the Microsoft way of writing code which is timeline driven rather than product driven. While being good enough for many, in reality it is third rate stuff without a commitment to excellence.
    • Well, there IS an ephemeral beauty in the sight of the innards of a luser splashed about the bottom of an elevator shaft. Or on the wall. Or in ... Hell, it's just beautiful.
  • by sl3xd (111641)
    I can see the point, but why bother if we can't even get the courts to recognize the artistry involved in writing software?

    An architect can get rights on his design as free speech, and artistic expression.

    Software designers get no such credit.
  • blah (Score:2, Insightful)

    by teknopurge (199509)
    The reason it's so bad is because it doesn't have to be good to get the job done. Most management is just about getting things done fast.

    There is usually a tradeoff between quality and expediancy.

    teknopurge

    http://techienews.utropicmedia.com [utropicmedia.com]. help us beta.
  • by GusherJizmac (80976) on Tuesday September 04, 2001 @04:54PM (#2252817) Homepage
    Software has to:
    1. 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.

    • by Telek (410366) on Tuesday September 04, 2001 @05:08PM (#2252921) Homepage
      I totally disagree. Well, maybe not totally. "Beauty for efficiency's and future usage and many many other reason's sake" is always a good idea, however not usually practical.

      In how many cases do you end up spending more time and effort in the long run debugging shitty code because it wasn't written properly in the first place.

      For those who know how to write good clean code it's not that big an issue. Writing clean code takes the same amount of time as writing sloppy code, and in most cases it actually takes less. The only difference is that you need to know what you're doing and have enough experience to know how to code properly.

      Also notice that you take away accountibility and responsibility because not everyone can see your code. It's like walking around inside your house in your boxers when noone's at home. And this problem isn't limited to software. Anything that people can't see inside isn't usually pretty.

      Bah, bring me back to the 8086 days where you HAD to code efficiently because you had no choice. Man, anyone remember Wordstar? Everything you needed in a word processor (ok, maybe not everything) in 80kb. DAMN!
    • by Andrewkov (140579) on Tuesday September 04, 2001 @05:20PM (#2253012)
      This article is demeaning to programmers. The reason quality is poor is due to unrealistic deadlines, the reason projects are over budget is due to poor planning.

      Most good programmers are capable of creating high quality, elegant code, but are not allowed to because of external pressures that are out of their control.

      And with all due respect to engineers, most software is a lot more complicated than building a bridge.

      • by jfunk (33224) <jfunk@roadrunner.nf.net> on Tuesday September 04, 2001 @05:59PM (#2253214) Homepage
        And with all due respect to engineers, most software is a lot more complicated than building a bridge.


        ...and you know this how?

        Ever designed a bridge? Do you know how long it takes? Did you know you only get one chance to get it right during the implementation stage?

        Yours is the attitude that spawns crappy software.

        You might tolerate a Windows BSOD, but what if your TV started crapping out on a daily basis? Do you know how involved the TV design process is? There's a hell of a lot more to it than you think and there's a lot more thought put into it than 90% of the code out there. Then you have such things as life-support systems and critical automation, which are a *lot* harder to do than any software out there.

        Oh, and I'm saying this as someone who does both, BTW.
        • by Jerf (17166) on Tuesday September 04, 2001 @07:15PM (#2253559) Journal
          Ever designed a bridge? Do you know how long it takes? Did you know you only get one chance to get it right during the implementation stage?

          While your reaction is understandable, and it's easy to overstate software complexity, it is not entirely untenable to maintain that software is an unusually complicated beast, by most any useful metric.

          "Useful metric" is where the standard falls down. What metric can we use that makes sense? Can one person understand the design of a bridge? I daresay yes. Can one person understand all of Windows to the same level? I daresay no. Is that a fair comparision? What is a fair comparision?

          We lack a metric of complexity. So I'll submit this: By the rule of mediocrity, "on average, everybody is equally stupid", we must say that software is more complex then bridge-building, because we know how to build good bridges. It's been a while since I've heard of a bridge honest-to-goodness failing from something other then lack of designed maintenence. Software, on the other hand, is still problematic and we've been trying to figure out how to build it for years.

          Self-flaggelating (or, if you are not a programmer, flaggelating others whom you don't really understand) is not really useful. Attributing bad software to extra stupidity on the part of the software authors is quite disingenuous. Odds are, if a lot of very smart people have been working on the problem and haven't come up with a solution yet that seems to work, it's because it's a hard problem, not because the smart people are extra stupid.

          (It's also worth pointing out that the few software team structures that do seem to produce useful, reliable, etc. code also require truly massive expenditures on design, testing, testing, and more testing. Without proof, I'm willing to claim that the amount of money spent developing the software for, say, the Space Shuttle in this manner grossly exceeds the design+labor of any bridge you care to name. (Discount materials for the bridge, there's no clear equivalent in software.) And that's just Space Shuttle software... that doesn't help you email Granny.)

      • basically, you're talking about the problem being that the product is being designed by people other than the engineer.

        Marketroids designing projects and setting schedules will get you an end product that does not appear to be well engineered. Because the engineer didn't design it. The Marketroids did.

        You want software that works? Put the engineers back in charge.
        But then the company that does that will be out of business by the next development cycle. Because their product won't look nice on the comparison matrix.

        Ease of use and word-of-mouth doesn't cut it anymore in this industry. You need the trade rags sucking up. And that takes marketroids.
    • 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.
    • Software has to:
      1. Meet user requirements


      Unfortunately, in a great majority of cases, the user doesn't know what he/she needs.

      I can't count the number of times I have installed a system in a hospital (communications systems), made it run exactly to spec, and then have the staff say: "Why does it do that, we have absolutely no need for that! It should do this however".

      Generally, the specs are made by managers, not the people who actually use the device (program, etc). This causes the spec to be what management perceives to be the need, not the actual need.

      Granted, in an software situation, you are supposed to go through everything and find out what they need. How often does this happen? In most cases, a programmer is given a spec and told to write the software to it.
    • As a developer, I would add another goal:

      Software has to:

      1. Meet user requirements
      2. Require minimum effort on the developer's part.

      Even if you're under work-to-rule when delivering a system, that second requirement makes elegance important. Writing thoughtful, elegant code is simply easier in the long run.

      The three principal virtues of a programmer are Laziness, Impatience, and Hubris. -- Larry Wall

    • Can I amend that to:

      1. Meet user requirements quickly

      When you build a bridge you have plenty of time to design and implement it. And that bridge will last decades, if not centuries.

      Software, however, isn't meant to last. It's meant to take advantage of cutting edge technology RIGHT NOW. You don't write a program to last for 100 years. You write it to last a maximum of 5 (longer for sparse exceptions). That's why software is often so ugly.

      Maybe after 30 years we'll have an OOPL that will eventually take the cake, and some sort of system where we don't change APIs every month. Then maybe people will be able to write code for the long term, knowing it won't be obsolete in short order.

  • 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. When it comes right down to it, most software is just good enough to get the job done because that is what is most profitable in the short term. I revel in every bit of beautiful code I write, but also know that if I spend too much time making my code beautiful I will be replaced by someone more interested in just getting the job done. If I really wanted to produce art, I would have gone into a field that produces recognizable art.
    • by tim_maroney (239442) on Tuesday September 04, 2001 @05:11PM (#2252954) Homepage
      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
  • complexity (Score:5, Interesting)

    by radish (98371) on Tuesday September 04, 2001 @04:55PM (#2252824) Homepage

    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 :-)

    • 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 :-)

      Engineering just applying rules, yet programming is an art? Is this your editorializing or the original quote? Somebody needs a smack from a slide ruler. ;)
    • Re:complexity (Score:5, Insightful)

      by oddjob (58114) on Tuesday September 04, 2001 @05:26PM (#2253052)
      Your argument rests on the assumption that something you don't know how to do is simple. The reason software quality is low is not because it is more complex than building a bridge.

      -- We've been building software for decades, but we've been building bridges for centuries.

      -- There are natural structures that resemble bridges that we have learned from. For most software, this is not the case.

      -- When a bridge fails, there is a good chance someone is going to die, so you'd better get it right. Software is rarely that critical, and when it is, it is usually better written.

      -- Also, when building a bridge, if you are sloppy about it, you're going to have a lot of dead workers. For coders, caffine overdose and sleep deprivation are seldom fatal.

      -- When building a bridge, it is difficult or impossible to correct mistakes after the fact. With software, just release a patch.

      -- When building a bridge, you have the contract before you start construction. With software, there is always the worry that a competitor will get a product out before you.

      -- If you build a bad bridge, you will get sued. Try and sue Microsoft.
      • Re:complexity (Score:3, Insightful)

        by sterno (16320)

        When building a bridge, you have the contract before you start construction. With software, there is always the worry that a competitor will get a product out before you.
        BINGO! I cannot recall at any point in my 4 year career as a software developer that any given project had concrete and immutable goals before beginning of development. On the best projects we'd have good documentation of requirements, etc, but EVERY time those requirements would change.

        To compare software design to bridge building or most feats of industrial or civil engineering are ludicrous. To put it in perspective imagine this scenario:

        The city planning commitee has contracted to have a bridge built. Original bridge specifications called for four lanes of traffic. The city planning commitee now has decided it must have 8 lanes and the bridge is already halfway done. Do you think the bridge builders are going to stop construction and re-engineer on the fly? If they did, you can bet that bridge would collapse. No, they won't do that, they'll build the bridge, collect their check and go home.

        That sort of scenarios ALWAYS happens in software. Why? Because everybody knows they can get away with bugs, that patches can be released, that ultimately getting it right the first time isn't 100% critical. So they don't worry about it, and why should they? It would be inordinately expensive and arduous to design all software to the tolerances associated with civil engineering, and it would provide questionable benefit in the end.

        The big problem with software engineering principles is that we keep trying to find physical world metaphors for the way software should be designed and they all fail. Why? Because the physical is, for the most part, immutable. So how can you apply those same design methodologies to something that is infinitely mutable? The simple answer is, you cannot. Sure, some aspects may be adaptable, but ultimately accepting that building software is completely unlike building a bridge will make life much much easier.

  • When your code is on center stage you want it to look good.
    • 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....
    • have you ever taken a look at the source code for SSLeay? The last time I looked at it, it wasn't pretty. Lots of 1 letter variable names and not very many comments.

      Open source isn't immune to this, but it's a lot lot lot better in that case.

      Mind you, at one place that I worked where our jobs weren't very secure I used obscurity of code to secure my job. Noone else in their right mind could understand what I wrote (not necessarily due to messyness, but no comments, and not meaningful variable names, no documentation, etc). I had written the entire application, and before I left I commented it, but it was fun at the time.
    • When your code is on center stage you want it to look good

      True...so true. However, with patches coming in from all over, or multiple developers, unless someone rewrites all the code to read the same, you have multiple styles of programming, multiple conventions (no how matter how much you dictate stuff) and so on.

      It's just as bad.
  • by room101 (236520) on Tuesday September 04, 2001 @04:55PM (#2252826) Homepage
    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.
    • but how much extra effort or time does it take to make code that both functions correctly and looks good and isn't messy? I know that every time that I take the time to make it clean I benefit from it, and every time I do things sloppy I curse it later on. Plus a properly designed (hmm, that's a whole other topic actually. Software DESIGN vs Software PROGRAMMING)... A properly designed and programmed piece of code will have FAR LESS bugs than a sloppily designed/coded one.
    • by Myopic (18616) on Tuesday September 04, 2001 @05:29PM (#2253074)
      I've seen this comment a lot in this discussion: "well, my software works, so it's good enough". You even say that you don't get paid to make pretty software; just usable software.

      I suppose that might be true, but I would venture that not everyone is in the same boat. I, for example, AM paid to write pretty code. My job is to come up with relatively simple perl scripts (modules) to solve various problems that Dartmouth [dartmouth.edu]'s website users have. (For example, I wrote a quota module to help people verify that files they want to write to disk will fit within their alloted disk quota.)

      I have NEVER turned in to my boss anything but well-documented, well-commented, readable code. I don't do this out of respect for my users; frankly, I know how to use the software and if they don't they can read my docs and try to figure it out. No, I do it for the other schmucks like me. At some point, my boss will probably tell his next lackey to add some little feature to one of my modules, as he's asked me to do with some older programmer's works. And it's DAMNED IMPOSSIBLE to wrap my head around code which is all mixed up. I comment for other programmers. People who might need to sink their hands into my code.

      Paying me now to write comments and format things well is worth it for the added speed with which the software will be maintained in the future. So for me, and I'm sure most of the code jockeys on Slashdot, the "real world" is one where software is written, THEN MAINTAINED. Beauty is part of maintanence.

    • But aestetics has its place, too. One of my personal guidelines when evaluating a software design is to ensure that any "ugliness" that appears in the design has a damn good reason for being "ugly". More often than not, a design "ugliness" is the result of a poor design, and not caused by the requirments. On the other hand, sometimes the "ugliness" is imposed by the requirements, and in that case, naturally the requirements take precedence over "elegant" design.
    • The point you're missing is that even getting things to "just work ASAP" doesn't happen by itself. Only the most trivial programs are created in a single flash of insight. Most follow some sort of process, which often looks something like this:

      1. Write component A.
      2. Start writing component B, realize that A doesn't really do what it needed to.
      3. Fix A, go back to working on B.
      4. Finish B, C, D, and E. On a roll!
      5. Start work on F. Realize there's something else wrong with A.
      6. Try to fix A, realize you forgot how it works, the code is a mess, and there's neither design nor comments to remind you of what you were thinking at the time.
      7. Rewrite A, forget what enhancements you meant to add for F.
      8. Figure out what you needed for F, add the enhancements to A.
      9. Fix B, which you broke when you rewrote A.
      10. Try to fix C, which also broke when you rewrote A, but now you've forgotten how C worked. Again, no design or comments, ...
      11. etc.

      Hey, now your productivity is approaching zero, but hey, at least you're having fun, right? WRONG! The whole idea of good software engineering is to stay out of this trap, not for aesthetics or on principle, but because it sucks, and it sucks even more when you realize it was oh-so-predictable and oh-so-avoidable. It's pure self-interest.

      If you can program in tiny little pieces and dump them on someone else while you job-hop, you might be able to get away with this kind of slop, but as soon as you start writing anything that has any meat to it you'll recognize the need for better methods. Unfortunately, very few people realize this until they've spent a job or two fighting through the kind of swamp outlines above.

  • by Satai (111172) on Tuesday September 04, 2001 @04:55PM (#2252829)
    Personally, I found Donald Knuth's [stanford.edu] Literate Programming [amazon.com] as well as the Practice of Programming [amazon.com] 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 sometimes suspect that "literate programming" is a gimmick to get around Stanford's policy that professors can own the rights to books they write, but software they write is considered a work for hire and the property of the university.
  • I've found that most of the cause of the problem is people "whip out a function that does that job" so they can compile the program, then never go back and fix it up.
    Same with code comments. "I'll add good comments later/when I'm done", and you finally get the program stable when it needs to be released.

    I find it a ton easier to do everything the way you were taught in software engineering 101. Design the hell outta documents (I, personally, use RUP which I find nice), then code complete objects, nothing that'll just "let me compile", but whole objects. *AND* I'll code in the javadoc when I make the object. The code comes out quit nice that way.
  • by aarestad (154626)

    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!)

  • by gss (86275)
    Unfortunately tight timelines always negativlty affects the quality of software. This is why I'm a total believer in refactorting. [refactorting.com] Software should always be evolving, when something is found that was poorly designed, time should be set aside to fix it. By refactorting you will eventually have high quality code.

    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.

  • Check out the source to Darren Hiebert's ctags [sourceforge.net]. Best-designed C program I've seen yet.
  • And How!!! (Score:4, Insightful)

    by Telek (410366) on Tuesday September 04, 2001 @05:01PM (#2252862) Homepage
    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.
  • flawed analogy (Score:4, Insightful)

    by funkapus (80229) on Tuesday September 04, 2001 @05:02PM (#2252874) Homepage
    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.
  • Wow, good one (Score:2, Interesting)

    by Sinical (14215)
    Wow, what an unconvential argument. Never heard that one before.

    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.
  • So we need building codes for software. Because right now people are willing to pay for a cardboard refrigerator box, and expect to get a single family dwelling in return, and it's not illegal to give them the box. That's how you get to be the richest man in the world :-).

    But what codes are appropriate? Simple merchantability, or some certification of tested-ness and guarantee of defect repair? And how much of that are we willing to pay for? Certainly the current crop of EULAs would have to go.

    So what do you think -- a Software Engineering Board? We have professsional engineering boards for civil, mechanical and electrical design. Of course, this would put severe limitations on the hobbyist and any non-engineer-reviewed software projects. Careful what you ask for...

  • by whjwhj (243426) on Tuesday September 04, 2001 @05:06PM (#2252901)
    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.
  • Not CS fault. (Score:3, Interesting)

    by Capt_Troy (60831) <tfandango@noSpaM.yahoo.com> on Tuesday September 04, 2001 @05:07PM (#2252908) Homepage Journal
    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.
  • Code aesthetics (Score:2, Insightful)

    by KingAzzy (320268)
    There is a definite difference between a "Programmer" and a "Coder". Programmers are interested in the aesthetics of their engineering as well as the science behind it (the two are non-distinguishable) whereas Coders only care about getting the job done well enough so that they continue to have employment and not get fired.

    Programmers are much more expensive than coders and harder, much harder, to find for employment. Coders are very abundant. I have never seen a development department (in the 'big corporate IT world') that had more than just a small handful of true programmers, yet dozens and dozens of coders all whittling away at these massively bloated, poorly designed, inefficient, unscalable, pieces of pure SHIT that absord millions and millions of dollars from the corporate budgets.

    I don't think comparing houses and bridges to pieces of software is a very fair comparison, btw.. In construction it's quite easy to put lower skilled people to work effectively for the larger picture (doesn't take much as much skill to lay brick as it does to design the wall) than it does in coding (an inexperienced coder can virtually infect the entire project with his or her incompetence.

    These are my opinions after working in big IT for too long and perhaps after reading too much Dilbert and Slashdot.
  • by tomlouie (264519)
    Hastily written code that's intended to be only a "temporary" fix never seems to be replaced with working code. The problem is that the "temporary" code isn't visibly different from more permanent code.

    The building analogy is that anyone can spot a poorly put together shack, as opposed to a carefully poured concrete foundation. Not so easy with code.
  • XP! (Score:4, Insightful)

    by Proud Geek (260376) on Tuesday September 04, 2001 @05:10PM (#2252936) Homepage Journal
    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!
    • Re:XP! (Score:3, Insightful)

      The only reason that so much code is ugly is that most people do not know about and adopt XP.

      Extreme Programming (still abbreviated XP, despite Microsoft's attempt to dilute the abbreviation) may have a lot to offer many software development projects. But Kent Beck and Ward Cunningham and Ron Jeffries were capable of writing beautiful software before XP was codified, and programmers in XP projects are capable of writing ugly software.

      Refactoring backed by unit tests (two XP practices) can help reduce software entropy, and keep software from becoming ugly; granted. But XP extremism helps no one.
    • Re:XP! (Score:3, Informative)

      by chipuni (156625)
      This is not a blast against XP. I think that XP has a number of good ideas. However, XP is not a silver bullet .

      If you're interested in learning to be a better programmer, learn from many methodologies. The following are some of the books in my collection:

      Journey of the Software Professional: A Sociology of Software Development by Luke Hohmann (Prentice Hall, 1997) goes through many of the ideas that make up Extreme Programming, and lets you pick the best choices for your own team.

      201 Principles of Software Development by Alan M. Davis (McGraw-Hill, 1995) is a collection of 201 very simple principles, short-short essays, and links to other books. It's an easy afternoon read that will change your world.

      The Unified Software Development Process by Ivar Jacobson, Grady Booch, and James Rumbaugh (Addison-Wesley, 1999) is a software development book that I trust far more than Extreme Programming.

      Constructing Superior Software edited by Paul C. Clements (Macmillian Technical Publishing, 2000) is an excellent collection of essays about constructing software.

      Regardless of whether you choose the books in my collection or other books, I strongly suggest that you read more than one methodology.

  • >If software design were as visible as a bridge or house, we would be hiding our heads in shame.

    You really should look more closely at homes/buildings.

    They are just barely made to meet some local standards. Its a challange of how to build it as cheaply possible while getting as close to the standards as possible. When they build it, even architects, they do it for money. Very rarely when you get a client who wants to build something for art's sake. Even then they are limited by local community standards.

    The difference between building a structure and software is that there are years of legal laws you have to follow because building and bridges in the past were "ugly".
  • Try telling your manager sometime that you want to redesign a piece of code because "It's aesthetically displeasing" or because "The design sucks." He'll laugh you out of the office and quite possibly the company. Nevermind that you were right or that your redesign would drastically improve maintability and probably speed things up. Managers don't want good code. They want code that you can squat and shit as quickly as possible because the only metric they look at is the deadline. It may not smell good. It may self destruct in a few months. It will certainly keep your team in "fireman mode" for the rest of the time they're at the company, but by God it made the deadline and that's all that counts.

    Just to make matters worse, a lot of managers believe that if they give their programming teams Rational Rose or Visual C++ or whatever, that those tools will magically make the code the team is producing well designed. Well if you give a monkey a computer, he's still a monkey and you won't get anything out of him at the day except a bunch of monkey shit. Most of the commercial code I've ever seen has been monkey shit. Ironically open source code tends to have a much lower monkey shit ratio because the programmers don't have time constrains and care to get their design right.

  • If you are under the misguided notion that you can write S#!% for code and it doesn't matter, then you will not last long in this world.

    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.
  • The problem is that while software developers may want to fix the bugs and make it work nice and all, the managers generally want to make money and the only way to sell a product is through new features. Usually adding in features after an application has been developed makes an app a nightmare to work on and harder to debug.
  • Writing software is writing, and the fact is that most people don't write very well.

    Long subroutines are run-on sentences [std.com] discusses one aspect of this problem.

  • Bad analogy. (Score:2, Insightful)

    by Dasein (6110)
    Building software and physical structures are two entirely different things:

    1) The customer of a construction company is unlikely to decide that their cute split-level should now be a super mall after construction is underway. It isn't unusual to see the equivalent happen in software.

    2) The "Mythical Man Month" presents a pretty good argument about fundamental complexity Vs. accidental complexity. It would be a good thing to think about.

    3) Because everyone has a passing familiarity with the physical world things that aren't right get pointed out fairly quickly. In my experience is that about 20-30% of programmers can cut through the symptoms and treat the cause. Everybody else goes around plastering over cracks instead of realizing that the foundation is crumbling.

    My two cents.
  • In all development shops I've seen it is very difficult to write beautiful code. I find myself getting the job during the day, and writing my own beautiful code, for my own projects, in my spare time. I imagine my feelings about this are not too far from that of a serious musician earning money by playing bar mitzvahs, or novelists writing ad copy.

    Anyway, here are the reasons why writing beautiful code at work doesn't happen:

    • Deadlines. If it ain't broke don't fix it.
    • Too many cooks. Someone else touches my code and they don't follow my coding style. Even worse, the offender doesn't follow any consistent style at all.
    • The original designer did a crappy job. Which is just another version of If it ain't broke don't fix it.
    • No time for re-factoring, even after requirements change, or you just realize better ways to meet the original requirements.

    Oh well, time to make more sausage.
  • It's half right to say we should engineer software like we engineer physical aspects of our lives such as bridges, houses, skyrises, etc.

    However.. Bridges, Houses, Skyrises, all are slow moving, slow changed things. House "technology" doesn't suddenly double every 18 months. Otherwise we'd be like the Jetsons with houses into the sky, and talking dogs. Bridges are engineered to last for a very long time, because they do a simple, easy function. They provide land where there is none to travel on.

    Software and Hardware however does. If you talk to a lot of software engineers, professors, etc. They'll all usually say not to worry about performance, next years computers will run it twice as fast anyway. This is very true at Microsoft. And its partially correct. Why bother spending a ton of time trying to make something work fast, when during the time you took to make it work fast, chips have doubled in speed?

    However I do beleive we need to up the standards because of other issues, not longevity, but security, and functionality. Sloppy code leads to sloppy security. Just install a fresh copy of Windows, you pick a version. Unless you patch it, there are already a handful of security issues. Last time I installed OpenBSD, I don't remember going "I have to hurry up and patch this, and this, and this otherwise I'll get hacked." It's because the OpenBSD development crew beleives in coding properly. They don't audit for security, they audit for proper usage. And thats what we should be striving for. Engineering our software applications, and using the tools to do so, the correct way.
  • 1) If it works, not fix it.
    2) Any landing you can walk away from is a good landing.
    If you apply these two lessons to software design, you never have a problem.
  • Go look here [dreamsongs.com] for Richard Gabriel's ideas on this subject. In particular check out the Feyerabend project [dreamsongs.com] and one of his many "worse is better" [dreamsongs.com] essays, which has this to say about the current pattern movement and its effect on software aesthetics:
    More disappointing is witnessing this same effect at work in the patterns community. Christopher Alexander's ideas of patterns has as its smallest part the pattern form--the concept of patterns really has to do with pattern languages and QWAN (the Quality Without a Name). It is not about con-struction tricks. It is about building artifacts not only suitable for human habitation, but artifacts that increase their human inhabitants' feeling of life and wholeness. Alexander is all about beauty and quality, not about how to stick things together cleverly.


    Yet, the most popular form of software patterns is exemplified by those found in "Design Patterns," by Gamma, Helm, Johnson, and Vlissides, which contains little more than techniques for coding in C++ constructs found in other programming languages--for example, 16 of the 23 patterns represent constructs found in the Common Lisp language. There is no pattern language involved, and there is nothing about QWAN. Interest in patterns is coagulating around the so-called Gang of Four style, and it looks like things could get worse. In fact, I would say that patterns are alive and well as a form of documentation and a quest for clever solutions to common programming problems, and pattern languages, QWAN, and the quest for a better future are now on their way to the sewage treatment plant--the same place they went to in the world of architecture. Down with quality, up with clever hacks. Why worry about what makes a user interface beautiful and usable when you can wonder how to do mapcar in C++.
  • A better look (Score:5, Interesting)

    by Lumpish Scholar (17107) on Tuesday September 04, 2001 @05:22PM (#2253026) Homepage Journal
    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." [virginia.edu] --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")

    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' ... 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.

    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.
  • that's the beauty of open source programming -- and one of its downfalls. with open source, we CAN look at the internals of the software, judging the design to be a kludge (most likely) or something better. i say this can be a downfall, because with this comes the burden on a programmer who wants to open source some code -- making it 'pretty' enough to be released. We saw that with slash in the early years:

    Us: 'Show us the code!'
    Rob: 'It is too ugly and I do not want it seen yet.'

    (I suppose to be fair Rob's misquote should read 'Its too ugly'. Yes, the spelling is meant to be a joke.)
  • 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... Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty.

    If you want to follow your bridge analogy, then get out and take a look at a real bridge. Quite frankly, there's nothing very "beautiful" about it, except in an abstract sense, and even then, most likely from a distance. If you get right up close to it, you'll see rust spots, cracks, welds, patches, odd and seemingly arbitrary scars, and other features that look entirely out of place on a bridge... until you see an inspector's scaffolding hanging from the knobs you thought served no useful purpose.

    In other words, by your standards, bridges are a friggin mess. Really... I mean, they have no "internal beauty", once you're close enough to see how they're put together.

    Just like software.

    The folks using the bridge don't care about it's internal beauty, except peripherally... they care that the hunk o' steel and concrete under them doesn't give way and dump them into a river. Similarly, the folks using software don't care about it's internal beauty, as long as it doesn't give way and dump their data into oblivion.

    In fact, the only people who really manage to care at all about how bridges are put together are the people who build 'em. The same goes for software. There are plenty of reasons to write clear, easy to understand, well-documented code, without having to resort to some sort of appeal to a completely subjective quality like "beauty"; and there are plenty of ways to write high quality, reliable, high-performance software without making the same sort of subjective appeal. (Note that there is a difference, IMHO, between beautiful code and elegant code. I've seen some quite elegant hacks that had particularly butt-ugly implementations.)

    I'll go as far as to argue that while there are exceptions, generally, good software does not come from pretty code. Think about it - when your code is "beautful", first and foremost, that means that eventually you'll sacrifice reliability or functionality rather than produce "ugly" code. I'd rather ahve my source code be ugly and correct than beautiful and full of bugs any day of the week.

  • ...Simple programs have fewer bugs (because there are fewer lines of code which can be wrong), run faster (because there are fewer machine instructions)...

    int main(void)
    {
    unsigned long *foo,i;
    for (i=0;i<0xFFFFFFFFUL;++i)
    for (;;)
    {
    *(++foo)=0;
    }
    }

    Well, so much for those arguments. :)

  • Software quality will not improve until there is a financial reason for it to do so. Build something physical which is of poor quality and you're likely to be sued and/or imprisoned when it fails.


    Build software poorly, and you not only lock a client into a system that's so bad no one else can replace you, but you get lots of billable hours trying to fix bugs and upgrade the software.


    When lemon laws apply to software (and they should!), hiring people to write software who are actually competent will follow.


    -jon

  • by GCP (122438)
    Part of the problem is the nature of programming languages.

    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.

  • by Sludge (1234)
    Please, make the people I have to answer to demand good, clean code. More often than not, clients of mine want the job done right here, and right now.

    I had one PHB try to freeze the project, bring his friend in, add features, and resume the project (rather than compensate us for the features). Please, make everyone understand what quality internals are, so that I may have an understanding when I demand the resources for such a thing.

  • by An. (Coward) (258552) on Tuesday September 04, 2001 @05:37PM (#2253108)
    • Project managers would see the balsa mockup and tell the construction crews to just put the mockup in place because it's good enough to use as is.
    • Somebody would stop the project halfway through construction to insist that it be changed from a simple truss to a suspension bridge.
    • Somebody else would stop the project to insist that it be changed from a suspension bridge to a tunnel, and furthermore, to demand delivery of a tunnel for simple truss prices.
    • Massive traffic jams would occur as users stop at each end and call for help because they can't figure out how to drive across.
    • Architects would be sent out to tow cars and fill potholes.
  • When it's done. (Score:3, Insightful)

    by verbatim (18390) on Tuesday September 04, 2001 @05:44PM (#2253137) Homepage
    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.

  • ...Isreal and palestine should lay down their arms and live in peace; the oil companies should all band together to clean up the environment; all the children in the Third World should be fed; science should invent a cure for AIDS; and Palm should open-source BeOS.

    In the meantime, the author of this article ought to turn his attention to explaining to managers *why* they should care about beautiful software design. Until management gives us the time and budget to do otherwise, we engineers are just going to keep on writing code as well as we can within the contraints we're given. It's not like we *enjoy* writing crappy software.
  • by Sebastopol (189276) on Tuesday September 04, 2001 @05:52PM (#2253183) Homepage
    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!

  • Perhaps the reason that people don't expect much from software is that we are legally prevented from doing so. Let's face it, selling software without warrantying it fit for *any* purpose is nonsensical, and everyone does it. There's a vicious cycle at work; no expectations breed no impetus to improve breeds no expectations...


    -db

  • The "bridges and buildings" analogy has been done to death; so much so I suspect this whole topic is a troll. But at any rate, here are some important differences that may help explain why software appears to be created to a lower standard:

    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.

  • by skoda (211470) on Tuesday September 04, 2001 @05:55PM (#2253200) Homepage
    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.
  • Beauty is in the eye of the C-coder.

  • time to rant (Score:2, Interesting)

    this is what academics do... they sit in ivory towers and look down on the messiness of the real world and lecture us about how messy it is.

    "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. ;-P

    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! ;-P

    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 ;-)

  • by gelfling (6534) on Tuesday September 04, 2001 @06:06PM (#2253241) Homepage Journal
    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 problems (Score:3, Insightful)

    by The Pim (140414) on Tuesday September 04, 2001 @06:13PM (#2253276)
    There are two problems with this guy's approach:
    1. You can't learn to write good software by talking and reading about it in general terms. The best way to learn to write good software is the same as the best way to learn almost anything: practice, and get feedback from better programmers. Even though I think I understand where this guy's coming from, and I basically agree with him, I think his essay is basically pointless. I think the reason that so many of the posts here are critical is exactly that he is not specific enough to sway anyone who doesn't already look at the issue the way he does.

    2. To the extent that we do understand how to write beautiful software, we don't stand up for it. Although many posters make the obvious point that we are under pressure to get software done, this is not sufficient excuse for ignoring the values espoused in the essay, for two reasons: One, software that merely provides the required functionality may let the user get his job done, but typically requires him to learn the concepts used in the program and put up with its ideosynchracies, because the program doesn't work in terms of the concepts he already uses. This frustrates and alienates the user, and ultimately contributes to the low regard people have for computers. Look around you--almost every object pays some passable respect to usability and form. We shouldn't make (and sell) stuff that's ugly, cumbersome, confusing, and surprising, because it's dehumanizing.

      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.

  • by eschasi (252157) on Tuesday September 04, 2001 @06:13PM (#2253278)
    michael says:


    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.

  • Excellent book (Score:4, Insightful)

    by Phrogz (43803) <!@phrogz.net> on Tuesday September 04, 2001 @07:11PM (#2253537) Homepage

    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 [amazon.com] by Alan Cooper, the 'Father of Visual Basic' and also author of About Face: The Essentials of User Interface Design [amazon.com].

    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 :)

  • development price... (Score:3, Interesting)

    by anshil (302405) on Wednesday September 05, 2001 @02:45AM (#2254610) Homepage
    Hmm I fear posting so late nobody might read this, but well I'll post eitherway ahead.

    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 :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. */
    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.

  • by Ukab the Great (87152) on Wednesday September 05, 2001 @04:57AM (#2254775)
    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.
  • by Performer Guy (69820) on Wednesday September 05, 2001 @06:55AM (#2254882)
    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.

I bet the human brain is a kludge. -- Marvin Minsky

Working...