Software Aesthetics

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

Re:Beauty for beauty's sake makes crappy software

[Telek]

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!

If bridges were programmed...

[An. (Coward)]

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

Re:Beauty for beauty's sake makes crappy software

[jfunk]

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.

Perl Software Pet Peeve: not using warn and strict

[linkyours]

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

Re:XP!

[chipuni]

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.