Software Aesthetics 748
cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.
blah (Score:2, Insightful)
There is usually a tradeoff between quality and expediancy.
teknopurge
http://techienews.utropicmedia.com [utropicmedia.com]. help us beta.
Beauty for beauty's sake makes crappy software (Score:5, Insightful)
- 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:software is incredibly complex... (Score:1, Insightful)
Organisms are incredibly adept at reusing design and building specialized components from generic building blocks.
They just happens to ooze.
Its a "I'll do it later" thing... (Score:2, Insightful)
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.
And How!!! (Score:4, Insightful)
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)
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.
Not this stupid 'programming is art' BS again! (Score:1, Insightful)
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.
His analogy doesn't work (Score:5, Insightful)
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.
Code aesthetics (Score:2, Insightful)
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 (Score:2, Insightful)
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)
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:Not this stupid 'programming is art' BS again! (Score:3, Insightful)
Planning and review save time and money (Score:5, Insightful)
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
Bad analogy. (Score:2, Insightful)
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.
Specs Sucks! (Score:1, Insightful)
I agree, most code look horrible and is a terrible mess, but that is a side effect of external forces, not because programmers need to be inspired to write clean beautiful code by some article.
software manager managing bridge architects... (Score:1, Insightful)
engineer -> yes, but it's really big and really important
manager -> yes, but it has to ship in 3 months.
engineer -> so how much weight does it need to support?
manager -> i dunno, I'll let you known in 2.9 months.
engineer -> what is it bridging?
manager -> why all these stupid questions, start building.
engineer -> I should do an architectural drawing first.
manager -> why bother, here's some metal, start slapping it together. Remember it ships in 2 months.
engineer -> I thought you said 3 months?
manager-> oh didn't I tell you, we heard a rumour that a competitor will be shipping their bridge in 2.5 months, so we have to beat them.
continue forever.
the reason there is no internal beauty is we (engineers) aren't given any time to build quality (although the argument could be made that the only way to build on schedule is by building quality). The other problem is, bugs actually translate into lucrative support contracts for most enterprise software vendors. Why improve quality? there is no revenue stream there. If users would SUE software development firms (the same way people would sue if a bridge fell when you drove on it) then vendors would suddenly find time in schedules for testing and quality.
we do the best we can, given the pressures. My advice, try to learn to say "no" to your manager once in a while, and hire a QA manager with balls who won't let shitty software ship.
Re:Beauty for beauty's sake makes crappy software (Score:4, Insightful)
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.
Re:Not this stupid 'programming is art' BS again! (Score:5, Insightful)
Very perceptive...coding software is like crafting a cabinet. However, designing a cabinet is art...and so is designing software.
Try expressing an emotion in C++. It cannot be done.
jesus->loves(you); // Sarcasm, for the humor impaired
Regardless, art doesn't just express emotion, it inspires emotion. And trust me, I've had (mostly other people's) C++ code inspire some pretty horrific emotions. ;-)
Good design and coding, on the other hand, can truly be things of beauty, regardless of language.
Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
Spoken like someone who just doesn't really comprehend software design, or why one design might be more elegant than another. I suppose you don't think mathematics is beautiful either...
186,282 mi/s...not just a good idea, its the law!
True, but code maintainability can be critical... (Score:3, Insightful)
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.
Re:Beauty for beauty's sake makes crappy software (Score:3, Insightful)
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.
Re:software is incredibly complex... (Score:2, Insightful)
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.
Re:complexity (Score:5, Insightful)
-- 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:XP! (Score:3, Insightful)
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:nice, but welcome back to the real world (Score:5, Insightful)
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.
Analogy better than ever (Score:1, Insightful)
Of course, if when I go down to my fuse box I just see an unlabled rat's nest of wires I'm going to be mad at whoever did the (half-assed) job. Then let's say I decide to add a room. The new contractor comes to me and says, "Well, we can't figure out how the first guy wired everything so we're just going to add a second meter for the additional room and give it a completely independant system".
Re:software is incredibly complex... (Score:2, Insightful)
When it's done. (Score:3, Insightful)
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.
Good design is bad (Score:1, Insightful)
At the same time I must admit that good design is not good business. No, it does not take longer to come up and implement good design. The problem is most software engineers don't understand good design. They can't maintain it.
Bad programmers can write code that other bad programmers understand and can maintain. They are the majority of the department so smart managers are wary of the one or two good designers they have.
A tiny example:
int strlen(const char *s)
{
int n;
for (n = 0; *s++; n++) ;
return n;
}
#define MAX_STRING_LEN 101
int strlen(char s[MAX_STRING_LEN])
{
int i = 0,len;
if (s[i] == 0) {
return(0);
}
else {
len = 0;
while (s[i + 1] != 0) {
len++;
i++;
if (i == MAX_STRING_LEN) {
return(-1);
}
}
return(len + 1);
}
}
The former implementation is more beautiful, but not something most software engineers could come up with. The uglier implementation is something they would immediately feel at home in. A good manager should discourage the better design "which only PhD's could understand and maintain."
Re:software is incredibly complex... (Score:5, Insightful)
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.
management and interns (Score:4, Insightful)
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!
Two problems (Score:3, Insightful)
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.
Good article, but... (Score:2, Insightful)
Not all software needs this much care Certainly if it's for you and your friends it can have all sorts of caveats, such as you can't have more than 3 windows open, and doesn't support adding and removing something at the same time, because the audience isn't big enough to justify the time. Sort of like how a lot of college kids build their own furniture out of 2x4s and cinder blocks. Which is sort of along the lines of:
Some software is temporary Software with limited lifespan (especially those stopgap solutions) is often valued more if it is realeased sooner, so in my opinion it's acceptable for it to have rough edges. I think of it like those metal plates they put down to cover holes in the road while they lay pipes or whatever: they suck right now, but they'll be gone soon. Even for continuing projects a lot of features are faddish, in vogue while they are being designed, but by the time they get implemented, a new way is catching on. It's the pace of the industry that leads for so much corner-cutting.
The complexity of large software projects is unprecedented I've often explained software to my (non-technical) friends as similar to building a car out of watch parts. And those are only for the smallish projects I've worked on. Software is virtually always a one-of-a-kind creation, so defects don't get "ironed out" over the production span. Actually, try taking 200 (or more) professionals from any discipline and see if they can work for a year on a project and see if they can produce something cohesive. Artists? They'd be too concerned about their individuality. Prototype car engineers? Ok, but what if they had to do everything by hand? That engine sure wouldn't be so smooth now would it?
Point: Software creation is unique, in no other industry is there so little refinement of existing features, because there is such a high pace of invention. Only the Space Station seems (to me) to match software development in terms of scope, collaboration, and uniqueness; and it seems to have all the same problems as software development does.
One last thing, these are excuses, but you should mostly listen to the article.
Java is inefficient (Score:2, Insightful)
I've done projects in C, VB (im not proud), C++ (yep MFC et al, 5 years) and Java (1.5 years now), and I question the statement that java isn't efficient.
I guess the gripe I have with this statement is your definition of efficiency. I won't argue that Java executes slower than an equivelent C++ program, after all it runs on a virtual machine that does have to do an amount of work to translate java byte code to native executable code, however, Moore's law applies here - machines and JIT (Just in Time) compilers will always get faster, as well as implementations of Swing and other graphics libraries.
However, I also like to think of efficiency in terms of developer hours, support and maintainence. Java outshines C++ in its ability to clearly express your ideas in a way a machine can understand. It frees the programmer and maintainer of the details of memory management. Not that a developer doesn't have to understand memory management and the implications of holding references to objects, but that allocation and freeing of memory isn't a constant requirement. Every C++ program of sufficient complexity has to be tested and debugged for memory leaks - someone always forgets to add a destroy call somewhere.
I won't even mention buffer overflow problems
While I'm on the subject, and although I seem to be praising Java a lot here, there are always places for each language. I don't think Java would be a good choice of language to build a kernel in, for example. But a JVM based kernel? Well, a JVM couldn't be written in Java, could it? (think about that)
And I wouldn't worry about Java being a proprietry language, as long as your java code executes in Kaffe and can be compiled with gcj (the gcc, java compiler, or something like that), then we will always have an open source program that will run accross many OSs and devices.
To sum up, Java is generally a more elegent language than C++, this leads to code with quicker times to market, less bugs and less cost in support and maintenance - efficiency isn't everything, afterall, "premature optimisation is the root of all evil" -- Donald Knuth, and how much more premature can you get than in choosing the implementation language?
Re:software is incredibly complex... (Score:5, Insightful)
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...
Re:complexity (Score:3, Insightful)
One of my best friends in college just finished their masters this weekend. She most definately did not slack off for the last 6 years; I can't count the number of times she pulled all nighters to get things done.
The difference between engineering a bridge and writing software is that all of the major problems with building bridges have been solved. There is a lot of math and a complicated series of steps and tons of engineering work involved, but the problems have been solved. We already know how to build bridges. We may not know the particulars on how to build a bridge that spans 2000 feet and can hold 500 tons, but the basic theory on how to do this is known.
Additionally, the application for civil engineering projects are very well defined. They have a small task that they need to perform.
I think that the most interesting work being done in civil engineering these days is materials research.
Software on the other hand doesn't have all of the problems already solved. We've come a long way in the last decade or two, but we've come far from solving all problems. I think it's safe to say we've solved all of the simple, basic problems, but the more complicated problems still exist.
The other problem with software is the scope. The scope of most software packages today is HUGE.
It involves problems that havn't been solved a 100 times already. And they are non-trivial problems. Sometimes the problems are actually hard to understand -- how do you approach a compression or encryption problem for example.
Another problem with software that makes it hard to compare with civil engineering is that it only takes one mistake to bring the whole thing crashing down; on a bridge, odds are if a bolt is misplaced the bridge will not fall -- there is built in redundancy; this is not a feature possible to have present in software (not unless you write the software 3-5 times, and have an agreement between routines about the result of a function call).
There are tons of differences between traditional engineering and software engineering that makes comparing the two fields difficult if not impossible.
Re:Beauty for beauty's sake makes crappy software (Score:3, Insightful)
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.
Excellent book (Score:4, Insightful)
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 :)
Re:Beauty for beauty's sake makes crappy software (Score:5, Insightful)
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.)
Better Code / Extreme Programming (Score:2, Insightful)
The reason for this I believe is the heavy use of Unit Testing. By testing first you have normally thought of a very elegant/simple design by the time you write the real code. It is also easy and safe to improve the code because you can check it passes the tests. But the tests also mean there is a great reluctance to change the overall architecture of a project because you will break hundreds of tests that will need to be moved, changed or rewritten.
Another thing that helps with code quality in XP is the fact that you write it with a partner and within a week at least 5 other people will probably have criticised it
Re:complexity (Score:5, Insightful)
That's an easy one to answer. Software companies don't back their products because their customers don't expect them to. Instead they expect low prices.
Bill Gates is a billionare because he was one of the first people to realize that given a choice between a $200 program that works flawlessly and a $99 program that fails 5% of the time, most people (and businesses) will choose the cheaper product (while moaning how bad software is).
Note that this isn't the case in all software markets. Banking and T.V. are both industries which I've worked in, in which customers actually demand quality. If it's crap, they won't buy it no matter how cheap it is.
Funny enough, Microsoft is not in either business - and not for lack of trying.
Re:complexity (Score:3, Insightful)
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.
Re:software is incredibly complex... (Score:4, Insightful)
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!
Re:Beauty for beauty's sake makes crappy software (Score:2, Insightful)
I agree, and actually I would go so far as to say that bridges are not that different to software
Having studdied civil engineering before I moved into computer science, I found that the basic rules are the same, you design the bridge or whatever to the required specs, cutting costs wherever possoible. The only real difference is that most customers tollerate software bugs, whereas your average city full of people will not tolerate a bridge that falls down in the normal corse of business
Civil engineers put allot of effort into their designs becasue they have to, there are laws in place to make them do so. If these laws were not in place we would see many bridges falling down. These laws are just another requirement. If there were laws stating that software must contain less than so many bugs, then that would be another requirement and you would find that more effort was put into the design of the software to ensure this requirement was met.
So really, the comparison does not really prove anything except that software companies don't need to design their products as well as civil engineers do. Its not usualy a requirement.
Re:Not this stupid 'programming is art' BS again! (Score:2, Insightful)
(i.e.) I think a Porsche would be beautiful in my garage, but that doesn't mean a Porsche is a work of art.
I suppose if you were going to compare coding with art (literature), coding would be non-fiction. Some of it is horribly written, but it's got all the facts right. Some of it is written wrong and doesn't make any sense. While the truly good works of non-fiction, even though they are only telling you facts, are beautiful, fill your mind and heart with thoughts and feelings, and are 100% accurate at the same time.
In that sense, yes it is art, and like with a non-fiction book, you can copyright the finished product, but you can't copyright the facts that make it up.
Re:Not this stupid 'programming is art' BS again! (Score:1, Insightful)
I play piano/keyboards, compose music and write software. I am NOT an *ist. I am amazed at all the confusion surrounding this evil meme. If you remove the word from your vocabulary and remove the concept the concept from your thoughts, the problem goes away. You'll see things in a new light. Carriers of this meme act under compulsion to be included among those who know what * is.
Free yourself. * doesn't exist.
Re:Beauty for beauty's sake makes crappy software (Score:3, Insightful)
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.
Componentize and Relate (Score:2, Insightful)
Building a house, a bridge, construction in general, that's all physical stuff. Humans are created to be good at physical stuff. Nature has given those industries an advantage. Everything in software development is by-proxy, it's all metaphor - pure language: more like poetry than mixing concrete. Humans are very good at metaphors too, but the pure metaphors found in software development often tax our limited processing powers in ways unrelatable in physical construction.
Pile on top of that that, as was mentioned before, there are standards to these construction craft that have been refined over thousands of years. Software development has what, 50 years of science behind it?
Finally, in physical construction, there are powerful tools (steam shovels, cranes, concrete, steel) that come "canned" or "out-of-the-box" to which there are no real parallels in software development. There is off the shelf software that looks good, but it never "plugs n' plays" like we really want it to. There are development tools, (debuggers, profilers, editors), but they are primitive by physical process standards.
I suppose I could come up with a ludicrous example of software development, likening it to some sort of construction project where the site is in the wilderness, and I need to pave my own road to get my trucks to the site, and I have to smelt my own steel from my own mines once I get there, and then I have to make homemade concrete, and on and on
This is why I believe that component development is on so many people's minds, why Enterprise Java Beans are looking SO attractive. Biz people and developers want powerful "canned" tools that they can "assemble" to form complete programs. They want relatability too, they want software processes to be easily relatable to physical or business processes.
It's going to take more time; the tools and science will need to progress more. As CPU and memory become more bountiful, we'll waste more on frivolities that make the computer itself more relatable. This will, in time, help to reduce programming to more natural forms of human communication and interaction. The computer will eventually be able to learn about a problem space and "develop" solutions with a programmer's help.
My hope is that the democracy and ubiquity of natural language programming will elevate the potential quality of code produced to that of fine literature or other great works.
-- BeforeCoffee
On the contrary, bad design is often visible (Score:3, Insightful)
it's as good as they want to pay for it (Score:2, Insightful)
pay for. I'm building a house right now and the
contractors showed me the bottomline: cheap, fast
or durable: pick any two. People don't want good
or safe code. They want code to be cheap, sexy
looking and more importantly, they want it now. Or
yesterday. As businesses and individuals, we
should stop behaving like whores and selling
whatever the customer will pay for and be more
like my construction contractors.
Market maturity (Score:2, Insightful)
Computers have only recently become a mass market item. It's still a bit of a luxury item. When cars were at this point you couldn't count on their reliability or safety. It took decades of refinement, regulation, and standardization before they became the daily commuter that we rely on today. And still after a century you can't take even a bucket seat from one and put it into another, even from the same manufacturer, without adaptation.
The sad fact is, you're probably born at that time when you'll never see a mature computing market. For the most part we're still working from the direct decendents of the first IBM PC. Still working from the first UI to make computers usable for about everyone. We're still defining what a computer is!