Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Software Aesthetics

michael posted more than 13 years ago | from the when-tidy-is-not-sufficient dept.

Programming 748

cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.

cancel ×


Sorry! There are no comments related to the filter you selected.

Case in point: (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2252792)

Linux. Bleach.

But what about... (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2252833)

Windows. Starch.

Satanist music kicks ass! (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2252930)

King Diamond fucking rules!

Frothy piss! (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2252793)


Hello again... (-1)

cyborg_monkey (150790) | more than 13 years ago | (#2252796)

Another low hug!

Beautiful software (3, Funny)

quartz (64169) | more than 13 years ago | (#2252799)

My software is so ugly it's beautiful. I'm coding in Perl these days. :)

Re:Beautiful software (-1, Flamebait)

Anonymous Coward | more than 13 years ago | (#2252891)


FP? (-1, Offtopic)

Cowboy Deejay (414387) | more than 13 years ago | (#2252802)

*crosses his fingers*

software is incredibly complex... (3, Funny)

swagr (244747) | more than 13 years ago | (#2252803)

kind of like the innards of a biological organism.

Ever disected anything? It's MESSY.

Re:software is incredibly complex... (1, Insightful)

Anonymous Coward | more than 13 years ago | (#2252823)

Actually, it is amazingly elegant and well thought out--(maybe "thought" is too strong).

Organisms are incredibly adept at reusing design and building specialized components from generic building blocks.

They just happens to ooze.

Re:software is incredibly complex... (2)

swagr (244747) | more than 13 years ago | (#2252906)

Or you could see it as...
absurd redundancy and "cut & paste hell"
The same data in each cell!!
Plus there are no implementation related interfaces: What can I replace my hand with, and how easy would it be?

Re:software is incredibly complex... (2, Funny)

ethereal (13958) | more than 13 years ago | (#2252950)

They just happens to ooze.

That's a feature, not a bug :)

Re:software is incredibly complex... (3, Interesting)

Blue Neon Head (45388) | more than 13 years ago | (#2252886)

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

Re:software is incredibly complex... (0)

Anonymous Coward | more than 13 years ago | (#2252898)

The source code is in every cell.

Re:software is incredibly complex... (1)

Yokaze (70883) | more than 13 years ago | (#2252937)

Is currently beeing reverse engineered.
Wonder if the DMCA applies here, too. :)

I Can see the point... (2, Offtopic)

sl3xd (111641) | more than 13 years ago | (#2252805)

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.

Re:I Can see the point... (1, Interesting)

Anonymous Coward | more than 13 years ago | (#2252827)

An architect's designs cannot do anything, they only tell you how to build a structure. Code can be turned into a working piece of software with no effort (compaired to constructing a building)

Re:I Can see the point... (0)

Anonymous Coward | more than 13 years ago | (#2252866)

So once we develop automatic home-building robots, the architects will suddenly lose their rights? I don't think so.

Not this stupid 'programming is art' BS again! (1, Insightful)

Flabdabb Hubbard (264583) | more than 13 years ago | (#2252879)

to recognize the artistry involved in writing software

What pretentious bullshit. Software is NOT art. It can be closely compared to bricklaying, or cabinet making, it is a CRAFT.

Try expressing an emotion in C++. It cannot be done. 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.

Re:Not this stupid 'programming is art' BS again! (1)

FortKnox (169099) | more than 13 years ago | (#2252918)

Now now. Art can be seen in any type of medium, even coding.

You may not understand it, but only the artist needs to.
I can see art in some obfuscated code I've seen.

Who are you to tell me what is art and what isn't?

Re:Not this stupid 'programming is art' BS again! (3, Insightful)

servo8 (572) | more than 13 years ago | (#2252939)

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?

And this is news? (1)

ptgThug (515679) | more than 13 years ago | (#2252806)

While I personally try to produce something I can be proud off, saying there is shody work out there is not news.

I would wager that most car mechanics, plumbers, electricians, home builders, anyone-who-works-on-something-you-don't-see are crooked, cutting corners where they can and shamming the public.

Other trades include: (1, Funny)

Anonymous Coward | more than 13 years ago | (#2252885)

education, medicine, accounting, law,
and journalism.

blah (2, Insightful)

teknopurge (199509) | more than 13 years ago | (#2252807)

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 [] . help us beta.

Re:blah (1)

bmj (230572) | more than 13 years ago | (#2252902)

There is usually a tradeoff between quality and expediancy.

i agree. can anyone shed light on what the typical iteration period is for structural engineers and architects? i'd be curious to know if they are put under the same time constraints as software developers.

i would also tend to think that the learning curve for developers can be a bit faster (thanks to rapid development cycle). that might lead to inexperienced developers getting involved in system design. it may not be that they are bad programmers--their managers may have given them responsibilities above and beyond what they can do. the average developer should spent some time as a code monkey (or perhaps just remain as a code monkey for their whole career).

VA Linux (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2252813)

VA Linux fucking sucks.

What the Fuck is this "There is nothing for you to see here, movie along" bullshit!?!?!??!?!

Another plot by the VA Linux faggot staff to make Slashdot unusable?

Re:VA Linux (-1, Offtopic)

Anonymous Coward | more than 13 years ago | (#2252830)

Don't worry VA Linux closed at an all time low of 1.25 today, shit you can't buy a fuckin subway token with that, bwahahah, va linux is gonna get bought or go out of business.

Either way don't worry i'm sure slashdots new owners won't be so gay.

Beauty for beauty's sake makes crappy software (5, Insightful)

GusherJizmac (80976) | more than 13 years ago | (#2252817)

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.

Re:Beauty for beauty's sake makes crappy software (5, Informative)

Telek (410366) | more than 13 years ago | (#2252921)

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!

Re:Beauty for beauty's sake makes crappy software (0)

Anonymous Coward | more than 13 years ago | (#2252944)

but if you just 'meet the user requirements' you can still miss a ton of other non-user requirements.
well commented code isn't a user requirement, but it sure a heck is a good programming practice and usually a technical requirement.

your answer strikes me as the lazy developer telling the manager "it works doesn't it?" when asked if the app is maintainable.

Ha, but really. . . (2)

Laplace (143876) | more than 13 years ago | (#2252821)

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.

Re:Ha, but really. . . (1)

kurowski (11243) | more than 13 years ago | (#2252884)

No, if you write beautiful, maintainable code then you won't get replaced by someone who prefers to hack together something that just works. Decent employers recognize excellence, especially when the project's lifespan is measured in months or years, not days or weeks.

Re:Ha, but really. . . (1)

TomRitchford (177931) | more than 13 years ago | (#2252889)

Laplace wrote:
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.

For my part, every minute I spend on making my code cleaner and more aesthetic comes back to me three-fold when I find bugs before the testers do and when I have to make changes later. Life is too short not to do your best work all the time!

and yes, I do have samples.

Re:Ha, but really. . . (0)

Anonymous Coward | more than 13 years ago | (#2252932)

Are you in management? You sure sound like it. A _good_ programmer will save several days coding for each day of planning. But in your case - it's probably a waste of time.

Planning and review save time and money (5, Insightful)

tim_maroney (239442) | more than 13 years ago | (#2252954)

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.


complexity (5, Interesting)

radish (98371) | more than 13 years ago | (#2252824)

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

Re:complexity (1)

lammi (52951) | more than 13 years ago | (#2252907)

Instead of a bridge the example of a Xerox machine should be used, something that takes input and gives output, but more importantly has a bunch of moving parts that consistently break down.

The reason that law offices have rows of copying machines isn't just because they make massive amounts of copies, its also because they realize they need backups when one dies.

Re:complexity (0)

Anonymous Coward | more than 13 years ago | (#2252912)

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.

And the design of software is the application of a few very simple logic principles to the task at hand. If I apply the same level of abstraction as you have above, it has basically one requirement: it must run.

Unless you've ever been involved in such a thing, or talked extensively with someone who is, you have no idea of the massive complexity of most civil engineering projects. Software looks like a child's game in comparison.

Most software is bad for two basic reasons: most of the people writing it are incompetent, and they can get away with it.

Open Source, of course (2)

infiniti99 (219973) | more than 13 years ago | (#2252825)

When your code is on center stage you want it to look good.

Re:Open Source, of course (3, Funny)

CrosseyedPainless (27978) | more than 13 years ago | (#2252900)

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

Re:Open Source, of course (1)

FortKnox (169099) | more than 13 years ago | (#2252904)

but without a coding standard that you state up front you have multiple coding styles.


int main ( int argc, char** argv )

foobar(char foo, int bar){

void foobar2(char * blah)

Three different styles makes the code harder to read...

Re:Open Source, of course (2)

Telek (410366) | more than 13 years ago | (#2252952)

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.

nice, but welcome back to the real world (3, Interesting)

room101 (236520) | more than 13 years ago | (#2252826)

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.

Re:nice, but welcome back to the real world (1)

Shimmer (3036) | more than 13 years ago | (#2252870)

I tend to agree. I develop custom software for a living. The plain truth is that most of my clients are not willing to pay for high-quality software. They want something that works ASAP -- damn the torpedoes. I frequently have to explain to them why software quality is important.

-- Brian

Re:nice, but welcome back to the real world (1)

jbum (121617) | more than 13 years ago | (#2252929)

> I need it to work, not look good.

Hear hear. Engineers with an over-developed
aesthetic sense are writing their code for other
engineers, not the end-user. Too many times
in my professional life have I seen inordinate
amounts of time wasted on issues which are
invisible to the end-user, because some overly-
aesthetically minded engineer couldn't sleep at

It's a craft, not an art; and if you can't sleep
at night, try getting laid.

some suggested resources (5, Interesting)

Satai (111172) | more than 13 years ago | (#2252829)

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?

Its a "I'll do it later" thing... (2, Insightful)

FortKnox (169099) | more than 13 years ago | (#2252832)

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.

internal beauty of software (1)

porky_pig_jr (129948) | more than 13 years ago | (#2252834)

once I was working on network performance monitor (written in C). Once I had a 'basic proof of concept' (quick and dirty, but mostly functional), I've told the interested parties I would have to re-write it so it would be modular, easy to read and understand and of course easy to debug. To my surprise those jerks gave me a hard time (noone gives a shit about your 'aesthetical feelings'). Well I did make some minimal changes and left the company soon after that. Hope someone is still struggling maintaining the code. The bottom line is that 'inner beauty' of any software is not a luxory item.

If you ask me... (1, Interesting)

The Slashdolt (518657) | more than 13 years ago | (#2252837)

If you ask me, it's those damn comments! They make my code look ugly! I write thousands of lines of beautiful code, only to have to return to it to comment it so joe programmer can come along and "maintain" it later. If it weren't for the comments, my code would be more beautiful than a bridge!

And BTW, did anyone notice that this guys code snippets are in Basic? That's enough to dismiss the article right there!

Re:If you ask me... (1)

RetroGeek (206522) | more than 13 years ago | (#2252925)

Comments nothing

It's all those damn logging calls.

Of course his software stinks. (0, Redundant)

emf (68407) | more than 13 years ago | (#2252841)

Of course that guys software stinks, he's using Visual Basic. ( Check the code sample )

This is news? (0, Redundant)

feydakin (161035) | more than 13 years ago | (#2252842)

This is news to some people?

This complaint is as old as most code. There has always been a better way to do things. It's just not the most profitable.

virtues of programming? (2, Interesting)

aarestad (154626) | more than 13 years ago | (#2252844)

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

And the quality HTML award goes to... (0, Offtopic)

Brazilian (98980) | more than 13 years ago | (#2252846)

... Charles Connell, for creating more "lousy" software. Call me crazy, but I would think that if you wanted to rant about "lousy" software you'd have the presence of mind to write decent-enough HTML so that the character " didn't show up as ? and bullets didn't show up as the character Y.


kilgore_47 (262118) | more than 13 years ago | (#2252849)

This article is a challenge to engineers, managers, executives and software users (which is everyone)

Lets be fair now. Some people actually don't use software (or computer technology of any sort).
Of course, no one any of us know.... but i'm sure such people exist!

NO !! (0)

Flabdabb Hubbard (264583) | more than 13 years ago | (#2252850)

Software engineering is there for one reason only. To perform a business function for the minimal amount of outlay. It is unlike bridge building in so many ways. Most software is only live for a couple of years at the most. This kind of VB quick hack does not need heavy duty architecture

Conversely where this approach is required (saftey critical systems) Formal Methods such as Z and VDM are often applied to prove the correctness of the specs etc and therefore guarantee bug free code.

As ever it is Horses for Courses. Don't lump all software developers together.

Crap inserted to avoid lame compression filter what is this bullshit ? slashdot has really gone down the tubes don't know why I keep coming back ! thank you.

Harumph! (1)

tbone1 (309237) | more than 13 years ago | (#2252853)

And when managers become reasonable and don't change things constantly without extending the deadline, this might be a real issue. As it stands now, most of us are just trying to get our jobs done before we're fired by people who make Dilbert's boss seem like a paragon of rational enlightenment.

*ACK* VB!! (1)

Anonymous Coward | more than 13 years ago | (#2252854)

The article has code fragments. Just now I noticed it was VB!

Why not show C++, C, or Java? That way you can really show the difference of a bad written program compaired to a good written one...

Good software takes time (2, Interesting)

gss (86275) | more than 13 years ago | (#2252855)

Unfortunately tight timelines always negativlty affects the quality of software. This is why I'm a total believer in refactorting. [] 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.

Re:Good software takes time (0)

Anonymous Coward | more than 13 years ago | (#2252947)

Good design begins with correct spelling [] .

I agree and disagree (1)

Uttles (324447) | more than 13 years ago | (#2252856)

I come from a computer engineering background so I would love to see fundamentally sound software that is clean, efficient, and fast. On the other hand, compilers are very good at optimizations these days, and processors even have methods of reorganizing instructions to gain speed, so one can argue how necessary it is for code to be perfect. I would like to see "beautiful" code, but I don't really think there would be much performance improvement.

You want to see beautiful code? (2)

Luke (7869) | more than 13 years ago | (#2252860)

Check out the source to Darren Hiebert's ctags [] . Best-designed C program I've seen yet.

Re:You want to see beautiful code? (0)

Anonymous Coward | more than 13 years ago | (#2252882)

PS - I didn't add that [] shit. Don't you like how they mess with comments arbitrarily?

Re:You want to see beautiful code? (0)

Anonymous Coward | more than 13 years ago | (#2252943)

PPS - You can turn that off in your preferences. I think it's to keep people from getting directed to goatse. :)

And How!!! (4, Insightful)

Telek (410366) | more than 13 years ago | (#2252862)

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.

A Prime Example (1)

docstrange (161931) | more than 13 years ago | (#2252864)

Is it just me or is computing going backards. It used to take 2 seconds to boot into DOS, yet it takes 20 seconds or so to boot into Windows 2000. We have various gui based medical management software that we manage at my place of employment, but the old dos versions were far more efficient. Call me a hermit, but I think that the "user friendly, gui=productivity myth" needs to die. Visual basic should not be used for ANY production applications. Especially in mission critical system. That aside, I would like to thank all of the crappy programmers, for providing me with job security. As long as your stuff breaks, my future looks bright.

Blame the customers... (1)

fleeb_fantastique (208912) | more than 13 years ago | (#2252865)

In commercial software, customers drive a demand for new software such that companies are punished for taking the time to try to get the software right. Time and again, when offered the choice to go with software that has been well-written versus software that is poorly written (but available today), the customer will choose what is available today.

I do not see this changing anytime soon.

It depends (1)

shd99004 (317968) | more than 13 years ago | (#2252869)

The software for millions of home PCs doesn't have to be that bugfree, really. There is no catastroph if a computer crashes now and then. The prices are kept pretty low, but instead it's not perfect. The better and more error free code you want, the more expensive will it be. For example, the software running at a nuclear power plant or in the space shuttle is probably very error free and has very few bugs. However, the time to develop it and the cost, must be way higher than any other system. It's all about how many errors you can tolerate in a system.

Public Safety (0)

Anonymous Coward | more than 13 years ago | (#2252873)

Bridges are designed the way they are because there's a large need to ensure public safety. That is why you have licensed engineers reviewing plans and signing them.

Code is just not as important. If it there is a malfunction, no one dies. If there is that possibility, then higher coding standards must be met.

flawed analogy (4, Insightful)

funkapus (80229) | more than 13 years ago | (#2252874)

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.

Good code comes from good programmers (1)

pudge_lightyear (313465) | more than 13 years ago | (#2252875)

Good programmers work for good money. How can you expect good programmers to be involved in projects that don't pay good money... Easy answer. You can't.

I also like this post for this reason. I think it serves to rally all of the programmers in the world to get together and agree to write good code. See, I write sloppy code on purpose. Now that I know that I'm not supposed to, I'll start writing clean code.
I came up with a cheer too...:
Rah Rah Ree! We Like our Code Clean! Rah Rah Ro! Sloppy Code Must Go!

Terrible analogy ahead (1)

Fjord (99230) | more than 13 years ago | (#2252877)

Designing 5-9s software for commercial use is like making a knife out of diamonds. Sure, it's more durable, but it costs a hell of a lot more than people are willing to pay.

Perhaps the house analogy is flawed as well... (1)

daoine (123140) | more than 13 years ago | (#2252878)

Take a look at the average house today as opposed to one built in the early 1900s. Today's houses are cookie cutter style boxes that look exactly like the ones next to them. Furthermore, these houses aren't going to last very long...I know WAY too many people who have dealt with shoddy construction of newer houses.

Houses today aren't nearly as ornate as before -- there is very little woodworking, no secret passages, not too much stands out.

The software world is much like today's house market -- contract to the lowest bidder, make sure it doesn't show any weaknesses until after purchase, and who really cares if the sheetrock cracks and the beams bow after you've sold it?

It's hard to try and make software look like Victorian houses -- nobody wants to pay for the added effort and longer wait. Especially when a cookie cutter Colonial will get the job done.

Wow, good one (2, Interesting)

Sinical (14215) | more than 13 years ago | (#2252881)

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.

Code beauty.. (0)

Anonymous Coward | more than 13 years ago | (#2252888)

OpenBSD... Nuff said...

And don't forget this one .... (1)

Zero__Kelvin (151819) | more than 13 years ago | (#2252890)

Most people who write papers chock full of sweeping generalizations have no idea what they are talking about ....

Unrealistic Deadlines (1)

J0ey4 (233385) | more than 13 years ago | (#2252893)

The main reason that most software design sucks is that the engineers are not give enough time to do the project right. The idea is that you just get it out to market and you can always patch it later. Try telling some guy with an MBA whose making all the decisions that it is better to take enough time to do a project properly. All he/she knows is that the "magic black box" will produce the same output whether the design is good enough.

So the same scenario is repeated over and over:

Engineer: "I can get this done in 10 months"

Manager: "Hmmm..... we need to get it done in 6."

Engineer: "That's not enough time to design and implement a clean, extendable, reusable product!"

Manager:(Confused by big words like 'extendable')
"It'll work though right?"

Engineer: "Well yeah, but..."

Manager: "Just get it done in 6 months."

As long as you have people who have no clue about software making deadline decisions, you're gonna have to hack like hell for 60 hours a week just to get it out the door. It's sad but true. Granted this isn't ALWAYS the case but in my experience it is most of the time.

If you want to take the time to do a project cleanly then I think academia is your best bet.

Re:Unrealistic Deadlines (2)

Andrewkov (140579) | more than 13 years ago | (#2252953)

Or open source, where you release your product when it is done, not according to an arbitrary schedule.

Human Factors... (1)

dane23 (135106) | more than 13 years ago | (#2252894)

I don't know about anyone else here but I HAD to take a Human Factors [] class before graduation from college. I'm damn glad of it too.

Building codes (2)

DJerman (12424) | more than 13 years ago | (#2252896)

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

You're all fucking next (-1, Troll)

Anonymous Coward | more than 13 years ago | (#2252897)

All you motherfuckers are gonna pay, You are the ones who are the ball-lickers. We're gonna fuck your mothers while you watch and cry like little bitches. Once we get to Hollywood and find those Miramax fucks who are making that movie, we're gonna make 'em at our shit, then shit out our shit, then eat their shit which is made up of our shit that we made 'em eat. Then you're all fucking next.

Love, Jay and Silent Bob

Death March (1)

digerata (516939) | more than 13 years ago | (#2252899)

The article has a lot of merit and its an evolving art for most programmers. Charles forgot to point out one thing. Most houses these days are forced to be built under the same demanding client deadlines and requirements. You may have to rush building a house, but I have never heard the term "death march" applied to building a house. Beautiful code isn't an luxury in many of todays coporate software environments.

His analogy doesn't work (5, Insightful)

whjwhj (243426) | more than 13 years ago | (#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.

will (and should) never happen.... (0)

Anonymous Coward | more than 13 years ago | (#2252903)

This is stupid. Software will never be failsafe and pretty--the open source guys, who aren't dictated by release schedules and costs can do this--I'd love to be able to write perfect, pretty code--it just isn't realistic. Software costs money. Quality is directly releated to the amount of money your willing to flush on it. Software design != bridge building...nuff said

Not CS fault. (3, Interesting)

Capt_Troy (60831) | more than 13 years ago | (#2252908)

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.

Not always true... (1)

bteeter (25807) | more than 13 years ago | (#2252909)

Not all code is built so poorly. In fact, most code is built quite well.

Just like things in the physical world, code almost always does what it was built to do quite well. For example: Microsoft Word is an excellent Word Processor, but a poor/pathetic drawing program.

Also just like things in the physical world, code is used for things it was not intended to be used for. Have you ever driven your Geo Metro through a river? Have you ever driven a tractor trailer over an old wooden 1 lane bridge? No, probably not. You would be crazy to try something like that.

People try to do things with software all the time that it was never designed to do. That is a big reason why software fails so often.

Of course most of these "things software wasn't designed to do" aren't always documented. For instance, Outlook Express is a decent mail program, but did you know that it almost always fails when you have more than 10000 emails in your database? It is not documented anywhere by Microsoft, but they have admitted to myself and others on their tech support line that Outlook Express fails due to faults in the mail database. Their theory is that OE was never meant to be used "that much" - so you should use the "industrial strength" Outlook instead.

If only we all knew what the true design limitations of the software we use were we would be much better off. In the physical world, this is very easy to measure. That bridge you just drove over to get to work? It has a nice little sign that says "capacity 6 tons". You would be a little nuts to drive a 40 ton cement truck over it now wouldn't you? People do that sort of thing with their computers all the time and just never know that they are doing it...

Take care,


100% Linux Web Hosting - No Windows - Fanatical Technical Support - Customer Loyalty Discounts []

Fit the Terrain? (1)

Relic of the Future (118669) | more than 13 years ago | (#2252910)

The site for a building is the slope of its land, its orientation to the sun, its local weather, other buildings nearby, etc. The "site" for a software system is its computer hardware, the operating system, any middleware (such as database or security systems), other software applications on the computer, and the style of the intended users.

That's ludicrous. Much of the software in the world today is designed to be portable. Various hardware, multiple OSes, etc. etc. Perhaps in the age of mainframes this idea of "terrain" was appropriate, but today? Hardly.

Bullshit! (0)

Anonymous Coward | more than 13 years ago | (#2252911)

Think about sufficiency and cost. Most houses are built to meet our housing needs in a sufficient manner. Should houses be constructed to last 500 years and survive F5 tornadoes without any damage? How much do you think that an average sized house built to these standards might cost? The reality is that software is constructed to sufficiently satisfy business needs. That means both cost and performance. And every product has compromises. Even the ones with the best combinations of compromises are not necessarily the best selling or most profitable. Usually the products that have the best marketing and sales force behind them dominate their markets. Nimrod! Good luck finding Utopia. For more information, goto

Clean code = cost savings (0)

Anonymous Coward | more than 13 years ago | (#2252917)

For all the management out there to keep putting deadlines on things that can't be met. Think about it. If you fix something before it is released, you will save your self thousands techsupport phone calls per release! That saves money!

Clean code means cost savings!

Code aesthetics (2, Insightful)

KingAzzy (320268) | more than 13 years ago | (#2252919)

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.

Code "seems" to work (2, Insightful)

tomlouie (264519) | more than 13 years ago | (#2252920)

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.

Software quality is inconsistant because... (1)

gatkinso (15975) | more than 13 years ago | (#2252922)

...humans are the ones developing it.

Once a means of expressing unambiguous software requirements to a computer is developed machines will do all of our "development".

Modern programming languages are merely a step in this direction.

You Retard (1)

newt_sd (443682) | more than 13 years ago | (#2252923)

Is this your first day in the wide world of business. Good luck with this mission. I agree with you don't get me wrong but come on unless you don't care about turning a profit their is no incentive to put out quality work. I applaud everyone that takes the time to produce quality i really do but you people are few and far between.

another interpretation (1)

10am-bedtime (11106) | more than 13 years ago | (#2252935)

beauty is in the eye of the beholder. beauty is an act of recognition, in essence, a verb. an artifact of process can have hints of the beautiful (or ugly) actions that go into its creation, but no more.

if you want truly beautiful software, you have to use truly beautiful process, expose the process, and help both purveyors and surveyors educate themselves to refine their aesthetic.

this article is itself ugly to me because (1) some weird-ass language example; (2) strange formatting that causes "?" to appear in unexpected places; (3) overfocus on the artifact. (feel free to disagree w/ my aesthetic [] .)

IMHO, admonishing people to write beautiful software is almost as much a waste of time as commenting on such endeavor.... :-/

XP! (4, Insightful)

Proud Geek (260376) | more than 13 years ago | (#2252936)

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!

Structures have by-laws to follow. (2)

GoofyBoy (44399) | more than 13 years ago | (#2252941)

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

Oh Yeah... (2)

Greyfox (87712) | more than 13 years ago | (#2252945)

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.

Beauty is the code (enhance, embrace, and extend) (2, Interesting)

awerg (201320) | more than 13 years ago | (#2252946)

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.

features vs bugs (2)

josepha48 (13953) | more than 13 years ago | (#2252949)

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... (2)

swm (171547) | more than 13 years ago | (#2252957)

Writing software is writing, and the fact is that most people don't write very well.

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?