Slashdot Mirror
Software Aesthetics
cconnell writes: "Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame. This article is a challenge to engineers, managers, executives and software users (which is everyone) to raise our standards about software. We should expect the same level of quality and performance in software we demand in physical construction. Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty." We had a good discussion on a related topic half a year ago.
My software is so ugly it's beautiful. I'm coding in Perl these days. :)
kind of like the innards of a biological organism.
Ever disected anything? It's MESSY.
-... ---
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.
-- Sometimes you have to turn the lights off in order to see.
The reason it's so bad is because it doesn't have to be good to get the job done. Most management is just about getting things done fast.
There is usually a tradeoff between quality and expediancy.
teknopurge
http://techienews.utropicmedia.com. help us beta.
Website Hosting
- Meet user requirements
Which doesn't necessarily mean it has nice and pretty code. If you have time, you are doing yourself a favor by designing it, but you can't lose track of the purpose of what you are doing, which is to get something working.Most techniques for designing or building software (e.g. patterns, processes) all serve to help you avoid bugs, which is to say more efficiently build software that meets user requirements.
http://www.naildrivin5.com/davec
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.
The middle mind speaks!
The bridge analogy you mention is frequently quoted. And I agree, standards in software design & implementation need to improve - particularly in the shrink-wrap world (I happen to think that in-house bespoke systems are generally better). But the standard response to your standard analogy is that any non-trivial application is hugely more complex than a bridge.
The design of a bridge is basically the extrapolation of a few well known engineering principles to the scale you want. It has 2 requirements : (1) It must reach from one side to the other and (2) it must not fall down. You may have noticed that software is not like that
I remember reading a quote from a famous software scientist (I forget who, maybe Turing?) who said (and I paraphrase here) that we shouldn't be teaching our your computer scientists maths, physics, engineering etc, but rather art and biology. Because programming is an art, it's the creation of something from your own imagination, not like engineering which is simply applying rules. And once created, any large application behaves far more like a living organism than a machine, it grows, it evolves and (often) it gets ill. I always liked that idea
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
When your code is on center stage you want it to look good.
I don't get paid to create beauty, especially not internal beauty. I need it to work, not look good.
The bottom line is, software isn't a bridge or a house, people don't trust their lives to my software. If I made software for the medical field or something like that, yes, I would have a different view. But the fact remains that you should only make it bullet-proof when you need to, because you never have time to make everything bullet-proof.
room101 -- how much can you stand before they break you?
(they always break you eventually)
Personally, I found Donald Knuth's Literate Programming as well as the Practice of Programming to be wonderful resources for writing better, more beautiful code.
This article is very interesting; the idea of code as an art form isn't new, but this article certainly is aggresive in encouraging it.
But what about "Extreme Programming" - doesn't it encourage the same thing, in terms of self-commenting code? Or does its specific nature essentially negate that aspect?
I'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.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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!)
"The world doesn't really need more busy people, maybe not even more intelligent people. It needs 'deep people'..."
Of course it also depends on your staff, if you don't have the expertise to begin with this process will either take a lot longer or may never happen if it is so poorly designed in the first place.
Check out the source to Darren Hiebert's ctags. Best-designed C program I've seen yet.
I can't tell you how many software packages I've looked at that are ABSOLUTELY HIDEOUS on the inside (and open source isn't exactly immune to that either. Anyone taken a look at the code of SSLeay? Good package thou).
The problem being, however, that once you have money entering the picture, and/or time, then the first thing to go is code quality. Mind you, combine that with the fact that a few years ago anyone who had the patience to sit down and read "How to program in java in 21 days" suddenly became a programmer. Here at work we have a very large codebase that we originally contracted out someone else to do, then took over once we got more funding. They preferred the "copy/paste" approach to doing loops, and tonnes of other hideous hideous things. I've done things like cut down 2500 lines of code to 1100. In fact, the company here could save money in the long run by hiring me to do nothing but optimize, by the cost of additional hardware that they would have had to buy to support this. ugh.
Unfortunately, in the land of "80% complete is good enough" and where "as long as it works" is a good philosophy, and in a land where "visual basic" is a professional programming language, we're not going to see this improve any time soon. Even Java works squarely against the goal of "efficient". Give me C++ any day.
I think that another part of the problem is people just not caring about their code, not having pride in what they accomplish. That and people simply not knowing what the hell they're doing. (Not that I know ANYONE like that around here... nope nobody...)
Argh. Ok sorry, I'll end my rant now.
If God gave us curiosity
Typically, the user interface to software is supposed to look good. This corresponds to the visible stuff in a house: the walls, floor, fixtures, etc.
But does the wiring look pretty? Or the plumbing? Or the unfinished basement/garage? Or any of the stuff that actually makes the house work?
Hell no.
Does the engine of a car look pretty? It's covered in grease and all kinds of crap is sticking every which way, and it doesn't make sense to the non-initiated. Function is more important than form when it comes to making the car go.
I'm getting tired of these calls for purty code. I like an elegant piece of software as much as the next guy, but my manager could give a crap as long as it works, and in fact won't be willing to give me extra weeks to make it look nice on the inside. Particularly when you consider that I'm probably the only person who's really ever going to look at my code.
Monkeytreats
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.
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...
Attempting to compare software engineering to building a bridge or constructing a house is flawed. The reason bridges are built to such exacting standards is because if they aren't, they FALL DOWN. They cease to function. 100% failure. Poorly built software, on the other hand, can still work well enough to be usuable. It may imperfect at some tasks, but perform adaquately at others. If it were true that anything less than a perfectly engineered piece of software would simply fail to compile, then we'd all be writing perfectly engineered software.
An additional flaw in the analogy is this: The function, or use, of a bridge is quite clear: Extend a roadway over an otherwise impassable divide, such as a river. Simple as that. But deciding what the function or use of a piece of software is much more difficult and complex. Software is told to do many things, and the things it's supposed to do changes over time.
I'm all in favor of well designed software. But his vision is more utopian than useful.
It's because managers seem to think that any computer related degree means you can design and write software. I'm not being mean here, but if you have a degree in maintaining networks or creating circuit boards, that does not mean you can design software.
I would hate to buy a cpu designed by a software engineer. But apparently buying software built by non-software engineers is ok.
I have found that very few software companys hire only CS majors for software jobs, you look on monster and it says, "Computer related degree required". That's bullshit people.
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.
--
$ chown -R us:us yourbase
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.
That is why we have advanced software engineering techniques like eXtreme Programming. Through it's constant refactoring it makes sure that code is always the best it can be for the task at hand, and constantly improving.
The only reason that so much code is ugly is that most people do not know about and adopt XP. XP closely resembles the reality of Open Source programming in its implement-now mentality and constant addition of features. If everyone used XP, the software world would be a better place!
Even Slashdot wants to hide some things
I think a problem here is getting to a common definition of art. If a master craftsman pours his soul into a work, how is that not art? Just because the emotions a work may convey cannot be easily categorized and labelled does not mean they are not valid feelings. There are many pieces of "craftsmanship" out there that evoke such feelings. I have felt them myself. Would you deny me that?
>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".
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
-- Andy
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.
Only 'flamers' flame!
Or open source, where you release your product when it is done, not according to an arbitrary schedule.
Every extra day that I take to plan, every minute I spend thinking about design, and every extra line of code I write to make my software more pleasing is another line that could add more functionality, another minute wasted not producing something tangible, and another day that I need to be paid.
That is an absolutely absurd statement. Every moment spent in planning, review, consideration of potential problems, creation of general-purpose solutions, and documentation of architecture pays for itself many times over later in the development, validation, release and maintenance cycles. Failure to undertake sensible planning activities early in a project leads to massive schedule delays from forced late-game rearchitectures that would have been headed off by early consideration, review and communication.
Software engineering is the only engineering discipline in which the practitioners are permitted to indulge themselves in work without planning or review, and that's the #1 reason that software sucks.
Tim
Long subroutines are run-on sentences discusses one aspect of this problem.
Building software and physical structures are two entirely different things:
1) The customer of a construction company is unlikely to decide that their cute split-level should now be a super mall after construction is underway. It isn't unusual to see the equivalent happen in software.
2) The "Mythical Man Month" presents a pretty good argument about fundamental complexity Vs. accidental complexity. It would be a good thing to think about.
3) Because everyone has a passing familiarity with the physical world things that aren't right get pointed out fairly quickly. In my experience is that about 20-30% of programmers can cut through the symptoms and treat the cause. Everybody else goes around plastering over cracks instead of realizing that the foundation is crumbling.
My two cents.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.
Anyway, here are the reasons why writing beautiful code at work doesn't happen:
Oh well, time to make more sausage.
It's half right to say we should engineer software like we engineer physical aspects of our lives such as bridges, houses, skyrises, etc.
However.. Bridges, Houses, Skyrises, all are slow moving, slow changed things. House "technology" doesn't suddenly double every 18 months. Otherwise we'd be like the Jetsons with houses into the sky, and talking dogs. Bridges are engineered to last for a very long time, because they do a simple, easy function. They provide land where there is none to travel on.
Software and Hardware however does. If you talk to a lot of software engineers, professors, etc. They'll all usually say not to worry about performance, next years computers will run it twice as fast anyway. This is very true at Microsoft. And its partially correct. Why bother spending a ton of time trying to make something work fast, when during the time you took to make it work fast, chips have doubled in speed?
However I do beleive we need to up the standards because of other issues, not longevity, but security, and functionality. Sloppy code leads to sloppy security. Just install a fresh copy of Windows, you pick a version. Unless you patch it, there are already a handful of security issues. Last time I installed OpenBSD, I don't remember going "I have to hurry up and patch this, and this, and this otherwise I'll get hacked." It's because the OpenBSD development crew beleives in coding properly. They don't audit for security, they audit for proper usage. And thats what we should be striving for. Engineering our software applications, and using the tools to do so, the correct way.
..There's a-dooin's a-transpirin'
1) If it works, not fix it.
2) Any landing you can walk away from is a good landing.
If you apply these two lessons to software design, you never have a problem.
Strange women lying in ponds distributing swords is no basis for a system of government.
I remember reading a quote from a famous software scientist (I forget who, maybe Turing?) who said (and I paraphrase here) that we shouldn't be teaching our your computer scientists maths, physics, engineering etc, but rather art and biology. Because programming is an art, it's the creation of something from your own imagination, not like engineering which is simply applying rules. And once created, any large application behaves far more like a living organism than a machine, it grows, it evolves and (often) it gets ill. I always liked that idea :-)
;)
Engineering just applying rules, yet programming is an art? Is this your editorializing or the original quote? Somebody needs a smack from a slide ruler.
+5:offtopic,but anti-American
To a Lisp hacker, XML is S-expressions in drag.
Very perceptive...coding software is like crafting a cabinet. However, designing a cabinet is art...and so is designing software.
Try expressing an emotion in C++. It cannot be done.
jesus->loves(you); // Sarcasm, for the humor impaired
Regardless, art doesn't just express emotion, it inspires emotion. And trust me, I've had (mostly other people's) C++ code inspire some pretty horrific emotions. ;-)
Good design and coding, on the other hand, can truly be things of beauty, regardless of language.
Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
Spoken like someone who just doesn't really comprehend software design, or why one design might be more elegant than another. I suppose you don't think mathematics is beautiful either...
186,282 mi/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
The cited article doesn't say anything profound. (I got particularly worried when he said, "global variables and GOTO statements ... may be exactly what the software needs to marry form with function," and when his example of beautiful software turned out to be a fragment of Visual Basic. "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." --said, tongue at most partly in cheek, by Edsger W. Dijkstra, in "How do we tell truths that might hurt?")
... and there are other programs about which we can say, 'wow, who wrote this!'" He suggests how you can recognize software with The Quality: "every part of the code is transparently clear -- there are no sections that are obscure to gain effciency; everything about it seems familiar; I can imagine changing it, adding some functionality; I am not afraid of it, I will remember it." There are even suggestions, not how to make more beautiful software, but how to learn to do so.
Richard P. Gabriel (whose essay on "Mob Programming" was recently discussed on Slashdot) has a far more profound take on the subject. He has a summary of Christopher Alexander's work on architecture and "The Quality Without A Name," and how it relates to software; you can read the PDF version on his Web site, or Google's cached text version.
Excerpts: "there are programs we can look at and about which we say, 'no way I'm maintaining that kluge'
Gabriel helped start the "patterns movement" in the object-oriented community. Aside from the Design Patterns book, patterns (and especially generative pattern languages) have yet to make a significant inpact on software development. Maybe someday, maybe not.
Stupid job ads, weird spam, occasional insight at
I sometimes suspect that "literate programming" is a gimmick to get around Stanford's policy that professors can own the rights to books they write, but software they write is considered a work for hire and the property of the university.
One can certainly succeed in meeting the user's initial basic requirements by writing a pile of spaghetti, but that doesn't make the writing of such sloppy code the preferred approach, at least in the general case.
Unless you're writing one-off programs for your customers (and how many of those end up being used over and over again?), the long-term maintainability of your code must be kept in mind at all times.
There's (usually) no guarantee that *you* are going to be the one maintaining the code in the future, at least many settings, and the people who will have to figure out how it works in order to maintain or enhance it will be extremely grateful if you lay your code out clearly.
So will your users, as they will have to wait a shorter amount of time before that bug is fixed or the new feature added.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
that's the beauty of open source programming -- and one of its downfalls. with open source, we CAN look at the internals of the software, judging the design to be a kludge (most likely) or something better. i say this can be a downfall, because with this comes the burden on a programmer who wants to open source some code -- making it 'pretty' enough to be released. We saw that with slash in the early years:
Us: 'Show us the code!'
Rob: 'It is too ugly and I do not want it seen yet.'
(I suppose to be fair Rob's misquote should read 'Its too ugly'. Yes, the spelling is meant to be a joke.)
The REAL sam_at_caveman_dot_org is user ID 13833.
If you want to follow your bridge analogy, then get out and take a look at a real bridge. Quite frankly, there's nothing very "beautiful" about it, except in an abstract sense, and even then, most likely from a distance. If you get right up close to it, you'll see rust spots, cracks, welds, patches, odd and seemingly arbitrary scars, and other features that look entirely out of place on a bridge... until you see an inspector's scaffolding hanging from the knobs you thought served no useful purpose.
In other words, by your standards, bridges are a friggin mess. Really... I mean, they have no "internal beauty", once you're close enough to see how they're put together.
Just like software.
The folks using the bridge don't care about it's internal beauty, except peripherally... they care that the hunk o' steel and concrete under them doesn't give way and dump them into a river. Similarly, the folks using software don't care about it's internal beauty, as long as it doesn't give way and dump their data into oblivion.
In fact, the only people who really manage to care at all about how bridges are put together are the people who build 'em. The same goes for software. There are plenty of reasons to write clear, easy to understand, well-documented code, without having to resort to some sort of appeal to a completely subjective quality like "beauty"; and there are plenty of ways to write high quality, reliable, high-performance software without making the same sort of subjective appeal. (Note that there is a difference, IMHO, between beautiful code and elegant code. I've seen some quite elegant hacks that had particularly butt-ugly implementations.)
I'll go as far as to argue that while there are exceptions, generally, good software does not come from pretty code. Think about it - when your code is "beautful", first and foremost, that means that eventually you'll sacrifice reliability or functionality rather than produce "ugly" code. I'd rather ahve my source code be ugly and correct than beautiful and full of bugs any day of the week.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
int main(void)
{
unsigned long *foo,i;
for (i=0;i<0xFFFFFFFFUL;++i)
for (;;)
{
*(++foo)=0;
}
}
Well, so much for those arguments. :)
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Build software poorly, and you not only lock a client into a system that's so bad no one else can replace you, but you get lots of billable hours trying to fix bugs and upgrade the software.
When lemon laws apply to software (and they should!), hiring people to write software who are actually competent will follow.
-jon
Remember Amalek.
Um, that's a total non-sequitor. The engineer in question could write "open source", but since the manager in question is asking them for a working software in 6 months, the engineer will apparently be funding the development in the meantime from his income from working at Wendy's. Now, if the engineer can find an open source package and convince the boss to allow that as a starting point...
I do not have a signature
The key is to format the code so it looks like an ASCII figure of a bug. The viewer, if he is hip, will appreciate the irony.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Part of the problem is the nature of programming languages.
A tool like C++ would never be tolerated in the world of bridge building. Too prone to invisible screwups.
Eiffel is an example of the sort of tool bridge builders might use. Eiffel will never succeed, though, because of the perverse nature of the programming tools market.
1) Programmers love the mental challenge of mastering systems of arcane, complex rules. It's a macho thing. They don't automatically reject monstrosities like C++, as bridge builders would, because to do so makes them sound wimpy. ("I don't know what you're talking about, it's not hard for *me*....")
2) Also, if programmers were to lose their careers over a single "crasher" bug, as bridge builders would, even they would reject C++ and go for something like an ubersafe Eiffel.
3) There's tremendous language inertia in programming languages (though not as much as in bridge building technologies.) There may be thousands of programming languages out there, but most are virtually off-limits for practical projects. That's why things like C++ grow so much tangled hair. It's easier to learn one more round of gotchas than to learn a whole new language, buy and master all new tools, and change jobs to a company using the new language.
If I created a really great new language, would it become popular? I'll take the 1 in a thousand risk of being wrong and state flatly "No."
As long as we're programming with the languages we use, we'll have the level of bugs we have.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I had one PHB try to freeze the project, bring his friend in, add features, and resume the project (rather than compensate us for the features). Please, make everyone understand what quality internals are, so that I may have an understanding when I demand the resources for such a thing.
It comes down to time and person-power. I think the biggest failing (from personal experience ;) )of most software/system design comes from either a lack of time or a lack of planning for time. The promise of "Technology" is here and now, but the bedrock is a sandy beach.
The other important consideration is person power. It's not necessarily a lack of intelligent and capable people, but rather poor management of their time (either by themselves or from project managers). For example, working long hours in "crunch time" or being forced into the 9-5 cycle. Unfortunatly, my brain does not work on the 9-5. Sometimes I'll work for hours on end in an outpouring of inspiration while other times I'll be staring blankly at an equally blank screen.
Another thing that corrupts software is the idea of "catch-all" systems. That is, does your web-browser _really_ need an IRC client? or, for that matter, an e-mail client? I think it would be helpful to break software down into individual, streamlined components that does one job - and does it really well, instead of doing a lot of jobs poorly.
Just my 2 cents.
Price, Quality, Time. Pick none. What, you thought you had a choice?
...Isreal and palestine should lay down their arms and live in peace; the oil companies should all band together to clean up the environment; all the children in the Third World should be fed; science should invent a cure for AIDS; and Palm should open-source BeOS.
In the meantime, the author of this article ought to turn his attention to explaining to managers *why* they should care about beautiful software design. Until management gives us the time and budget to do otherwise, we engineers are just going to keep on writing code as well as we can within the contraints we're given. It's not like we *enjoy* writing crappy software.
--
CPAN rules. - Guido van Rossum
DISCLAIMER: this is not a cheap shot at interns: it is a shot at managers failing to properly groom young hackers into veteran hackers with the humility to focus on the what's best for the project, rather than deft coding tricks.
i've seen dozens of interns and new hires come in with 1 or 2 semesters of C, and write lots of code, sometimes important pieces of code. management seems to think that if you throw enough newbies at a problem, it's the same as one or two really good programmers. this is a huge management oversight. interns and new hires need good solid mentors and time to develop and hone their skills, and project management needs to enforce design rules. unfortunately, newbies are very reluctant to code to design rules, I know because I always wanted to do stuff my way as an intern (eight years later I'm writing design rules... irony). the result is like a meatgrinder on full speed: code spewing everywhere that all looks different, and is not being tested, regressed or reviewed.
I've seen projects with strict design rules and rule checkers plus a technical guru/godfather for the project owner: results, fewer bugs and fewer people needed to support the code, and i'm talking about million line simulators.
solution: mentoring by veterans with large program experience (the really mean veterans, they are the best people to surround yourself with); and a strict adherence to design rules and revision control; and regression/coverage testing!
https://www.accountkiller.com/removal-requested
-db
1) Materials science changes only slowly, in small increments.
2) The working principles of structural engineering scarcely change at all.
3) The practices and processes by which bridges and houses are built evolve only slowly, and incrementally, over decades.
4) The fundamental purposes for which houses and bridges are built never really change.
Contrast that with the practice software engineering where everything, beit language, paradigms, principles, practice, materials and even purpose change radically within very short timeframes. Programmers are expected to track all these changes, and what's more, they have to deliver quickly and efficiently.
In conclusion, I would assert that if architects and structural engineers were obliged to work in the conditions and culture in which programmers do, they would not succeed in building anything at all.
Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame.
You've apparently never seen how a house is built. While the exterior finish looks very nice to the final occupants, the construction process and actual "code" (if you will) of a new home is quite sloppy; easily the equal to typical ugly code.
Tract housing, in particular, are built as quickly and cheaply as possible. Wires are run rapidly, without much care to particular placement. Builders leave lunch trash inside wall interiors. Finishes are half-baked, details are of little concern. The materials used are the cheapest possible.
Just like a program, what the buyer sees is the outside finish, and that's basis for their purchase decision normally. But look at how they are actually built, and you'd be afraid.
People cut corners if they think they get away with it, be it bridges, houses, or programs.
ShoutingMan.com
Beauty is in the eye of the C-coder.
this is what academics do... they sit in ivory towers and look down on the messiness of the real world and lecture us about how messy it is.
;-P
;-P
;-)
"those who can't do, teach"
you read this topic, "software aesthetics", and you begin to understand why this saying is so apt.
i'm sorry, but scenic pastoral allegories about bridges and houses makes me want to choke. has the author ever actually worked in the business world? you don't have 3 months to look at a business problem like it were a chess position or a game of go and wax and wane philosphical about "internal beauty". you have 3 days to give it a heartbeat and stick it in front of an end user and then wrench it's guts around 5 different ways while the end users completely mess around with the spec.
if i do this, and some guy is going to criticize the loss of mathematical symmetry in my choice of algorithms to solve a particular problem i'm going to punch him. oh my gosh! i could have written the entire app stateless rather than stateful? i could dimensioned this array to use 10% less memory? these variables are redundant? WHO CARES!
so go compose hiaku about the beauty of software or write code IN haiku, or whatever floats your boat about the serene inner symmetries about math and logic, and leave the real work to the real people in the trenches.
sorry folks, but this is total bullshit! (i know, i'm not talking about systems that help my mother's surgeon operate on her heart, or trade my stocks, or send the next space probe mars-wards, but this criticism of inaesthetic code, applied to the 95% of programming that is not so death-defying, is inappropriate)
look, as long as hard drives grow in capacity like weeds and moore's law on processor speeds holds true, software bloat is the only game in town. maybe in the days of the 6502 and 4k of memory, writing clear, concise, elegant code was not only kewl but necessary. but nowadays allocating 20k of memory for an object that, as used in code, is the logical equivalent of a boolean, is, well, a moot point!
so let the greybeards look down on us and scowl at our waste... we can waste! it's OK. you are still an "alpha geek" or whatever you feel you have lost by not revealing the beauty of prime numbers in your code for the shipping company's bike messenger route tracker. oh dear!
in fact, i'd rather see a discussion on the modern trend of "skinning" apps, or at least the gui in general... that is where developers REALLY have to pay attention (boy have i seen some doozies). the gui is where smart coding really does make a difference and where most programmers really do drop the ball awfully. the gui is where a discussion like this really can make a difference, i think.
note: if you want to flame me and you don't work in the business world, please temper the thought with some empathy for us dilbert-esque programmers who report to dilbert-esque bosses. (that's the REAL source of my passion on this topic.) thanks
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
The software equivalent of a bridge is a slide rule. It's static, single function, well understood and reliable.
Maybe if evey god damn software project weren't the engineering equvalent of a fucking concept car (along with all the robustness that they have) the software would work like a charm every time you hit a key.
Until then, fat chance. It's still better to have a 90% solution today than a perfect one after you're out of business.
The author compares writing programs to building a house - adding on unneeded features, he says, is "horrible design". However, one of the most important issues with code that is of less importance in construction is scalability. You don't expect your house to hold the proper framework for an eventual skyscraper. This is routinely expected of computer programs; software that does the job will live and grow until it ceases to perform. Thus his argument for minimality based on home design is somewhat inappropriate.
Gee that's a very tough problem. I'm sure I could say something meaningful about but I can't cover it in the allotted time or using the money you're paying me to do it.
Why does quality suck? Why does performance suck? What kind of quality are you talking about? Functional, aethetic (I guess you mean elegant though), fixable, manageable? Those are all different axes of quality that represent different things, having different values and are achieved through different means and methods. The reasons they fail are myriad:
1 Management doesn't have a clue
2 Programmers don't have the skill
3 No one cares if it's shit
4 The customer is insane
5 The customer is cheap
6 There are too many changes
7 There is no difference between success and failure
8 The technology is crap
9 Poor program/project management
10 Cult of the hero
11 A preference for predictable mediocrity over accidental brilliance
12 The arrogance to believe that what you do is art but what everyone else does is 'engineering'
13 No accountability for problems
14 No time for design
15 Thinking a packaged solution can be installed as-is
16 Inability to create useful requirements
17 Scope creep
18 No test plans
19 No QA
20 Poor cost and time estimates
Those are just the ones I saw today.
How do YOU know it's good code? Your opinion means nothing to me. You are probably misintreperting something you do not understand. In fact, your post is a perfect example of the bullshit I was talking about in the original post.
A good CS major does not just sit there and code to the specs a suit type hands them, they learn the industry so that they can write better code. Now perhaps you have dealt with shitty CS majors, but talk to any CS professor and they will tell you that nobody should be developing applications without proper training.
And proper training is not joe blow who once wrote a program to keep track of his baseball cards then majored in biology.
The software industry is known for many accomplishments, but is known just as stereotypically for a lot of crap and disregard for quality.
On the other end of the spectrum seem to be anyone involved with games and 3D graphics, be they programmers or artists (with the exception of recent MMORPGs). Games and 3D graphics have made HUGE strides in quality and have not slowed down one bit. They are the things pushing computers to their limits and using every ounce of computing power to its full capability. How is it that these two related industries continually meet standards so high and continue advancement at such a pace? I think the answer lies in portfolios and the reconition of quality.
In most software, you are using it because you have to. Standards are needed and many times what you have to use is not the best option, but you are locked in place. Windows.
In the world of games you don't get hired with a CS degree, you get hired with a demo or a portfolio of demos. In 3D production there are no official degrees. No standardized education must mean no one is educated then huh? Fuck no. You get into a company with a portfolio. You show what you can do, and if its good enough, you're in.
Reconition of quality is another big factor. The crap sinks and people don't buy it. They want games that are fun and software that works. 3D software is what made me want to program in the first place. The elegance, speed, ease of use, complexity, organization, and balanced nature still blows me away. Programs that suck get ingnored. Programs that rock are hot property. Studios are starting to use Linux in a big way. Why? Because its better. They reconize quality, that's what they buy and that's what they hire.
I can't really get hired as a programmer. I don't have a degree. I know 9 languages and know a good amount about structure, organization, and design. I have written some intelligent programs, but it doesn't matter. Stop using personel directors, recruiters, and middle management to hire programmers. Programmers should be hired by other programmers. Not their job? Make it part of their job, give them help and don't tie them up with stuff they don't have to do, but when it comes to reviewing and interviewing applicants, it should be the senior programmers doing it. They should be looking at code and have some kind of portfolio in their hands, not sorting out the people who don't have degrees, because that is just one way for people to learn.
None of this guarantees that crap still won't make it out the door, because the money and time restraints are still there. But at least this way it will be weighing down on skilled people and not the 'I want money, I think I'll program' type people who don't know what the fuck they are doing.
This Wiki Feeds You TV and Anime - vidwiki.org
I know, I'm gonna get flamed till I'm golden brown for suggesting this, but think about it for a moment.
Most every other device, object or institution that interacts with the general public has a set of rules, guidelines or industry accepted practices that are enforced.
Any device that emits RF energy must conform to the appropiate licencing requirments in the country it is operated in.
Any device that uses electricity must obtain the appropiate certifications before it can be readily sold (UL or CSA for US/Canada).
Motor vehicals of all shapes sizes and types have to go through a whole battery of tests and certifications before they are allowed on our public roads.
Now look at software. Badly designed software has the ability to do harm (MS Lookout trojans anyone?) So why shouldn't software be subjected to some sort of public examination? I'd be in favor of "crash tests" of software packages by some independant body like we do with vehicals. There is no legislative requirment that I know of that manufacters make 'safe' cars beyond the basics of seatbelts and such, but as a consumer, I look at the crash test results and I'm more likely to buy a car that has a good crash test report then one with an exploding gas tank!
As software becomes are more and more intergal part of our day to day life, I think something like the FCC's rules for software might be required for network connected software: This software must not emit any harmful data into the Internet, but must accept any and all harmful data from the internet. Ie: No more buffer overflows.
Ideally none of this should be required. Unfortunatly no software is an island anymore. Everything interacts, and unless we have some basic rules of the road, chaos will inevitably ensue.
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
Two, software that is not conceptually clean is hard to extend. People often talk about maintainability, but it rarely gets priority during implementation. Why did Netscape's browser finally lose? Not because they didn't have good ideas for new features, but because it was internally such a mess that they couldn't improve it fast enough. This is not uncommon.
So, even when we feel the very necessary pressure to get our code out the door, we need to push back in order to give more attention to beauty. We will benefit.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it. If it were a house, we would be afraid to enter. The only reason we (software engineers) get away with this scam is the general public cannot see inside of software systems. If software design were as visible as a bridge or house, we would be hiding our heads in shame.
I'm sorry, Michael, but I must disagree. This weekend I had two wonderful counterexamples.
We had our house built, in fine detail. That included making decisions about such seeming trivia as the knobs on the closet doors. It was a pain in the ass. But we got a helluva well-built house out of it.
One part of this detailed process was selecting a builder. We knew from wandering thru unfinished houses that there were some real corner-cutters out there. It wasn't that their houses didn't meet code or fell down, but there's the letter of the rule, the spirit of the rule, and (best) is the urge to do it right. Our builder did it right.
But he's the exception, not the rule. Open up the drywall on any house (or better yet, try to install some paneling) and you'll be surprised how much your house is out of true. We all get it, we all live with it.
Even as well-done as ours is, tho, there are still some things that are hard to do. Like the pain we had this weekend running 10-baseT cable and coax to my teenagers rooms. Too damned many solid things in the way. Yeah, we didn't think of it in advance -- and twenty years ago, who did? Is this a design flaw? Nope, even the best of houses has errors.
The other example from this weekend is building a computer for my sister. She doesn't need much; an older system will do the trick. So I went down into the Eschasi's Basement of Dead Computers and started scrounging stuff together.
You know what? The mechanical design on most legacy PCs is light years ahead of their more `advanced' cousins, the workstation. My SS-10 is much harder to work on than the average PC. And let's not think about some of the other old systems out there...DECStation 3100, anyone?
Why are PCs relatively good? Because they're designed to be cheap to assemble, and because economies of scale have helped made components standardized. So you get simple parts that plug together simply. For a counter-example, look at any automobile. It doesn't use standard components, so parts are custom-designed for ease of assembly.
A modern PC, in spite of idiocy like the BIOS and DOS's legacy, is a thing of technical beauty. And so is some of the software we write.
What distinguishes the good from the bad is (as so many have pointed out here) is (a) what you have to work with, and (b) what you're incented to do. With good tools and good standards and an environment where the software lifecycle is understood, good code is written. I do it damned near every day.
This is NOT a troll. Seriously, isn't this question basically asking, "shouldn't we make software that works well and is relatively easy for another programmer to take over?" The point about "beauty" is somewhat relevant, in that well-constructed code has an elegance to it that other programmers can appreciate -- in the same way the Golden Gate does for civil engineers. But then you just get down to the same old ridiculous discussion about "what is beauty?", which is nightmare anywhere but DEFINITELY shouldn't be touched on Slashdot. ;-D Anyway, seems like a very silly question.
My thought is that quality won't improve until software makers and authors are held responsible in the same way any other manufacturer is for defective products. If Ford, say, tried to say they weren't responsible for defective products beyond paying for a replacement car, any judge around would smack them for contempt of court for ignoring precedent before letting the jury take them to the cleaners ( see the Pinto case ). Until the same thing happens to software companies, we won't see any change.
IMHO striking all those EULA provisions as illegal and enforcing consumer-protection rules for software would be a Good Thing.
There's a tendency in people who Think Big, or maybe Beautiful, to make software that is more general than it needs to be. This monolithic design process -- where you Conceive The Program in one fell swoop, then Implement The Design -- that usually ends up ugly and not very useful.
But when you appreciate that beauty is the balance between small and general, then you make things that are really useful.
First off, I completely agree with the article, and am one of the biggest proponents of "beautiful software" I know, but...
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.
Kurdt
I'm not anti-social. Just pro-technology.
You're paid to make it work, make it keep on working, and do so in an efficient manner.
That is WHY you must "make it beautiful". To do otherwise takes longer and costs more. A LOT more.
One of the problems with this debate is the use of the vocabularity of aesthetics. That software with certain characteristics is also "beautiful" is a side-issue. The characteristics that make it "beautiful" are also those that make it:
fast to write
low in errors
easy to debug
easy to modify, augment, and improve.
Being "beautiful" is pleasant for the programmers (which also improves productivity somewhat). But issues of "beauty" and "style" - AS beauty and style - are a red herring.
And these characteristics that are usually only describable in these terms make an ENORMOUS differece.
For instance: I habitually use these principles in my coding, and debug as I go. My work was once characterized as "... takes three times as long as anyone else, but it usually works."
Bullshit.
The techniques made my work so blazingly fast that I was able to deliver a complete, debugged, essentially error-free component in about three times what it took the other programmers to get to their first clean compile, or to do a debugging iteration. And by "essentially error-free" I mean that in over two years of work at one site, with thousands of lines of code, I had one error detected by someone else, in a preliminary internal release, before I had corrected it.
But the result was that my time-to-completion was measured against everybody else's time-to-do-a-debugging-iteration. And the administration discounted my advice in favor of that of the "most productive" - read least careful - member of the team. And the bulk of the project iterated until the sponsor turned off the money.
So this esperience was an example of how using the vocabulary of art to describe practical issues of programming methodology is actively counter-productive.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
on the issue of software elegance. There is a middle ground on this issue, where code beauty/maintainability/simplicity can be weighed against expediency/commerce/requirements-meeting and a healthy outcome emerges. Of course, this almost always involves a political fracas with both Crap Coders who don't give a sh*t about the quality of their work as well as the Elegance Nazi's who won't accept anything that's not absolutely perfect.
The best programmers, IMHO, are the ones who have the experience and social skills to influence both sides to "cut the crap" and get on with creating reasonably elegant and high-quality software in a reasonably fast manner.
Steve Magruder, Metro Foodist
Even Java works squarely against the goal of "efficient". Give me C++ any day.
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?
So, by all means, be guided by aesthetics. But don't expect that everybody will agree with your sense of beauty.
> And I agree, standards in software design & implementation need to improve - particularly in the shrink-wrap world
I own an automobile. There was a minor flaw in the design and/or implementation, namely the "low battery" light for that model did not always come on when it should.
For this, they recalled my car and fixed it at their own expense.
What happens when COTS software ships with a bug of that nature?
The world is full of crappy software because people put up with it.
Sheesh, evil *and* a jerk. -- Jade
Software engineering can be taught, but IMHO the real prerequisits are a careful and analytic method of thought, along with the ability to absorb technical details like a dry sponge tossed in water, and the perserverance to tackle tasks that seem impossible. Any technical major in college will be sufficient to aquire these traits, because there are things of intellectual complexity to rival the worst of CS in many other fields (for example, IMHO the analysis of algorithms pales in comparison to quantum mechanics or group theory; and if you think Biology is simple I invite you to examine the Kreb's cycle or Citric Acid cycle at some point. ). The rest, quite honestly, you can aquire by going to a bookstore and buying books to fill in the theoretic gaps in your knowledge. And you don't really know anything until your first job.
So saying that only majoring in CS gives you the ability to produce good software and judge the merits of software, is more than slightly myopic.
Insight into solving problems with electrons flowing through silicon is by no means dependent on what formal educational background you have.
Remember, Turing and Djikstra weren't computer scientists in the formal sense of the word (respectively their formal backgrounds were/are in mathematics and theoretical physics).
Of course, coming into the art of software engineering from computational chemistry may have prejudiced me to some degree.
News for Geeks in Austin, TX
Perhaps that's why big designers have people whose single task is to do ui (user interface) and why good ui designers get paid so well.
[Something witty and intelligent should have appeared here.]
{Traicovn}
Not only is the UI supposed to look good, but the software is supposed to function well. It is very dificult to draw an analogy between physical objects and ethereal ones (such as cconnell and the bridge or you and the house/car). How do you correlate a really nasty bit of code that is completely unreadable but executes fast-as-hell? A turbo maybe?
Sure I want my house's walls to look pretty, but I also want the behind the walls stuff to be well thought out and implemented. If the waste from the toilet has to travel up the wall, over the BR ceiling and then down to the sewer, I am going to be displeased with the results.
By the same respects, if your car's engine is "covered in grease" it takes about 5 minutes with a degreasing spray to clean it up. So there are "all kinds of crap is sticking every which way" and "it doesn't make sense to the non-initiated". I am certainly not going to make much sense of even a well writen C program. But my programmer friend will (if the code is well writen, and he knows the language). Just the same way that my mechanic can make sense of the engine (if the engine is standard, and he is familiar with the tech i.e. fuel injection, diesel, etc).
Just because the back end of a program is hidden from view, and/or would make little sense to the masses, does not justify discarding sensible software aesthetics. Just ask the Saab mechanic that has to pull the engine to replace the oil pan gasket. He'll tell you that function is not more important than form.
Yeah, there is some truth in that, but...
Most software written is written for the first time. Writing a new piece of software is not like building another house. It's like building the first house, or the first bridge, or the first power station. If one were already build, we'd use that. But there isn't, so we have to invent it as we go.
And no matter how many houses or bridges you've built, it's really unlikely you'll build your first power plant correctly the first time around. There's stuff you just can't know about power plants until you actually get around to building one and see where your plans were wrong.
Yeah - I can write a function (or object, or whatever) to do foo with my eyes closed. Just as a good engineer can build a wall or a tower. But until you put all your walls and towers together for this damn thing, it's really easy to miss the support beam you _really_ need to hold _that_ piece of roof up, even if all the rest of the roof, and all the walls, floors and plumbing work. And because it's _way_ too expensive in terms of time and money to pull the whole thing down and do it again from scratch, you jury-rig it. You have to.
Of course it doesn't help that your schedules are normally set by someone else, who insists that you have to get this new piece of software out the door before anyone else, because getting to market first with a buggy product is more important (in their eyes) than getting it right. There's always time to get it right later they say, but if we miss getting to market first, someone else will have the mindshare and won't bother buying our product, even if it is better, if they've already got this other guy's product that _almost_ does the job and they've been promised a cheap upgrade and bugfix within the year.
And seeing as they're the guys with the money, if you won't do it their way, they'll quite happily find someone who will.
So you write and design this piece of software as you go, doing your damn best to make it Right given the (impossible) constraints given, but having to jury-rig as you go at times, telling yourself you'll get it right for version 2, having learned what you have. Meanwhile, your non-technical superiours look at you strange when you say that the internals are 'ugly' and that you really need to tear it all down and start again (which is what research - which is what you're doing, let's face it - is all about), and insist that version 2 will do fine being an extension of what's already there.
_That's_ why it's ugly and doesn't work.
Why doesn't the gene pool have a life guard?
There are a lot of similarities, but there are some important differences.
Different people usually build the house than design it. The design by an architect can be done at a more sane pace, but once the building starts, it becomes very expensive to have delays or slow downs. In software, there's usually pressure from day one. Also, with a house as with software, you can have a great designer and a lousy builder/coder and end up with a less than optimal result. Or vice versa, though a really good builder/coder can sometimes save a bad design.
One significant difference is that houses have some standards they have to follow, the Uniform Building Code plus local building codes (such as for earthquake safety). Houses also have periodic inspections during building (framing, electrical, plumbing, etc.) to make sure those standards are followed. Sure, the inspections aren't ultra-detailed, but they do keep the builder somewhat honest.
Beautiful code usually has periodic inspections, too -- starting with reviewing the design. But too often such reviews are sacrificed in the name of the schedule. There was an interesting discussion about code reviews on /. a while back.
Another significant difference is that in building a house, it's agreed up front what the design is going to be. If there are changes, people know it costs time and money. If standard sizes for doors, windows, etc., are used, it's cheaper and faster than doing custom sizes. Those lessons don't seem to be universally understood in the software world, though.
Finally, the author notes that it isn't a perfect metaphore. But regarding his statement that:
There is a parallel: a good house requires a well-drawn design, and communication (written and spoken) between the architect and the builder. A good design includes a document with the things that standard architectual drawings doesn't include spelled out: what materials to use if they aren't standard, what colors, any thing to watch out for, etc. This is very similar to the need for clear, readable code.
All in all, an interesting article, with some good thoughts. Even if the metaphor isn't perfect.
There are 5 kinds of causes of bridge failures:
- Bad specification
- Bad design
- Bad construction
- Bad maintenance
- Accident or sabotage
As you point out, bridges do FALL DOWN. Here is a list of major bridge collapses, including this one which I actually witnessed fall. And the expense of one crash tracked to an error in design can be enormous. This is area where quality is design is important, and usually is done. And given that the cost of the design work is small compared to the cost of materials, construction, and loss in the event of a crash, there is relatively little pressure to reduce costs by cutting back on the design diligence. That doesn't rule out trying to design for lower costs elsewhere, but still, that is rare due to the extreme costs of crash.Software doesn't usually have the extreme costs of a crash. Some exceptions do exist, like airplane navigation and medical instruments (and cases of bad software there is a concern, too), but in general, the cost of a crash is low compared to the cost of design, which is often very high. That means that cost cutting measures tend to focus on the design because that's where the costs are high, even though it's only that way because the other costs are low. So pointy haired managers will do their thing and we get software that sucks to some degree.
If software did have the same cost ratios of a bridge, you can be sure the design quality would not be skimped on, and better software would result. In the sense of "if the economic model could be applied" the analogy fits. But of course reality is that the economic model is not the same at all. So I see where he is coming from with his analogy, and it makes sense, but we can't use it to solve the problem of why software sucks so much.
now we need to go OSS in diesel cars
The last house my parents bought was new. It came with bugs [defects].
:)
Flipping certain light switches would result in an exception being thrown [circuit breaker being chipped].
There were some graphical glitches in the house rendering [missed paint in a few areas].
One of the bedrooms had a half-assed bug fix [garage roof went through one of the windows; they fixed the problem by cutting the window size in half].
I could go on, but you get the point.
When I helped a friend refinish a basement, we did make sure that all the extra things like wiring and such were done well. The framing was all well put together with good lumber, the wiring all very efficient and well planned. The junction boxes were all open and easy to work with, room for expansion.
Personally, I would be upset if I opened up my walls and found a badly done job (in fact that's often true of my current house as the builders were rather careless in spots).
If the engine of the car is covered in grease then it's not working as well as it could, you're just asking for a breakdown. A well-designed engine is very pretty - have you ever been to a new car show?
As for your manager not "giving" you an extra week to make it pretty - that's right, they'll never give it to you. You have to take it. Slowly over time they'll realize the benefit and give you more leeway - if not you can move on and try again. At least in the meantime you were able to work on something you were proud of instead of being the equivilent of a McDonalds worker, just punching a clock.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
It is a popular saying that success has many parents, but failure is an orphan. This is true as a parable, but not in fact. Failure, in fact, has many parents.
One of them is economic. Quite apart from catastrophic civil engineering failures that result in injury, death, and vast property loss, there are innumerable engineering failures that merely have a steep price. When Ford designs an automobile and do not discover until production that the bolt holes on the block do not match up with the bolt holes on the transaxle, millions of dollars have already been spent tooling up the incorrect production lines. Millions more will have to be spent to correct the problem, not to mention the amount of inventory built prior to discovering the mistake. Since such errors are so costly, there is a strong economic incentive to avoid them. This is a cost far smaller than the collapse of the pedestrian bridge in the Vegas Hyatt, or than the collapse of the Tacoma-Narrows bridge, but it is a cost that can feel that heavy when the production engineering team has to explain things to the board of directors.
While failure in software can indeed have high costs, it is realy on the level of cost even of the automotive example I use above. The plain truth is that there are bugs that it is simply not worth it to catch before the software ships.
The virtual nature of software makes this an inescapable fact. If you want to see our economy screech to halt, require zero software defects.
Consider as a comparison those places where software failure is roughly equal in consequence to mechanical failure, such as in implanted medical devices, or in launching manned spacecraft, or even in our (USA) overtaxed Air Traffic Control system. In these places, change control is every bit as rigorous as in the design process of civil engineering projects.
Most software is bad because, frankly, most of it doesn't have to be that good and it would cost too much to make it that good. This is not to say that excellence should not be sought, nor to say that developers should not constantly be seeking new ways to improve software design and development, but, believe it or not, we actually do know how to make software with zero defects. Most developers and businesses are not willing to work within the controls that ensure this, or pay the price in slower development and longer time-to-market.
In the long run, I think Free Software is the way to improve the quality of those applications (such as Operating Systems) that must indeed approach zero defects, since barring extremely rigid development methodologies that center around exhaustive code coverage and expected outcomes testing (test, design, code methods) coupled with a rigid system of change control and code review, we will never see zero defects.
As a counter-example I would offer anecdotes from my own experience. One would be the dramatic improvements is error rates and development time I have seen by merely switching from a very fine, but bug prone language (C++) to Java. This is not the only reason to choose a language, but it is s good one. I am just finishing the development of a production floor control system in Java that took a team of six a mere six months to build with a near zero defect rate that would have (in my estimation, admittedly) taken 2 years in C++ and would likely have a number of latent pointer/reference errors that are difficult to discover and even more difficult to locate.
So appropriate technology may be a more important predictor than methodology.
Well, I'm really running on at length, but in my career I have seen the exhortation "we must do better" again and again, and very little changes because quality is expensive, and few people, if any, want to pay the price of quality software.
Again, I say Free Software is your best bet, since you get much greater manpower on the code for "free" than anyone could afford to pay for...
For a particularly good book describing the problem and situation (fabulous for understanding the flaws in most businesses software design methodology, and more importantly for convincing managers that this is the case) then you should read The Inmates are Running the Asylum by Alan Cooper, the 'Father of Visual Basic' and also author of About Face: The Essentials of User Interface Design .
It's light on concrete solutions (although the foreward addresses why that is the case) but still a useful primer to read even if you want to solve the problem, since the first step to solving a problem is properly understanding it. It's so fabulously refreshing to see in print a rather respected person describing the problem as I know it to be true, and especially providing big-business, big-name, concrete examples to point to and say, "SEE! IT REALLY DOESN'T WORK TO SET ARBITRARY DEADLINES AND TO START CODING WITHOUT PROPER SPECS!".
This issue is just a little bit important to me :)
Just this past weekend...
My SO and I were out pricing houses - something we have been doing lately on the weekend as we save (and scrimp and more) for the down payment to get our mortgage - fun, fun, FUN!
Anyhow, we went to this one open house that was really funny. Looking around, and asking the seller, they wanted $205,000 (US) for it (way out of our price range, but we decided to continue to look around, for politeness sake). We went upstairs, and started looking around - one area that was funny was a closet we opened - and behind the sliding door was wall!
It turns out that when the builder built the house, this room and the adjacent room had "side-by-side" closets - well, the second room had a larger closet than the one we were in, but the doors were the same size, so it was a really botched job.
We left wondering what other "funkiness" was in that house...
Reminds me of code I have seen...
Reason is the Path to God - Anon
I just started a job recently where the previous developer of software that I'm modifying did NOT use warn or strict!!! How the hell do people justify that? I just don't get it... Not only do these tools speed debugging, they make your programs less succeptible to bugs.
;-p
If anyone reading this does NOT use warn (invoked by putting a '-w' after your perl interpreter call, ie: #!/usr/bin/perl -w ), or strict (invoked by putting this after your perl interpreter call or package definition:
use strict;
then please do!
You'll have to make sure your variables are scoped correctly (ie: my $scaler = 'whatever';), which may seem like a bitch but is HELPFUL!
hehe, ok, enough of this. Hope you all are having a fun day.
-japh
p.s. I don't have a tv either, I recommend this if you don't like being brainwashed/desensitized,
I wouldn't want to go back to the days of assembly-language, but you're right about it weeding out the incompetent. People who weren't with it just couldn't write assembler at all; but they often can churn out semi-working C/C++ code.
Let me second this: most housing construction I have seen (in particular in the US) is pretty shoddy. However, as with software, if you build your house yourself using non-mass-production techniques, you know what goes into it, and you will end up with something that's more livable, more suited to your needs, more efficient, and often cheaper as well.
But Perl poetry has a long history.
Never play leapfrog with a unicorn. Or a juggernaut.
First.. the analogy to bridges... it doesn't hold up.
Ugly code != unsafe bridge.
Code that's not expandable and cleanly written is not necessarily bad, if it gets the intended job done.
Now, I'm not saying there is no place for proper software engineering, and well-written code is always better than sloppy code... but let's remember.
Not everyone has the time or effort to do really serious software engineering. If I buy an app, I expect it to do what it says it will do, no more, no less. If the underlying code is crappy, I don't care, so long as it doesn't affect my work.
Building good software (in the mid to large-system sense) is simply a matter of good teamwork, nothing more. Good teamwork means that the team comes up with coding standards that everyone practices. Good teamwork means that management from the top to the most junior program, have a way to communicate what the company needs and when it needs to be done. Good teamwork means that the team, from management down to the most junior programmer, agree on a system for developing requirements down to designing and implementing the software.
While it's been a long road (longer than expected because of a lack of resources and a little too much confidence), we have come up with what everyone on our team believes will be a revolutionary product. Time will tell, but our customers and potential partners are mightily impressed.
The team was fairly small. It started with two developers working together as architects and me as team manager. The team is now 5 developers (me being one of them) and me still managing and architecting. I'm not bragging. I learned from better programmers and better managers and did my best to provide what I thought I could provide. Through some luck and good teamwork, we've managed to provide what I promised and a whole lot more.
The code is designed well enough that a recent hire (two weeks old) has already added significant functionality, yet the system consists of more than 40 individual components.
Anyway, I owe it all to teamwork. I couldn't have done this alone certainly. I made a number of mistakes as a manager, and even as an architect, but I think that comes with breaking new ground. In the end, the overall design was solid enough that we've been able to survive changing and new requirements and still have a very stable and well designed system.
Okay, looks like a long brag, I guess. Sorry.
My personal experience is that extreme programming (XP) produces code that is exceptionally good quality at a low level but not so great at an overall architectural level.
:)
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
Say what you will about poor software quality, and I'm sure that there are various things that could be done to improve it, but the real problem is with the users. Most consumers are more interested in having software that mostly works today rather than software that works perfectly a year from now. This is how the markets work and managers know this, and they supply the market with inferior software in the shortest time possible.
In theory, the software can be fixed in the second version if it turns out to be popular enough, but in practice, the same process happens over and over with each release. Screw it, ship it!
In order to change this trend, consumers will actually have to hold out for high-quality software, rather than low-quality software available earlier.
There are no insights in this article. Mr. Connell is just reiterating the sentiments we have all felt (or even expressed) at one time or another.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
This is typical XP evangelism, and as usual, it's supported by precious few facts.
XP has its good points, certainly. However, it's not nearly as clever as it thinks it is. "Test first!" they claim. Where do these tests come from? The requirements, of course. What do they do? They lead you to implement code that systematically meets the requirements. S'funny, I coulda sworn that was what this "design" thingy was all about.
And no, the fact that they UseIrritatingStyle for their LongWindedNamesForThings does not make them clever, either.
I can certainly see the point of some of XP's major bases, but most of them aren't unique to XP, either. We frequently work in pairs at work, not just for a quick review, but really, for hours at a time, just as XP advocates. And yet we don't claim to use the XP approach. We refactor code a lot, and yet we don't claim to use the XP approach.
In fact, the XP approach would likely have killed the project on which I work before it even started. Perhaps it's exceptional; it really is a MLOC project, it really has been going several years, they really did spend months to start with developing the framework on which it's based, and it really has paid off.
Granted, it's over-engineered in places, which XP code should never be. Then again, I find it very hard to believe that an evolutionary approach such as XP advocates would ever have produced as well designed and integrated an approach as the senior developers on this project produced after weeks of forward planning.
So, by all means highlight the strengths of XP. But let's leave the "Everyone should adopt it, because it's great, so there!" out, OK?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Woah, Stanford. Well since you went ahead and tossed that big name college out there, I will have to concede my point. You must be right.
Back to the matter at hand, though - software problems are "complex" only in theory. Any given component can always be simplified. (That is the basis behind any heiratchical design technique, such as Jackson Structured Programming.)
As any given component can be simplified, you can ALWAYS reduce it to a put-block-A-on-block-B level. This will NOT produce the "best" code, it is only guaranteed to produce working code.
The challange - the REAL reason that programmers don't bother with Z, or JSP, or any other formal method, is to contract that expansion into something useful.
Squeezing the expanded code, WITHOUT breaking any of the code, and WITH improving space & execution times, is not a trivial task. On this kind of scale, it can't be automated. There are no compilers with optimization routines capable of turning Z-specified code, at the most fundamental level, into useful, usable code.
Nor are there any programmers capable of this task, or so it would seem, since virtually nobody even tries. (I include myself, here.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Is it:
1. Massively documented, heavily object oriented code with lots of reuse, designed for ease of enhancement and maintenance, etc?
2. Tight, fast-executing code which, while it may be difficult to figure out at first glance, is powerful, resource-sparing, and generally cool algorithmically? Of course it is well documented, designed carefully, etc.
3. Other standards of elegance?
There are jobs for which (1) is the definition, and others for which (2) is a good definition - although my own bias leans toward (2). Note that systems built with (1) as the definition tend to be resource inefficient, but in many applications, this doesn't matter. Are you writing code which glues together a bunch of legacy db's and other apps or are you coding an OS or filesystem? To borrow a phrase from architecture: form follows function.
It has evolved in the same way that melanoma can be considered to have evolved from healthy skin cells.
Part of the problem lies with the root of the profession. Most software practitioners would compare themselves to doctors. Well with their media generated "Dr. Kildare" image of doctors.
Real doctors harbor no such illusions of infallability. They know its called a practice for a rason. They're practising. Medicine unlike say, architecture, is far from an exact science.
Most software projects start with simplifications based on unjustifiable assumptions and descend quickly into a managerial surreality where no regard is shown to the customer needs, marketability or even reality.
Most people who cobble software together, like Frankeinstein stitching away in his laboratory, should consider careers in other fields: ("Ya wan' fries wi' 'hat?") They are too fuckin' ignorant to do it right at almost any level.
Just because any fool can write a Visual Basic program with VisualStudio doesn't means that its a good idea.
While the level of naivete shown by software developers at all levels, from the CEO to the janitor, might be delightful in a three year old it is downright frightening in alleged adults when you consider the degree of waste generated by the ineptitude of these cretins. They are forever re-inventing the wheel in the name of intellectual property. What property? What fuckin' intellect?
The problem with comparisons to architecture is that they aren't valid. Architecture has standards groups, construction guidelines, review boards and comittees, material science and the one thing all architecture is in opposition to: gravity. Its residents may suck but the earth doesn't. Even at that people plunge down shafts, fall off balconies or trip and break off bits every year.
How about automotive design? Until there were mandated to by force of law (and long jail sentences for murder,) cars had long solid steering wheels which could be counted on to impale the person behing the wheel in a head-on colision like a bloody butterfly to a display case. The Chevy Impala was also the Chevy impaler. The Corvair launched Ralph Nader's career. The litany of tragedy is not limited to one company or one continent.
How about roads? The Romans built roads that are still in use. Yes. Nice flat roads on nice flat lands. Along mountain roads in many countries they plant a white wooden cross for every person who has died as the result of a plunge into the abyss at that spot in the road. (Bus plunges are specially showy but not as effective as a steel guard rail.)
Most design isn't. Jonathan Ives may be brilliant at putting together pleasing designs but I wouldn't necessarily trust the guts if he had to put together the ENTIRE box, contents and all.
Most software is inadequate crap slapped together by people who are trying something with one lobe of their brain tied behind their back. Its systemic and self-inflicted container-based stupidity.
Most managers can't manage to keep out of the friggin' way or to keep their people supplied with guidelines and guidance. Most QA is dedicated to catching shit when the clients are already stepping in it. Most documentation sucks the wind that someone else broke. Its always late and never accurate and is usually written by someone whose grasp of any human language is, at best, tenuous.
Hey! I wouldn't ask Proust to write a payroll program, why the fuck is some COBOL jockey writing a user manual? He can barely complete or comprehend a compound sentence. Nobody ever knows about the context that their software has to operate in.
All in all, this is a pretty sorry industry.
Now for the big pronouncement:
This industry will be fucked as long as we use a container-based paradign for encapsulating software architecture.
The very thought of encapsulation is a management fallacy.
The management technique of drawing the box and cutting out everything that slops over the side is completely backwards.
What fits completely inside the box is monotonic, generatable and hopelessly isolated.
The strength of a system lies in the parts that slop over the edge.
Systems are made up of objects and their relationships in the same way as a brick wall is comprised of bricks, mortar and the spacial relationships betwen the bricks.
Architecture is not about bricks and mortar but about bricks, mortar and the space that is defined.
Software architecture is about classes, objects and relationships.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
This struck a nerve. It's when you have to dig and find out what a pice of sh*t it is you get mad. I've dug into code and thought "man, this is crap", but then again, it looks a lot like the code I wrote two years ago.
But the other day I went to replace a toilet in my house (cracked base). When I pulled it up, I found a HOLE (I could see the dirt below the subfloor. Stuck into the toilet base was a thin metal pipe (think dryer vent pipe) rusted out, no wax seal, all the floor underneath rotted.
Am I mad at the builder? Well, a little, but the house is 50 years old. I'm mad at the inspector who was too lazy to go 60 feet into the crawl space to look at this. One look at the pipe, you knew it was crap. And the black, rotted subfloor should have told you something..
Similarly, I get mad at management for not LOOKING AT WHAT THE CODERS ARE DOING plus, of course, not backing coders when they say "this module is crap, it needs to be fixed -- excuse me "refactored."
BTW, if you're curious, 14 hours later, replaced pipe with new PVC, patched it into the existing drain pipe (cast iron), replaced subflooring (got lucky there, tile was set in an two INCHES of mortar, stayed put fine while I replaced the boards underneath), jacked up a new extra support joist between two others, and installed the new toilet. You want it done right? Do it yourself. You program software right? And you think plumbing is hard? Nope, just messy and tiring. HACK YOUR HOUSE!!!
DO NOT DISTURB THE SE
We should expect the same level of quality and performance in software we demand in physical construction.
Consumers are not willing to pay for such quality, or wait for it.
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Software engineering is not at that point yet. We don't have rigid standards in place for stuff that is really at the raw material level in software. What our discipline needs is standard, off the shelf software components that have been proven to be both bug-free and to have used the best algorithm possible for its task. Some people claim that writing bug-free software is impossible, and maybe so, but we could still learn from other engineering disciplines and strive for a six-sigma level of quality.
So what is really needed is a big, powerful, high-performance, and bug-free library that is able to perform common programming tasks. Preferably, it should have the ability to be called from a variety of higher-level languages. Come to think of it, if the underpinnings of
So far we aren't there.
No, Thursday's out. How about never - is never good for you?
If anyone reading this does NOT use warn (invoked by putting a '-w' after your perl interpreter call, ie: #!/usr/bin/perl -w
Obsolete, use use warnings; for recent versions of perl.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Right on. I'll gladly take a safe memory-managed language like Java to write my efficient code, since it means I can spend more time optimizing things which really matter (algorithms).
By the way, there exist languages with the same abstraction qualities as java (safety, garbage collection, portability, etc.) which aren't slow in the sense that the original poster meant. Check out O'Caml, for instance. It's got a lot more interesting features than Java, and runs as fast as C.
At my former employer, software was written cheap. There usually were no requirements (at least no written ones), no real management, and the execs wanted the deals in.
So, sometimes a project manager had a moment of brilliant thought when writing a schedule, time estimates, and budget, and happened to ask some senior developer "how long would this take, who'd need to work on this". With the answers (still not good, due to lack of information) he'd go on and get a decent schedule, time estimate and budget.
However, then the sales intervened with "the customer needs this faster and won't pay that much". If the project manager again happened to understand what's going on, and asked the senior developer about if those changes were possible and what would need to be cut, and reworked the numbers, they'd still be over the sales requirements.
Now, some exec who wants that particular deal in takes the numbers and the sales requirements (max time and money, both at most half the schedule and budget) and finds another project manager until someone takes the deal and decides he can make it happen.
Of course then the schedule and budget are blown, the customer is unhappy and the company makes loss with the project.
Some of us got sick with the company. We talked with the management, disagreed about the future, strategy, and basically everything there was. We walked out and formed a new company.
Now, we have written project orders with written requirements and written acceptance criteria. We give reasonable estimates about time and money, and if the customer doesn't want to pay that much or wait that long, we don't get the contract. However, we still have customers who're willing to wait and pay for programs that work, are documented, and tested. And the developers are happier.
And I'm a lot happier. Now I don't need to take deals that would need to be done "just well enough that the program works".
(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.
What?
Why should software be "beautiful"? Why should we care? Although I wouldn't use "beautiful", I'd use the analogy of the architecture of a house to software, as opposed to a bridge. Once a bridge is done, generally it stays the same. A house, on the other hand, is often expanded and modified a lot (depending on HOAs).
. No, software is designed a _LOT_ worse nowadays than houses.
:(] and down the road, it'll save WEEKS when the inevitable design change is asked for (threaded table access, or dynamic table sets per configuration). By abstracting various key items up front, making major architectural changes were done on time and under budget.
From large software projects I've worked on, the original design had some sound principles, but it's architecture didn't allow it to expand to meet the inevitable requirement changes. Sort of like adding a room to a house or changing the size of a bathroom. One's idea of how the house would look was different from the next owner's (like programmers), so over time some houses look and feel like crap because of conflicting architectures. Or rooms are appended without thought so it's harder to move around the house. Just like it's harder and harder to add or change modules (classes) without introducing bugs due to bad software architecture. I'm living this problem of bad architecture in my current job, so I know of what I speak.
As to other posters comments about how badly houses are built, I say if a house was like some software projects I've seen, you would have water pipes running straight across a hallway a foot off of the floor, outlets that aren't grounded, or stairways that go to nowhere (like the Winchester house http://www.winchestermysteryhouse.com/story.html)
When I have a new project or expand an existing one, I always try to take the time to decide if part of a class should be abstracted out here or implemented right there. I ask myself how do various classes interact. It doesn't really take that long to draw a sketch of what the architecture should look like. You don't HAVE to do a 100% UML set of diagrams [unless you have to
As for the comment that we've talked about this a few months ago, it looks like we still need to talk about it some more. The software projects I've seen are still just as crappy as a few months ago, and the year before that, and so on. In fact, I think we should continue to repeat this post every few months until we get it right...
Why should software be "beautiful"? Because your career and how people perceive how well you program may depend on it, as they will inevitably ask you to change it. Trust me, they will. The days of rigid monolithic military government (MIL-STD-1679) requirement definitions are gone (if they were ever there in the first place). Are you going to just sit there and whine about how difficult it is, or just do it and amaze others?
I think in the book 'The Hacker and the Ants' there is a quote along the line of programming being like building out of toothpicks carefully glued together and if just one toothpick is out of place the whole thing comes crumbling down. I always liked that.. it seems very truthful. I might add that programmers are usually encouraged by those they work for to forget careful design and implementation and just duct tape parts together as quickly as they can make it work 'most of the time'.
I like to write beautiful code.. as I imagine most real programmers do.. us geeks that live, breath, and dream in code.. but in real life there usually is not enough time or resources given to manage to write really well planned out code. This is why Microsoft sucks and a popular motto is "When it's done!" among the truely geeky programming houses and why open source will eventually kill most commercial software.
With commercial software if it's ugly you aren't likely to get a second chance to really make it beautiful. With open source software it may start out ugly but over time can gradually become beautiful as people clean and fix it. The code is visible and so is everyone elses. You can help each other and learn from each other.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I mean what would we do with all this 1 GHz+ processors and 512mb+ chunks of ram? If everyone starts coding better we could go back to older machines and be faster than we are now.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
I expect that software quality is about to take a sharp turn upwards. We're going into a recession. Places like HP and Compaq are laying off heavy hitters. The "Learn Perl in 21 days" crowd will go back to flipping burgers. We're going to see more people with CS degrees doing maintainance programming.
I agree that software should be beautiful. The real problem is that the judges of the computer program beauty pageant also think that this truck is beautiful. Seriously...if beauty is in the eye of the beholder, then why is it news that we should write beautiful software? Somebody should start a school where they teach nothing but artistic value in programming and post it on Slashdot. That would be real news.
If tits were wings it'd be flying around.
Hmm I fear posting so late nobody might read this, but well I'll post eitherway ahead.
:)
:o) With source comments allied to the bridge example, /* we added this plank here, since if not the bridge will always fall down when poked 3 times in 1 second distances, we don't know why, but with it vanished. */
The fundamental goes about development costs. The article descripes the problem very well in software people can't see inside like in houses or bridges. Okay with OpenSource they can, but still most users won't
The matter is as a project making super stable software is far to expensive to be compatitive. Software for airplanes and for nuclear powerplants is tested with other means than 'normal' software. These software is usually tested with a kind of profiler support, until it is taken sure that -every- branch of the software has at least been taken once, and every loop has at least looped 3 times during the test. This requires high qualified testers, beeing able to read and understand the source, and more important time, time, time, time, which is a lot of money. For high security systems this pays of course of. But again people cannot see how the bridge is constructed, say you will be buying a bridge, and it's a black box for you, you can't see it's fundament, you can't see how it's pillars are constructud, it's just a path from one shore to the other. Now for which of the two will you decide? Okay you'll evaluate both, and ran on both bridges a few times up and down, maybe send or two a cars over both. They're stand you're test, and you can't see the one that's build with super high quality means, build of concentrate and secured with steel cables, and the one that's a chaotic assembly of wood added and added to it until it did no longer break if the builders tried to walk over it. Now the first costs 10 times as much, which one will be bought? (remember you can't see the wood vs. steel)
So for software, everybody wants graphics, GUIs, 3d, easy click and features, and features, and features, nobody wants a plain but constructed very carefully but boring/simply interface. Your costumers will need the features, are at least think they can't live without and leave you for featurefull wood bridge.
OpenSource at least eases a little, since people -can- look how the bridge or the house is constructed, but really take yourself, did you ever looked in example at the sources of xfree, gcc, bash or any of the applications you use each day?
In example when exploring the sources of the linux kernel I've a subjective of course safe feeling, most of the stuff looks nicely constructed, and is not super complicated. On the other hand other (opensource) software I looked at, you shudder, but think, well it runs aster all so I just better wont touch it. I'll not call names for this catagory since this would be just a flame, and maybe only because I didn't understand some stuff. But trust me for a quite some closed applications if you could look at the source (supposing you know C(++)) you would never want to start that application again
In this case the construciton engineer would investigate and proparly discover it's some kind of harmonic vibrations that cause it to fall down, but for the (commercial) software enginner there is no time or money for this, he couldn't explain his chief they used up 6 weeks to find out why a plank more changed the harmonic oscillations, he just adds a plank and the problem vanished, so the problem is finished within the available resources.
--
Karma 50, and all I got was this lousy T-Shirt.
The point we as coders seem to consistently miss is that code isn't supposed to be pretty. It's supposed to provide utility to the human using it to make them more productive. Don't misinterpret me, pretty (better stated: more concisely and completely documented) code can co-exist within software that meets this goal.
At the time I started using Dr. T's music sequencing software on a Commodore 128 I had no fscking idea what C was. I don't know what that thing was written in to this day. But I wrote over 75 songs in 2 years and haven't created that level of product in the past 13 years.
I used Cakewalk 2.0 on Win3.1 for a couple years and was equally productive there until 1995. That's when music went away and I started hacking Linux because MickeySoft pissed me off so much with their "innovations" in Win95 that it completely killed my machine's ability to perform my most important task (writing music).
Thankfully, with Win2k and it's better stability Cakewalk 9 and my killer 128Mbit Creative Platinum with built in MIDI have brought songwriting back as an option. Yeah, it's Windows, I hate it, and it screws me sometimes, but not so bad that I can't write songs now. Honestly, I'm not that interested in coding C, now that I can write music again. Trust me: my music is better than my coding, although my coding isn't lousy.
What I want is Cakewalk for Linux and then I'll leave you talented hackers to your domain and drift back into that which I've wanted to remain in before all this sloppy coding pulled my sorry ass out of it.
I don't care what the source looks like, but you should comment your code. I just want results. I'm sure most others do as well.
www.dedserius.com
VB != VisualBasic
Maybe when you have the time you could fix it and submit a diff to the author. Or perhaps you can submit a bug report. It couldn't hurt.
War is necrophilia.
Programming software is nicely compared to real world construction except that ...
... but that would never be an relevant example: real software development is a convoluted and fluid transmission of ideas rather than a construction of anything - even in the ideal CASE tool driven, XP driven, UML driven, highly "engineered" environment. Again, it's a lot more like writing or speaking than like construction.
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
Beatiful code is a for loop which takes up 10 lines between the (). 8^)
Yes, I am indeed very evil.
You'd be surprised how much faster code runs when you increment in the for loop constructs than inside of the loop.......
Almost always, functinality must be proportional to complexity. The converse makes no sense.
Furthermore, depending on the skill of the developer, errors have a certain probability of existing per unit of code. More code = more errors.
Now biologically: functionality of an amoeba vs functinality of a fly. Or, probability of getting cancer in a specific cubic millimeter of flesh vs. probability of getting cancer period.
And now that I've made excuses for messy software... here's how to avoid it:
"Never build an application."
[instead]
"Design a domain specific "language" that can be used to talk about applications in this domain. " -- The Pragmatic Programmers
-... ---
But you have to know what to look for. I've often found a badly designed user interface to be a real tip off that other parts of the software are crap. I'm not talking about pretty pictures and cute icons (which, unfortunately, is what a lot of people in the free software community think constitutes usability), I'm talking about whether widgets are laid out in an unambigous manner and whether operation of the interface is efficient and cognitively sound. If a company designs one part of the system in a very half-assed manner, they'll most likely do the same with the other part, too.
In my view, there are two extremes in which a software project can be approached:
:)
I) Design it to death
Take a few weeks to write specs that describe every nitty-gritty detail. Reduce coders' individual freedom to a bare-bones minimum.
Advantages:
- Client knows exactly, beforehand, what a piece of software will do and at least to an extent what the cost will be.
- Programmers know exactly what their job is.
Disadvantages:
- Constant micromanagement is required to find out if the programmers in quiestion aren't cutting a few corners to meet their deadlines/to show off.
- For a huge amout of time, no progress is visible, since everything is planned in advance. This could lead to a seizure or two when the deadline is there and the resulting software doesn't meet requirements.Also, tests can't really start before the project is completed.
I suppose this method works best if you have a team of inexperienced coders and a rather large architect force.
II) XP
Together with client, draw up a list of requirements. Then hand out this list to all programmers who divide the work out amongst teams either made by themselves or by management. Make them develop on a shared, simulated test-implementation environment.
Advantages:
- Huge cost cuts are made in the design.
- Obviously, since there is a shared, 'real-life' testing environment, testing can be done at any given time.
- Kent Beck could give you about a thousand more
Disadvantages:
- Requires a lot of independence from the programmers themselves. Independence some, if not most programmers simply do not possess or even _desire_.
- Assumes a good design will sort of 'come naturally' out of a joint team effort. I do not believe this notion will ever hold true, maybe only for small teams.
- If one little cog in the XP wheel is missing, like continuous deployment and testing or constant peer-reviewing, the whole thing comes crashing down like, well, a badly built bridge because -guess what- the DESIGN is missing!
XP works, I've seen it work, but only in small teams, on small to medium projects done only by REALLY good programmers.
Conclusion: The old-style, Systems Development method of doing a software project is certainly up for a revamp, although I think XP is too 'Extreme' for most real-world situations. My clients generally _want_ to see solid design before they OK a project, they simply aren't content with just turning in requirements, and most certainly do not want to put one of their own tech people on the project (why else would they have come to us).
I personally believe that there is a more elegant solution to the dilemma, which is combining the design phase of old with both generative programming and the development phase of XP. It may seem a bit bulky at first but with generative programming a lot of bulkiness is taken out of development, and people can start 'dumping modules' into the test environment almost instantly after design has finished.
__
Not believing in force is like not believing in gravity.
Part of the problem is the languages people use: modern functional languages virtually force you into a safer, cleaner programming style and these days don't require you to compromise on efficiency; most imperative and OO languages lack any real facility for abstraction and in many ways just make you stupid. There is some hope: if you want the best of both worlds use OCaml - it's often faster than C with all the OO, abstraction and type safety you could ask for. It's imperative, to boot, if you have to think that way.
Market forces place universities under pressure to just teach people Java/C#/C++/whatever is being used in industry at the time, rather than teaching students how to use abstraction to solve complex problems (as opposed to just ad hoc hackery). The debate isn't going to get anywhere, however, because people who demanded and got this sort of bricks-and-mortar-but-no-architecture degree don't want to hear it. They're in the majority and managers know what they're hiring, even if experience shows time after time that the results are bad.
If software were a bridge you'd use it to cross an otherwise unpassable gap between two points, and NOTHING else. There would be 2 or three basic designs which nobody deviated from and nobody would have seen much innovation in decades if not centuries.
Software is in better shape than this dumb article suggests. You can get better software, but you have to pay for it and folks don't want to. Pay in open source terms means have less software around than you need with developers concentrating their efforts on fewer projects.
People not comprehending software keep trying to compare software to some hardware analog, such as bridges, constructing houses, conveyor belts and what have you.
I have never heard one analogy that it correct, and nothing is so dangerous and irritating as analogies that seem to apply at first glance (since they tend to suggest a wrong fix).
People, especially managers, keep being frustrating because they don't really seem to understand what their people are doing and they feel they don't have control. Then they envy the "neat and ordered" world of (e.g.) house construction, where you can see and feel concrete building blocks, have an architect making a design before etc.
What they forget is that software is endlessly more flexible, and is also expected to be so. During construction requirements keep changing, also after delivery new features need to be added. The environment keeps changing (operating systems, hardware etc). Imagine to construct a house and then halfway and afterwards keep making big changes *all the time*, while also the environment changes (hills arise, climate changes rapidly (ice ages etc), rivers come and go, sea level changes etc).
Obviously this means that those nice and orderly "standard building blocks" that many hardware engineering disciplines have does not apply very well to software, and thus design methodologies, techniques etc keep changing in a fast pace.
Therefore any analogy with hardware construction is flawed and leades to counterproductive conclusions and methodologies.
Nope, I haven't designed bridges, but have designed bridge cranes (and had my design checked by my boss). Bridge cranes really age a lot like bridges in theory, but they move around.
I've also designed electronics (Including firmware)
I'd say, in order of difficulty (assuming you are in the same part of the technology curve of each technology)
1) a Bridge
and then tied - electronics and Software, and a LOT of the problems in electonics come down to firmware problems (Hard Realtime is "fun"). That said, I'd dare some folks to trace out common noise problems in a prototype high density switching power supply (and the stuff you see in a PC power supply isn't high density)
I'm a bit older than most of the folks here, and have had some fun over the years. I've gotten to recreate the Tech revolution. I started with steel working/machine shop work (which is still a hobby), went on to electronics, and am now a programmer. I've gotten to see how all these tie together, and trust me, they do
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
software is just as good as people are willing to
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.
The software market, and in fact the entire computer industry, is not mature enough yet to offer a high level of sophistication and uniformity. It's where auto manufacturing was in the early part of last century. There are a few mass marketers producing vanilla products for those who are dying to spend for it. They have the upper hand becasue people are going to buy whatever they can find. If you want a high scale product you're going to have to pay someone to make it for you. Otherwise you get what they have to offer, and it's good enough because it's the only thing you have.
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!
- Sig this!
...following that analogy, we could build beautiful robust software, in say, a century perhaps? Sorry, but real users want real software yesterday...not beautiful 100% bug free correct software ages from now. Programming != Engineering.
It's 10 PM. Do you know if you're un-American?
1. Tell them if they're too busy to use the system, you're too busy to write it for them. Seriously, you need to reach an agreement with clients when the project starts on how much work you expect them to do.
2. You need to do a proper analysis - interview the customer's staff, write use cases. This is where XP falls down - how are you supposed to know the problem domain ?
Engineers of Dreams at amazon.
Read a good book lately?
Your analogy with construction intrigues me.
Yes, I'm an engineer and I sit in front of a terminal coaxing C++ code into looking half way elegant, doing the job and being a pleasure to look at in the future instead of the pain that happens so much during the inevitable phase of maintenance and improvement.
I also built a house a few years ago and obtained a general contractor's license so that the bank would trust me with doing the subcontracting.
If you think that by virtue of "it's being in the physical world" that construction is some kind of nirvana where design elegance and the true art and beauty of the profession of engineering can flourish unimpeded, then think again.
In terms of residential house construction, the whole endeavor is a mess.
I could tell you the sorrowful tale I heard one Monday morning, when asking where John the other worker was, and was informed that, tragically, he was still in jail for DWI over the weekend.
Or the framers that got cold one morning and built a fire on the slab to keep themselves warm, nevermind the sparks wafting through ultra-dry framing and expensive heavy logs that had been hoisted into place for the house.
Or the initial 3 week time estimate for completing one phase of the job that stretched into 10 weeks, requiring constant rescheduling with subsequent subcontractors (never mind the heavier interest on the money I'm paying on the construction loan).
Or the interesting "features" that crept in (and then had to be worked around) because various individuals couldn't read blueprints properly (no, the beam can't go there because there's a fireplace directly beneath it).
Or the knowledgable foreman was out doing sales while the jobsite got staffed with ignorant, wet-behind-the-ears kids in charge of the project. The end result was a standing edifice that was "acceptable", but a careful scrutiny with a level and plumb line showed where shoddiness had crept in.
I could whine for ages about my experience, but I'll cut it short to summarize my experience with house construction projects:
Yes, things are different in commercial construction versus residential construction. Commercial buyers know it's not uncommon to pay $200 / sq ft and the more important the structure, the less allowance can be made for shoddy work. And that observation starts to address some of the issue in a more meaningful way.
Usually, shoddy workmanship creeps in for a very good reason: it's cheaper to get shoddy work done that to get good work done. And most uneducated buyers look primarily at price and usually little else.
It's all fine and good to exhort practitioners of the fine arts of construction or of software building to hone their skills and to take pride in their workmanship. But the root of the issue can be traced to the buyers of the services. They are the ones that need the education: they need to know the difference between shoddy software and good software and to learn to appreciate fine workmanship in software. As buyers, they are the ones ultimately responsible for promoting or denigrating the fine arts of software building.
"Provided by the management for your protection."
I'd call that an extreme case of biting off too much at one time. XP in and of itself is a cultural change. Turn around and change the language as well is gonna complicate things more. Early XP at a company should be the only "new" thing being done at one time. Once the programmers are truly XP's, THEN you can switch other parts of the environment.
Also, there's enough missing in your description of this that would lead me to think that the company is blaming XP for a true LACK of design. There is still a design that needs to be followed, at the higher level, and an upper manager deciding which parts of that design get implemented in the XP way. Part of that design is in talking about how components done by individual pairs get integrated together again. That requires extreme communication at the early stages of work before you go through pairs together to "do this, do that, test it".
Software is still complex, as much as XP tries to hide that. Non-trivial software still requires division of responsibilities and agreement of component interfaces so that later component integration can take place with relative ease (e.g., again in the XP way with two programmers, one from each component being attached at the time)
Since XP requires extreme levels of communication and feedback, and the company was not achieving communication adequately, then its easily concluded that the company never really used XP, and therefore XP is not to blame.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
A friend of mine's father is a Civil engineer who does a lot of work on bridges. He refuses to use the Lions Gate Bridge between Vancouver andNorth Vancouver (he lives in North Van, and there are only two bridges between North Van and Van.).
Free Software: Like love, it grows best when given away.
Microsoft's best product is Excel. Why? Because, unlike NT or Word or whatever, it's the main application used by the people who sign the cheques.
The Free Software Foundation's best product is Gnumeric. Why? Because, unlike GNU/Linux or GNOME or AbiWord or whatever, it's the main application used by the people who sign the cheques.
The KDE Team's best product is KSpread. Why? Because, unlike KDE or KWord or whatever, it's the main application used by the people who sign the cheques.
Will I retire or break 10K?
"If construction workers built buildings the same way programers wrote code, the first time a woodpecker came along it would destroy civilization."
...
At least we have OOP and Generic Programming to reinforce our "buildings" now.
Getting this back on topic
Code *can* be art. I've seen some beautifull code: Elegant, and powerfull. It's amazing how the elegant solution is usually smaller and less complicated then code written by someone who doesn't really understand the problem.
If code, or math equations, can invoke an emotional response out of me, I'd say that qualifies it as partially being art.
What you don't have time to submit a bug report? Give me a break. If you can't do it at work do it when you get home. If you are unwilling then don't use it and don't whine about it. There are plenty of commercial products that probably work just fine just pay your money and go about your business.
Lead, follow or get out of the way. And in any case nobody wants to hear you bitch when you aren't even willing to submit a bug report let alone a patch.
War is necrophilia.