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.
While I personally try to produce something I can be proud off, saying there is shody work out there is not news.
I would wager that most car mechanics, plumbers, electricians, home builders, anyone-who-works-on-something-you-don't-see are crooked, cutting corners where they can and shamming the public.
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!
once I was working on network performance monitor (written in C). Once I had a 'basic proof of concept' (quick and dirty, but mostly functional), I've told the interested parties I would have to re-write it so it would be modular, easy to read and understand and of course easy to debug. To my surprise those jerks gave me a hard time (noone gives a shit about your 'aesthetical feelings'). Well I did make some minimal changes and left the company soon after that. Hope someone is still struggling maintaining the code. The bottom line is that 'inner beauty' of any software is not a luxory item.
If you ask me, it's those damn comments! They make my code look ugly! I write thousands of lines of beautiful code, only to have to return to it to comment it so joe programmer can come along and "maintain" it later. If it weren't for the comments, my code would be more beautiful than a bridge!
And BTW, did anyone notice that this guys code snippets are in Basic? That's enough to dismiss the article right there!
mp3's are only for those with bad memories
Of course that guys software stinks, he's using Visual Basic. ( Check the code sample )
This is news to some people?
This complaint is as old as most code. There has always been a better way to do things. It's just not the most profitable.
Death and poverty like me so much, they've brought friends!
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'..."
... Charles Connell, for creating more "lousy" software. Call me crazy, but I would think that if you wanted to rant about "lousy" software you'd have the presence of mind to write decent-enough HTML so that the character " didn't show up as ? and bullets didn't show up as the character Y.
This article is a challenge to engineers, managers, executives and software users (which is everyone)
Lets be fair now. Some people actually don't use software (or computer technology of any sort).
Of course, no one any of us know.... but i'm sure such people exist!
___
The way to see by faith is to shut the eye of reason. --Ben Franklin
Conversely where this approach is required (saftey critical systems) Formal Methods such as Z and VDM are often applied to prove the correctness of the specs etc and therefore guarantee bug free code.
As ever it is Horses for Courses. Don't lump all software developers together.
Crap inserted to avoid lame compression filter what is this bullshit ? slashdot has really gone down the tubes don't know why I keep coming back ! thank you.
The Independent: Reverend Spooner Arrested in Friar Tuck Incident - ISIHAC, Historical Headlines
The article has code fragments. Just now I noticed it was VB!
Why not show C++, C, or Java? That way you can really show the difference of a bad written program compaired to a good written one...
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.
I come from a computer engineering background so I would love to see fundamentally sound software that is clean, efficient, and fast. On the other hand, compilers are very good at optimizations these days, and processors even have methods of reorganizing instructions to gain speed, so one can argue how necessary it is for code to be perfect. I would like to see "beautiful" code, but I don't really think there would be much performance improvement.
~ now you know
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
Is it just me or is computing going backards. It used to take 2 seconds to boot into DOS, yet it takes 20 seconds or so to boot into Windows 2000. We have various gui based medical management software that we manage at my place of employment, but the old dos versions were far more efficient. Call me a hermit, but I think that the "user friendly, gui=productivity myth" needs to die. Visual basic should not be used for ANY production applications. Especially in mission critical system. That aside, I would like to thank all of the crappy programmers, for providing me with job security. As long as your stuff breaks, my future looks bright.
Remember that you are unique, just like everybody else.
In commercial software, customers drive a demand for new software such that companies are punished for taking the time to try to get the software right. Time and again, when offered the choice to go with software that has been well-written versus software that is poorly written (but available today), the customer will choose what is available today.
I do not see this changing anytime soon.
And so it goes.
The software for millions of home PCs doesn't have to be that bugfree, really. There is no catastroph if a computer crashes now and then. The prices are kept pretty low, but instead it's not perfect. The better and more error free code you want, the more expensive will it be. For example, the software running at a nuclear power plant or in the space shuttle is probably very error free and has very few bugs. However, the time to develop it and the cost, must be way higher than any other system. It's all about how many errors you can tolerate in a system.
Will work for bandwidth
Bridges are designed the way they are because there's a large need to ensure public safety. That is why you have licensed engineers reviewing plans and signing them.
Code is just not as important. If it there is a malfunction, no one dies. If there is that possibility, then higher coding standards must be met.
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
Good programmers work for good money. How can you expect good programmers to be involved in projects that don't pay good money... Easy answer. You can't.
I also like this post for this reason. I think it serves to rally all of the programmers in the world to get together and agree to write good code. See, I write sloppy code on purpose. Now that I know that I'm not supposed to, I'll start writing clean code.
I came up with a cheer too...:
Rah Rah Ree! We Like our Code Clean! Rah Rah Ro! Sloppy Code Must Go!
Certainly every man at his best state is but vapor
Designing 5-9s software for commercial use is like making a knife out of diamonds. Sure, it's more durable, but it costs a hell of a lot more than people are willing to pay.
-no broken link
Take a look at the average house today as opposed to one built in the early 1900s. Today's houses are cookie cutter style boxes that look exactly like the ones next to them. Furthermore, these houses aren't going to last very long...I know WAY too many people who have dealt with shoddy construction of newer houses.
Houses today aren't nearly as ornate as before -- there is very little woodworking, no secret passages, not too much stands out.
The software world is much like today's house market -- contract to the lowest bidder, make sure it doesn't show any weaknesses until after purchase, and who really cares if the sheetrock cracks and the beams bow after you've sold it?
It's hard to try and make software look like Victorian houses -- nobody wants to pay for the added effort and longer wait. Especially when a cookie cutter Colonial will get the job done.
What pretentious bullshit. Software is NOT art. It can be closely compared to bricklaying, or cabinet making, it is a CRAFT.
Try expressing an emotion in C++. It cannot be done. Please think before repeating these banal opinions that software is art. It just isn't. Deal with it, and if you want to be an artist, learn to paint.
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.
education, medicine, accounting, law,
and journalism.
OpenBSD... Nuff said...
Most people who write papers chock full of sweeping generalizations have no idea what they are talking about
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
The main reason that most software design sucks is that the engineers are not give enough time to do the project right. The idea is that you just get it out to market and you can always patch it later. Try telling some guy with an MBA whose making all the decisions that it is better to take enough time to do a project properly. All he/she knows is that the "magic black box" will produce the same output whether the design is good enough.
So the same scenario is repeated over and over:
Engineer: "I can get this done in 10 months"
Manager: "Hmmm..... we need to get it done in 6."
Engineer: "That's not enough time to design and implement a clean, extendable, reusable product!"
Manager:(Confused by big words like 'extendable')
"It'll work though right?"
Engineer: "Well yeah, but..."
Manager: "Just get it done in 6 months."
As long as you have people who have no clue about software making deadline decisions, you're gonna have to hack like hell for 60 hours a week just to get it out the door. It's sad but true. Granted this isn't ALWAYS the case but in my experience it is most of the time.
If you want to take the time to do a project cleanly then I think academia is your best bet.
I don't know about anyone else here but I HAD to take a Human Factors class before graduation from college. I'm damn glad of it too.
Warning! Keep Out of Eyes! Wash Out with Water! Don't Drink Soap! Dilute! Dilute!
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...
The article has a lot of merit and its an evolving art for most programmers. Charles forgot to point out one thing. Most houses these days are forced to be built under the same demanding client deadlines and requirements. You may have to rush building a house, but I have never heard the term "death march" applied to building a house. Beautiful code isn't an luxury in many of todays coporate software environments.
1;
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.
This is stupid. Software will never be failsafe and pretty--the open source guys, who aren't dictated by release schedules and costs can do this--I'd love to be able to write perfect, pretty code--it just isn't realistic. Software costs money. Quality is directly releated to the amount of money your willing to flush on it. Software design != bridge building...nuff said
It's because managers seem to think that any computer related degree means you can design and write software. I'm not being mean here, but if you have a degree in maintaining networks or creating circuit boards, that does not mean you can design software.
I would hate to buy a cpu designed by a software engineer. But apparently buying software built by non-software engineers is ok.
I have found that very few software companys hire only CS majors for software jobs, you look on monster and it says, "Computer related degree required". That's bullshit people.
Not all code is built so poorly. In fact, most code is built quite well.
Just like things in the physical world, code almost always does what it was built to do quite well. For example: Microsoft Word is an excellent Word Processor, but a poor/pathetic drawing program.
Also just like things in the physical world, code is used for things it was not intended to be used for. Have you ever driven your Geo Metro through a river? Have you ever driven a tractor trailer over an old wooden 1 lane bridge? No, probably not. You would be crazy to try something like that.
People try to do things with software all the time that it was never designed to do. That is a big reason why software fails so often.
Of course most of these "things software wasn't designed to do" aren't always documented. For instance, Outlook Express is a decent mail program, but did you know that it almost always fails when you have more than 10000 emails in your database? It is not documented anywhere by Microsoft, but they have admitted to myself and others on their tech support line that Outlook Express fails due to faults in the mail database. Their theory is that OE was never meant to be used "that much" - so you should use the "industrial strength" Outlook instead.
If only we all knew what the true design limitations of the software we use were we would be much better off. In the physical world, this is very easy to measure. That bridge you just drove over to get to work? It has a nice little sign that says "capacity 6 tons". You would be a little nuts to drive a 40 ton cement truck over it now wouldn't you? People do that sort of thing with their computers all the time and just never know that they are doing it...
Take care,
Brian
100% Linux Web Hosting - No Windows - Fanatical Technical Support - Customer Loyalty Discounts
That's ludicrous. Much of the software in the world today is designed to be portable. Various hardware, multiple OSes, etc. etc. Perhaps in the age of mainframes this idea of "terrain" was appropriate, but today? Hardly.
Those who fail to understand communication protocols, are doomed to repeat them over port 80.
Think about sufficiency and cost. Most houses are built to meet our housing needs in a sufficient manner. Should houses be constructed to last 500 years and survive F5 tornadoes without any damage? How much do you think that an average sized house built to these standards might cost? The reality is that software is constructed to sufficiently satisfy business needs. That means both cost and performance. And every product has compromises. Even the ones with the best combinations of compromises are not necessarily the best selling or most profitable. Usually the products that have the best marketing and sales force behind them dominate their markets. Nimrod! Good luck finding Utopia. For more information, goto http://www.garagelogic.com/welcomingcommittee.htm.
For all the management out there to keep putting deadlines on things that can't be met. Think about it. If you fix something before it is released, you will save your self thousands techsupport phone calls per release! That saves money!
Clean code means cost savings!
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.
...humans are the ones developing it.
Once a means of expressing unambiguous software requirements to a computer is developed machines will do all of our "development".
Modern programming languages are merely a step in this direction.
I am very small, utmostly microscopic.
Is this your first day in the wide world of business. Good luck with this mission. I agree with you don't get me wrong but come on unless you don't care about turning a profit their is no incentive to put out quality work. I applaud everyone that takes the time to produce quality i really do but you people are few and far between.
***I GOT NUTHIN***
if you want truly beautiful software, you have to use truly beautiful process, expose the process, and help both purveyors and surveyors educate themselves to refine their aesthetic.
this article is itself ugly to me because (1) some weird-ass language example; (2) strange formatting that causes "?" to appear in unexpected places; (3) overfocus on the artifact. (feel free to disagree w/ my aesthetic.)
IMHO, admonishing people to write beautiful software is almost as much a waste of time as commenting on such endeavor.... :-/
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
>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!
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.
Seen a network tabloid like 20/20 or Dateline lately? Houses are built like crap. We should aspire to something better.
Anyway, here are the reasons why writing beautiful code at work doesn't happen:
Oh well, time to make more sausage.
I'll start writing code as beautiful as a bridge when management stops changing the requirements throughout the programming process. How many bridges do you think would look good and be stable if half way through the construction one person decided it needed three more lanes, another felt it should be double decked and yet another added the requirement that it be one way. Software sucks 90% of the time because the requirement specs suck. And no one every looks at a bridge that is 70% complete and says "This looks good enough for now, let's start using it and work out the kinks as we go" like they with software.
I agree, most code look horrible and is a terrible mess, but that is a side effect of external forces, not because programmers need to be inspired to write clean beautiful code by some article.
Even if they could see it, they wouldn't understand it. The general public wouldn't even be able to write software.
Software that -needs- to be as relaible as the golden gate bridge is. It runs medical equipment, aircraft control systems, etc. Your word processor is irrelevant.
Sorry but the comparison between a house and software doesn't really hold water. First off a house is a mostly static environment: floors, walls and ceilings just have to be, they don't have to respond. Software has to respond. Its in this response that problems arrise. I'm willing to bet that most code that turns out ugly started out pretty (I did say most not all) and it was when unforseen events occur that the software needed to react to, kludges and hacks were inserted to take care of them. Thus creating the ugliness. No one ever asked a wall to prevent a person from doing something stupid to it but everyone always expects software to do that very thing.
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'
...was an interesting one. Where I work we did a bit of research into the structural integrity of bridges-turns out more than half in the U.S. need major repairs, 3000 in Cali alone. And inspecting bridges is normally done visually-but nobody's done research on whether a person's eyes affect how well the bridge comes out in the inspection. So we do cross bridges like this every day, but like software we just don't know the quality is lacking.
I think it's just that every field is like this when it's done to earn a living. Maybe the difference between work and hobby is the hobby is where you can do things right, not just right now.
If I built a roof on somebody's house the way I write code...I'd still be doing time.
Bush is a cylon.
If you build a faulty bridge, people die.
If you write bad code, the user pushes button.
It may be a bit simplistic but it puts things into perspective.
Today's Dilbert in the local paper:
"Upper Management says profits are down because of the slow economy."
"So, when profits are up, it's because of good management. But when profits are down, it's because of a slow economy?"
"These meeting would go much faster if you wouldn't put things into perspective like that."
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
Try looking into "Extreme Programming" concepts.
www.extremeprogramming.org
www.xprogramming.com
----- LoboSoft specializes in Digital Language Lab
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
Those of you who scoff and say you don't have time to implement good software are shooting yourselves in the foot.
Where I work, we've developed a lot of code. We re-use as much as we can. And because a lot of our code isn't simple/elegant/pretty, it takes us more time to re-use that code than it should. It's still faster than rewriting the code but it's nowhere near as effective as it could be.
So earlier this year I began pushing for a major project to refactor and clean up this code. Already the initial stages of this project (implemented by several programmers on our staff) have yielded huge gains in how quickly we can develop stuff. As we continue to clean and simplify, these gains increase.
This is real-world. We have deadlines just as impossible as anyone else. We're doing this effort so that we can meet these deadlines on more and more projects.
If you ever plan on using that code again, write it clean. You'll thank yourself later.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
manager -> we need to ship this bridge in 3 months.
engineer -> yes, but it's really big and really important
manager -> yes, but it has to ship in 3 months.
engineer -> so how much weight does it need to support?
manager -> i dunno, I'll let you known in 2.9 months.
engineer -> what is it bridging?
manager -> why all these stupid questions, start building.
engineer -> I should do an architectural drawing first.
manager -> why bother, here's some metal, start slapping it together. Remember it ships in 2 months.
engineer -> I thought you said 3 months?
manager-> oh didn't I tell you, we heard a rumour that a competitor will be shipping their bridge in 2.5 months, so we have to beat them.
continue forever.
the reason there is no internal beauty is we (engineers) aren't given any time to build quality (although the argument could be made that the only way to build on schedule is by building quality). The other problem is, bugs actually translate into lucrative support contracts for most enterprise software vendors. Why improve quality? there is no revenue stream there. If users would SUE software development firms (the same way people would sue if a bridge fell when you drove on it) then vendors would suddenly find time in schedules for testing and quality.
we do the best we can, given the pressures. My advice, try to learn to say "no" to your manager once in a while, and hire a QA manager with balls who won't let shitty software ship.
To a Lisp hacker, XML is S-expressions in drag.
If people could see the construction of their houses without paint, paneling, dry wall, etc... getting in the way they'd crap themselves. If people could crawl underneath bridges and see the corrosion and bird shit they'd crap themselves also. Software is suppose to work and be outwardly pleasing. Nobody gives a flying fuck if the code is beutifull on the inside. Just as nobody gives a fuck if a fat person or thin person is beutifull on the inside. Anybody who compares software engineering to physical engineering needs to have their heads examined then set apon with a ball peen hammer.
Steve's Computer Service, Hobbs, NM
So let's extend this analogy just a little shall we? How many moving parts does a plain bridge have? What sorts of user interaction is there aside from walking on it?
If I had a program and all it did was add 2 to every number I gave it--well duh! There's the equivalent of a simple archway over a stream.
But what about vehicles, automobiles? Machinery? Robotics? You think those systems don't have specific limitations in them? You think if you drive the wrong way down a one-way street, it's the car's duty to turn you back around again? No--and in a head-on collision, the best a car can do is crumple and absorb the impact of your stupidity, or flatten the opposing vehicle. The car is then a write-off. Period. Yet it sounds to me like you expect software to bounce back and survive catastrophy.
If a bridge is built for x lbs of weight on it, and you dump 5x right in the middle, you think the bridge is going to be okay after that? But software should be able to. Ah. I see.
Large software systems are so completely different from real-world systems that comparing them is silly. (And is that Visual Basic I see there to try to prove your case with?)
That in the revision history that this is the 3rd version of this paper in almost 3 years?
So it takes him almost 3 years to write a 10 paragraph essay with some VB code mixed in, and he is telling us we need to do better? Nice example Mr. Author.
mp3's are only for those with bad memories
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.
Arguing by metaphor is not valid. Even so, no real evidence is given supporting the mataphor.
"Most software design is lousy." Evidence? Support? Oh, because the second paragraph describes ugly buildings in detail?
"Beautiful programs work better, cost less, match user needs, have fewer bugs, run faster, are easier to fix, and have a longer life span." Evidence? Support? Of those measures on "beautiful" versus "ugly" programs?
Reading constructs like "Just as a building should be..." pisses me off. We're talking about software. Give me measures of software, not buildings. That point doesn't even apply, since evidence is given for neither.
Gross.
If you are writing software to control the raising of a drawbridge, or flight control for an airplane, or a thousand other possiblities, then people can die too. There are critical pieces of software in todays world, just like there are critical (and not so critical) pieces of architecure
There is a chasm
of carbon and silicon
the software can't bridge.
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.
Sometimes, when you see some beatyfull software design, the tears start to fall.
I've certainly worked with software that made me want to cry, but not because it was well designed.
To steal from the Murray boys, if good code makes you cry, stay the hell away from anything on the Lifetime network. 'Cause you'll have to go on Zoloft to get over Steel Magnolias.
Pussy.
Your friend,
--Shoeboy
Comparing software to architecture is absurd. If an architect had to build something that would be able to float on water, work in sub-zero temperatures, be stable on quicksand, and be 5 miles tall, THEN they could compare it to software. Architects deal with knowns and constants. Software design has to be able to work in so many different scenarios, often some which preclude being able to do the "pretty" thing. It has to work in the end, it doesn't have to look beautiful on the inside.
The best design and architecture in the world still fails sometimes. People should be amazed at how much "ugly" design in software has been able to do, and do well.
--Alex
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
Don't blame the developers, blame the guys forcing timelines. The managers and the guys at the top of the monkey-tree doing the support, the analysts, and the pink-slip nervous bastards who breath down your neck in quiet harrassment ... they're guilty too. Bad design propagates down.
... it comes naturally.
A good carpenter never blames his tools. A good manager never blames his developers. A good developer doesn't give a flying fu^^ about design, because
Bit-wise and envied, with just enough cliché.
Guck
..right now I am *supposed* to sit tight and fix a boatload of old, ugly code, apparently written by a crack addict. I know how to make it nice, tight, fast and clean - but they would not let me. Old one passed some joke of a QA, and nobody wants to commit their ass into rewrite - in this times the universal question is "what if it fails and I get laid off".. Sucks. I hate every line I look at, and use every bug as an excuse to clean up part of it..
<^>_<(ô ô)>_<^>
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.
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.
No, you've improved the analogy. Lets take your first example: The wiring. Your theory is that I, as a users, shouldn't care if little thought or planning was given to doing the job since i "don't see it".
Of course, if when I go down to my fuse box I just see an unlabled rat's nest of wires I'm going to be mad at whoever did the (half-assed) job. Then let's say I decide to add a room. The new contractor comes to me and says, "Well, we can't figure out how the first guy wired everything so we're just going to add a second meter for the additional room and give it a completely independant system".
I'm going to be modded down for saying it, but it's true: most of the people I have worked with are NOT capable of writing elegant code. This is particularly true of Perl programmers... :-/ As long as it ends up working (for a while) they couldn't care less how much of a maintenance headache they are creating down the road.
Knowledge of algorithms and methodology does not translate into clean software systems directly. Knowledge of the system that is reflected in software does. I think a great deal of bad software design is due to the fact, that all that wizard CS professionals knew zilch about what they where writing about. I would better hire a good biologist/physicist, who know how to program (and many of them do, then a CS major, who can quote pro and cons of sorting algorithms and C++ constructs in his sleep, but does not know squat about what he is coding about.
Idealy, though, a good team is a mix of different skills.
<^>_<(ô ô)>_<^>
Dim Author as Idiot
Well, you've obviously never designed or written software.
I would agree that bricklaying is not art, but how about architecture? The bricklaying of programming is the actual typing.
I've expressed emotions in C++. Fuck, I've written outright poetry in perl.
To play devil's advocate:
What pretentious bullshit. Painting is NOT art. It can be closely compared to putting dots of color on a piece of paper, it is a CRAFT.
Try expressing an emotion with dots of color on paper. It cannot be done. Please think before repeating these banal opinions that painting is art. It just isn't. Deal with it, and if you want to be an artist, learn to hack perl.
yes it is art. When software is the result of some ones ideas , and it is loveingly put together it is art , and most probably very good.
When software is made by a team apporach , it is engineering , and although it may be edible , it cannot be great.
I have seen this over an over, just because software can be made as engineering doesnt make it great.
* Carthago Delenda Est *
... I think you're being a bit harsh. :)
My degree is in Mathematics with Computer Science Emphasis, which means I got a CS minor and took math classes mostly relating to CS-y subjects (e.g. Linear Algebra, Numerical Analysis.) I compare the code I write to that written by the CS majors in my classes, and I don't think it's any worse than theirs. Furthermore, my boss seems to think my software is just fine, since he pays me plenty of money to write it. And in fact, there are a lot of mathematical techniques underlying good software design which most CS majors don't seem to learn.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
I have never been hurt by software.
Nothing has facilitated the production of poorly designed software like the mouse has. When you sacrifice a single command prompt in favor of a GUI interface, you're declaring open season on your desktop. The marketroids are going to light up every pixel you have if even remotely possible. It's the difference between a tornado touching down on a little town's main street (read: command line) as opposed to touching down somewhere in Kansas (read: GUI).
Companies like RealNetworks and Microsoft don't give a damn if their software works as long as it drives people toward their services and content. And we can thank the Internet for that. Software to them is more about battling over the Windows registry to become the default viewer, the portal or home page. It's about getting the user to put the mouse in the proper coordinates and clicking away.
The author makes an important point about internal form and function following internal form and function.
IANAH (I am not a hacker), but I do have training and experience in developing programs and systems to meet my needs as an accountant. This is my tale of hell.
My company wanted to implement a new system to integrate accounting, reporting, and planning for sale and orders for our three main sites (in 3 countries). We're a capital goods manufacturer so each individual sales contract (not counting spare parts) is mostly likely unique. We hired an outside shop to put this together for us. I spent several weeks with the guy they brought in going over the "big picture" components of the system - what we need to the system to do, what the key data were, how they needed to be structured. Our discussion led pretty cleanly from first principles to a definition of tables, and a pretty complete set of functional requirements. I had a lot of fun finding the most compact, complete way to look at the information we needed. It was, dare I say, something I was really proud of, especially the data model.
Ahh, user-boy, I thought to myself, your work here is done. Time to kick back, turn it over to the pros and check back in for beta test.
Wrong.
Way wrong.
I kept getting questions. Lots of questions. Questions that indicated that, despite the many hours of conversation, the guy doing the coding did not understand the big picture and what he was being asked to deliver. (Now, partly, this is because the fscking consulting company had hired a guy whose background was grinding out Access databases to implement something that had an Oracle backend and an intranet-based front end.) However, I soon realized that the lead consultant did not have a clue what the hell she was talking about. We would explain why things needed to be structured a certain way, sometimes quite forcefully, and she'd wander off, implementing it some brain-damaged way, then come back to ask another question about a problem her "solution" had created. The underlying data model and table structure ceased to bear any resemblance to the concepts we had so carefully sketched out weeks earlier.
Overtime. Overbudget. Clueless. The consultants were out the door. We put someone internally on to the project, and, sure enough, the only way they can get a clean product is to go back and do what we said in the first place.
The point of all of this is that the consultants did not have a clue from first to last what they were doing. And it shows as a gawd-awful mess of broken tangled tables and useless spaghetti code.
At this point, a year late, we still don't have a working system. (I'm so frustrated I want to go out and learn Linux, MySQL, and Python and do the g*damn thing myself for my own intellectual and esthetic satisfaction. If anyone knows a good tutorial for MySQL, please lemme know....)
Beautiful code comes from grokking the end-user, not just the code.
Do not taunt Happy Fun Ball
I am ashamed of this guy's behavior; I have valid reasons for coding badly.
1. All coders including me are lazy, and would rather patch something together than do it right. And bloat doesn't matter, since people will just buy better hardware to compensate. So flush quality, I don't care.
2. Don't talk down to me man, I'm an engineer! Even if my Uncle John, a so-called REAL engineer who makes nuclear plants or something, says I should lose the use of the word "engineer" in my job title. Hey man, I graduated my correspondence course fair and square.
3. The computer industry is run by young people. We lack the hardened fontanelles and experience to be able to do good work and excercise restraint, discipline, or create any code above the mediocre level. But hey man, the people lap our shit up! Let the market decide if it's good enought.
4. If my employer (who makes a product you all know about) is willing to throw money and juggernaut stock options at me for meeting deadlines no matter what, who am I to give up my jackpot for stupid quality. Flush quality. what do I care.
Basically, it's all about making a load of ca$hola, and then retiring to the Bahamas at 30 while the rest of you at home can fix what I made. And you'd best be thankful, I don't have to care as much as I do. It's dog-eat-dog, and the best product rarely wins. That's why you linux guys are at 5% of the market. You take too long, and fool around making Atari Emulators. Bill has to prop you guys up as competition because you suck so bad. And nobody will believe Aple is competition, since Microsoft practically owns the company.
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
"Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty."
Somehow I have a gut-feeling that my boss thinks exactly the other way around, make it fast, make it work, give the customer what he wants !
The customer doesnt care about beauty, he wants to see something work as fast and as cheap as possible !
Life starts at the end of your comfort zone.
I know good design when I see it. I can produce good design. I practice good design in all my work.
/* leave room for null character */
/* don't forget empty string */
/* error; need to revisit this */
At the same time I must admit that good design is not good business. No, it does not take longer to come up and implement good design. The problem is most software engineers don't understand good design. They can't maintain it.
Bad programmers can write code that other bad programmers understand and can maintain. They are the majority of the department so smart managers are wary of the one or two good designers they have.
A tiny example:
int strlen(const char *s)
{
int n;
for (n = 0; *s++; n++) ;
return n;
}
#define MAX_STRING_LEN 101
int strlen(char s[MAX_STRING_LEN])
{
int i = 0,len;
if (s[i] == 0) {
return(0);
}
else {
len = 0;
while (s[i + 1] != 0) {
len++;
i++;
if (i == MAX_STRING_LEN) {
return(-1);
}
}
return(len + 1);
}
}
The former implementation is more beautiful, but not something most software engineers could come up with. The uglier implementation is something they would immediately feel at home in. A good manager should discourage the better design "which only PhD's could understand and maintain."
You could follow this
Guide to Writing Unmaintainable Code.
If we put this article in close proximity to Mr. Connell's, in a searing flash of heat and light they would negate each other in a matter/anti-matter like reaction.
"I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve."
There is an old saying that using good software is like eating good sausage:
Those who like it should *never* see it being made.
Yummmm!
(With apologies to vegetarians.)
I bet most bridge building engineers aren't told my their managers that it's not important whether the bridge will fall down and kill people, if it's just done by next Friday!
True, most software sucks, but it's usually not the fault of the coders...
May we live long and die out
If architects were to build like software engineers do, a lonely woodpecker could instantly destory a metropolis.
Code poet, espresso fiend, starter upper.
It's not that hard to write good code. It is hard to get managers to value good code. I've never been a programmer on a project in which I was not directed by the project leader to develop the code in the quickest possible way and without takihng time to create documentation.
There's (usually) no guarantee that *you* are going to be the one maintaining the code in the future
;-)
I thought that was the point of writing sloppy code in the first place!
Job Security: it's a wonderful thing
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
Sheesh, another academic preaching about how all commercial software sucks and how we should spend more money to produce higher quality software.
Guess what, more people and more tools and more training and more time means that the shoot-em-up-game you just bought costs $350. Would you pay that for a perfectly stable game? Or would you buy it at $50, enjoy the game, bitch and moan about the occasional crashes and hope that they release a set of patches?
Quality is expensive. I think everyone would agree that a BMW or Mercedes is better engineered and higher quality than a Lada but very few people can or want to pay the extra money for a BMW. What makes you think that decisions about software would be any different. People want software to get them from A to B cheaply. Plus, software quality is not a status symbol.
I'll also address your bridge analogy. Imagine if an engineer was asked to develop a bridge in the half the time, half the people, half the budget and half the steel. Could they guarantee that it would last 5 years? Would they consider it ethical to build it? These constraints (usually much worse) are the limits that commerical software developers face everyday. They one advantage that we have is that most commercial software does not mean the difference between life and death. When it fails it is usually an annoyance.
Get real,
Jason.
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.
While I agree with this essay, I can't help but feel a strong sense of deja-vu. This sounds alot like the original Unix philosophy, one that has to large extent been ingnored by the contemporty computer industry. Instead of building quality systems, the focus is more on presentation (i.e. Apple) or market share leverage (Microsoft). Even modern Unix variants, including Linux, have fallen prey to the false god of excessive ornamentation.
I'm glad this view has gotten some amount of attention, but I'm pessimistic about any prospects of change. The processes and attitudes are to ingrained in our technical culture.
I work mainly with Flash 5 ActionScript applied to web applications, and while that certainly *isn't* a real programming language, it is complex enough that issues of code cleanliness definitely arise. However, with website development budgets and deliverable deadlines getting tighter and tighter, the time it takes to really go through and optimize and comment your code sometimes just doesn't exist--or isn't budgeted for by the client. While that is no excuse in itself for ugly "Fruit Loop" code (a competent programmer shouldn't be doing that stuff anyways), sometimes the unfortunate reality seems to be that time and budget constraints force programmers to "just get it done". In a perfect world, we'd be able to get paid to take the time to perfect our applications, but in the real world, that's often just a fantasy, IMHO.
If you are like me, and you work in a large corporation, where you cannot attract truly good programmers because your projects aren't interesting, then you are stuck hiring bottom of the barrel, "Learn Java in 6 weeks!" hacks that don't know jack about writing software. I have to deal with developers who blame everything but their own code whenever there is an application problem. Every time, we have to go through our servers to prove that nothing is wrong with them, when everybody knows that the code sucks ass. 90% of these people have no idea how to even use a debugger. It almost makes me want to go back into development, but I don't know if I could stand working with the others. My suggestion is that we get legislation in place to require licensing exams for software engineers.
There is usually a tradeoff between quality and expediancy.
/., but think about it... how many really decent operating systems and applications have the users experienced? As long as expectations of quality are low other factors (cost, ship date) will take precedence.
I agree entirely - but I don't think it's fair to lay this completely at the feet of management. IMHO there are a couple of major drivers here:
1) Users are used to shitty software. I know it's becoming gauche to rag on MS here at
2) There's no liability for software publishers. Just look at your average shrink-wrap agreement - would you buy a house or a car or a bridge if you had to agree that total failure of same was just tough titty for you, and the manufacturer had no liability? Of course not.
I think the industry (software) is still too young to have worked out all the bugs - er, so to speak. I wouldn't be surprised to see some sort of certification or licensing come about for programmers, after a time. It's just a matter of how many people wind up dead due to fault software.
Software has to:
1. Meet user requirements.
2. Meet user requirements (in 10 years).
If your business plan includes any kind of long-term component, you know that initial sales are only a small portion of your revenue stream. If you write software for retail sale, the long term comes in the form of selling subsequent versions of your product. If you develop directly for large clients, it usually comes in the form of explicit code maintainance contracts. This is doubly true because most software has relatively few users for the initial release, and only gains widespread adoption with time.
Either way, you're in it for the long haul. The known user requirements are not the end-point of your development effort, but rather the first of many waypoints. Maintainability and extensibility are everything: If you can't correct the bugs in version 1.0 and get version 2 out the door (both in a timely and cost-effective manner) you're not going to be selling much software. That's why an elegant design is worth the extra initial cost.
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
I look forwards to the general public gaining an appreciation of good code. Much of the discussion so far seems to revolve around how software is not hardware and how much harder it is than physical engineering. No comment on this issue.
The point for me is that the general programming community (I) need to successfully explain to the general public (my mum) why some code is beautiful and other code is not. Until then the public will not pay more for good code than bad code. I am failing miserably so far.
Please remember that the general public is still shaky on the concept of resizing windows and scrolling webpages. Spellchecking is a non-trivial exercize rather than F7 (or whatever).
Ugly hard to use programs have been rightly discarded, so there is a basic appreciation of UI design. So there is hope, however don't forget that most apps are a commodity product and so the cheapest tin of beans will sell the most, since the contents will be very similar.
In the same way that in the renaissance noble families supported the old masters, some corporations keep the more distinguished names in our field, so beauty is preserved in odd corners.
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.
Machine Beauty is a book by David Gelernter that gives an excellent exposition of why beauty in technology is a good thing. I recommend it to anyone who wants a deeper understanding of the issues.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
It's interesting that a person who writes about bad software design will create the HTML using Microsoft Frontpage, which apparently doesn't even know how to generate a bulleted list properly...
I the crawl space under my floor is unusable, the drain system outside is also inadequate, and the wiring is not very usable. I cannot run a simple network cable from my place to a neighbors - that to me is just as bad as any poorly named variable.
The fact is we do live in poorly designed stuff. Just like you don't need to be a good designer to code, property developers don't need to be good architects to throw together a development.
I disagree with the whole idea that IT is worse than other professions. Look at the mess lawyers/governments make with the law. Give me a poorly designed goto any day!
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.
Where did this go:
2 31 &mode=thread&threshold=-1
http://slashdot.org/article.pl?sid=01/09/03/201
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.
The get-anything-out-now mentality alluded to by a number of posters is certainly one of the worst things that came out of the dot-com boom (yeah, it was there before, but not at that level).
Does anyone ever worry about maintenance anymore?
I manage a small development team working on commercial software. Yes, its important for us to get software out quickly. But thats one of the reasons that we insist on good quality, clean and readable code.
We leverage off our existing code base for each new iteration; some of the code has been in use for years (though now used in ways we never expected of course). If we didn't take the time earlier to make that code cleaner, we'd be paying the price everytime we go back and have to work on that code again, whether to just fix bugs, extend it to do something new, integrate it with a new package, etc. This is true both for the original programmers who wrote the stuff, other people on the team who have to wade into it, or new people we bring on board.
I've done things the no-documentation, make-it-work, anything-goes approach before, and I know I'm never going back that way again, for anything more than hacked together demos. I expect everyone on my team (myself definitely included) to write clean, well-documented and understandable code, following our coding conventions. Everyone gets flak from everyone else when this doesn't happen (its quickly corrected). Sure, sometimes it doesn't happen in the very first cut on a tight deadline, but you can bet cleanup is the next thing that happens in the schedule.
What the author of this article doesn't realize is that many houses *are* ugly hacks, just not where you can see. The doors are pretty, the walls are painted, but the roof is leaky and the wiring is substandard. Just because houses look good doesn't mean they are defect free; there are probably dozens of cut corners and screwups in the walls and floors that will never be noticed, in addition to the few that will be.
Software is the same way. As long as the internal structures and building methods are hidden from the user, and as long as not too many things break, the user will be happy.
First, I think beauty is the wrong word to use. A bridge (or any other engineering project) can be beautiful without being terribly useful or reliable. I think we should be striving for high quality software. What is a simple way of writing more high quality software you ask? Stop using C, C++, or Java. Start using ML, Haskell, or Clean. Modern functional programming languages offer:
... An Experiment in Software Prototyping Productivity" and "Four-fold Increase in Productivity and Quality" for respectively an academic and industrial look at the productivity increase offered by functional languages.
1. Immutable objects
2. Higher order functions
3. Strong static type systems
4. No pointers
5. Garbage collected memory allocation system
All of these add up to shorter, much more reliable code. I know there are some people out there who will protest that any garbage collected language will be slow. This is simply false. Thanks to strong static typing and a formal semantic that permits easy reasoning about optimizations, ML family language compilers produce code that is almost always faster than Java code and quite possibly faster than C code that has not been hand optimized. For those who are interested take a look at "Haskell vs. Ada Vs. C++ vs. Awk vs.
The one area of computing that most functional languages are not particularly well suited for is low level system programming. However, there are researchers working on that, and how many of us do low level system programming?
Cheers,
Benjamin
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'm doing my part to try and improve things, and finding that nobody cares enough to help. Personally, I dont release jack squat until I can confirm to the best of my ability to test it that my code is clean, and solid. People who release anything less are either lazy or wreckless, IMHO.
So whats your excuse?
Cheers,
Bowie J. Poag
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
Then you really need to go watch some new construction happening. When the painters recover from thier shellac-induced highs they toss enough of it down to hide the shoddy carpentery. That nice marble seat in your tub? Held up by scraps of ceramic tile and a couple of pounds of mastic. This is caused by a simple fact : _Unions make people lazy._ The reason software is less than elegant in many cases is due to the urgency placed on developers for rapid development.
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.
>> programmers in XP projects are capable of writing ugly software.
> Yes, and XP works anyway.
hmm..
yes it does, no it doesnt. Yes it does, no it doesnt. Yes it does, no it doesnt. Yes it does, no it doesnt...
As a former C++ coder who is now suffering in that terrible hell known as "Microsoft Visual Interdev", I have to say that writing Visual Basic shouldn't be considered programming.
Vor sowe good examples how NOT to mrite your programs, check this site: IOCCC
badness 10000
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.
People are always bragging about what a hack job their code is, or how messy or dirty it is, but it works so that's the important thing. It becomes a joke.
:]
Personally I blame it on hungarian notation.
My code's beautiful. Everything I write is gorgeous.
-J5K
The libertarian solution to the failures of capitalism is to apply more capitalism til the failures are fixed.
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.
So what are my real choices? Either I can hold out and write software that doesn't suck and give up tens of thousands of dollars, or I get the damn thing into beta on time.
If I want to write great code then I work on my sourceforge project. If you want corporate code to be elegant then go bitch at the managers who tell us "You guys always pad your estimates too much. Instead of December I'm going to put you down for the end of September".
You present an interesting example of bad design: MySQL. When database people dismiss MySQL, that's because the transactionless design of MySQL, besides putting your information at risk, betrays even the SQL name.
But that's not all. SQL in itself is a mistake, a contamination of the relational model. This is not the place to explain the relational model for database management, its conceptual and practical relevance, but you can find something more at http://dbdebunk.com./
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
Genu the key,Isnt ? just search Genu into google.
Having mixed-case tags is completely irrelevant to the PERFORMANCE of the website. It's a non-issue when writing the HTML code, it's a non-issue when transferring the document over the wire, it's a non-issue when the browser renders the document (unless the browser validates with XHTML 1.0 Strict). The important issue is not how nice the code looks to your eyeball; it's how nicely the code WORKS.
(Please note that I am talking solely about markup languages like HTML; my comments may not be applicable if you extrapolate them to cover programming languages,)
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
I posted almost the same thing as an AC by mistake, so here it goes again.
Case in point: MySQL. When database people dismiss MySQL, that's because the transactionless design of MySQL, besides putting your information at risk, betrays even the SQL name.
But that's not all. SQL in itself is a mistake, a contamination of the relational model. This is not the place to explain the relational model for database management, its conceptual and practical relevance, but you can find something more at http://dbdebunk.com./
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
This can be true, but certainly isn't often the case. To optimize code for speed often involves contortions that do not clarify the code or make it simpler or easier to read.
The real trick is making it fast and readable. :-)
I'm an old school engineer (chemical to be exact) and to me, there is one thing that defines for me what an engineer does: have a sense of social responsibility. Doctors and lawyers are responsible only to their respective clients. Engineers are the only professionals who are responsible to society as a whole.
Software engineering does neither. Nothing makes my skin crawl more than a MCSE calling themselves an engineer, in Canada we finally made that illegal. I make a mistake, and there is a big smoking crater and lots of dead people. I take that incredibly seriously. A software engineer makes a mistke, BSOD big deal!
(Nothing critical to facility safety, in my experience, is controlled by software. It's all mechanical safety devices or discrete logic.)
Computer science I can accept as an science. But software engineering has no sense of responsibility to the end user, let alone the greater good.
Laugh while you can, monkey boy!
If you are making a bridge, you are given specs for it, you design it, you build it, and you occasionally maintain it. However, once its built its done. With software you make an incredible design for your first specs. Then your asked to add features, maybe change some functionality. It becomes add-on after add-on. And if you need to make changes to a bridge, you don't tear it down, you just build over it. Well, with software, if you equate it to a bridge, you've taken a wooden-covered bridge and you turn it into the Golden Gate, with some cool pillars, maybe a dock, and some weird crane thing on the side that no one knows what it does but its left there "just in case." Quick dirty summary: SOFTWARE EVOLVES TOO FAST TO BE PRETTY
- gtaluvit (prnc. GOT-tuh-LUV-it)
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.
The U.S. workforce is still 90+ percent male in software and network design.
Women think differently then men. According to some scientists they have more serotonin transmitters so some think they are smarter then men but do not quote me on this, verify it elsewhere ...
I attended FreeBSDCon '99 in Berkeley and nowhere since then have I seen such a disproportionate ratio of women to men versus the average population (women at 50+ percent?). I think there were five women at the convention with hundreds in attendance.
These numbers are highly indicative of either a great reluctance on women's part to get into software design because it doesn't work the way they think or men who discriminate/harass them, or both. I'm tired of it and I don't think I'm alone.
A simple visual object-oriented programming language (successor to LOGO?) and a top notch GUI for Linux could ease this needed transition. Maybe a proportionate group of men and women working together cooperatively will develop this.
--ftide
Fight Spammers!
What about standardization?
Whoever wrote this obviously has never seen how badly houses can be built. How many times have you seen major disasters where everyone asks how did that building ever be allowed to be built. Engineering these days is a task on building something that will do the job for the least amount of money. No-one ever gives you the budget to improve a working section of code.
G
... is a must for all software engineers.
... or does anyone else find it is funny that the article discusses software aesthetics using Visual Basic code examples ...
> 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
Contractors, builders, city planners, etc. have the ability to pick the environment in which they build. Before a building permit is issued, studies are (usually) completed to make sure that the environment is sound and will support the proposed building.
This is a far cry better than the foundation upon which software engineers build. The foundation that has been laid and cannot be changed is usually the underlying operating system. Without being able to change an extremely shaky foundation, an extremely shaky "building" is the result.
This becomes even worse when all of the "building codes" are defined by the provider of the OS, but not all of these "codes" are published for the engineer to build from. No wonder the "building" software engineers create is so shabby! Give a contractor a rocky, uneven field with a stream running through it, don't tell him all of the building codes, make him and his workers build without breaking the ground (the environment in which the building is built) and make him work in the dark at least half of the time, and then we are approaching the conditions that M$ has given software engineers.
.sig wanted. Inquire within.
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?
I know the man is brilliant, but in my opinion his code samples are CRAP. I know this will get moderated as flame bait, but it comes from the heart. One letter variable names should be OUTLAWED from languages. I don't know how many times I've had to wipe up the shit that someone left because they didn't take the time to think up better variable names. Second to this is variable names are that are sequenced. For example: a1, a2, a3.
No doubt this will generate a lot of heat, but I know there has to be others who feel the same way.
Building a dwelling is much more like your average software project. ;)
1) It has multiple subsystems. In a house, there is the roof, the walls, the electricity, ventilation, plumbing, the foundation etc. In most decent sized projects well, there are also many subsystems (database I/O, display widgets, parser, interpreter etc).
2) Some subsystems are more critical than other subsystems. Most people are much more critical about the structural integrity of the house and then probably the plumbing/electrical, than they are about, say ventilation, or nicely placed windows.
3) Look at the life cycle of most condominiums to see what "good enough" construction and design looks like. "Good enough" in condo construction means that the owners don't sue for about eight years (long enough for the original builder to duck financial liability
Have a NICE day.
I may look like an idiot by saying that but dude I can't write in VB, it's too weird for me to understand.
and a lot of science to both. I DO both, and I don't see any intrinsic difference. You start out with a problem, and you wish to create as elegant, straightforward, and cost-effective a solution as possible. There artistic flairs that can be applied to either, but both are scientific arts.
If you do not see similar art in engineering, you aren't looking hard enough.
+5:offtopic,but anti-American
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.
It is easy to see why software has evolved the way it has. Originally bridges were just logs over the river, they have gotten better because people fell off the logs and died. Life or death situations tend to sharpen the skills of prosepctive designers quickly.
Military software doesn't have the same problems as M$ software. Because most military software has been designed with the "life or death" benchmark firmly in mind. Commercial software will never approach the design standards of bridges and buildings, simply beacuse no one will ever look at a subroutine and wonder, "will someone die if I don't re-code that goto?"
I thought that Slashdot was against censorship.
is also a must.
"Stop whining!" - Arnold, as Mr. Kimble
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
Now, we (software developers) are notoriously bad at finding out what the customer wants and then implementing it correctly - with that I'll agree. But I really do think that there has been progress in this arena...
I do everything the voices in my head tell me to...
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.
If bridges are so all fired wonderful, why do I have to creep along at 2 mph every day when I cross the bridge going home. If the bridge was so wonderfully designed, traffic shouldn't back up. And sometimes the traffic across the bridge stops completely. It's as frustrating as if my computer just locked and it takes 2 hours for it to reboot.
... when it locks up it just takes a couple of minutes to clear things up!!!!
They should build bridges like they write software
However wrote this article either doesn't use many bridges (at least not around here) or doesn't know how good the software is.
Software aesthetics? Just look at the crappy HTML-code of this article:
<p class="DefaultText" style="text-indent: 0.5in; line-height: 150%; margin-left: 0in">
<span style="font-family:Wingdings">?<span style="font:7.0pt "Times New Roman"">
</span></span>Cooperation</p>
What should be a <ul> is emulated with CSS and windings 8-bit characters (bullets, I suppose - they don't display on my system, because I'm not using windows!). A Frontpage-Consultant confesses his secret love for goto's and teaches us software-aesthetics using VB-examples. Strange times.
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...
Code does in fact need to be "pretty". But what means "pretty" for code is different than for something else. Good code needs to be maintainable, because it is almost inevitably: an integral part of a larger whole, and going to be changed in the future.
If a car manufacturer upgraded your car's engine every year, they would probably go to greater lengths to make sure that it fit in such a way that they could easily remove the existing engine, then replace it with the new one.
The way code is *VERY* similar to the auto industry as you mention, is that extreme care is required to make each part not "pretty" but "properly". Every part has to meet strict requirements and tolerances. This is where the analogy begins to show differences.
For the most part, pieces of cars are very carefully designed very smooth operating pieces of machinery. The bearings that let the wheels turn were designed with great care, and the people designing the bearings were probably very careful to talk to the people designing the wheels to make sure that either part would do exactly what they needed, and work together well.
Two interfacing routines in code often do not have the same characteristics. A large number of programmers in today's field either: don't care or don't know how to make good code. I've been pained watching my coworkers code in the past, replaced existing routines with amazingly smaller and more efficient pieces, cringed as I watch "computer experts" just mash the arrow key and wait to be at the beginning of the line instead of just pressing "home".
I think pretty is a very subjective word. Things will be pretty only from the right perspective. I believe the right eye can look at a house's wiring in the same way another would look at fine art in a museum. I've seen a lot of machines that nearly took my breath away, just because they accomplished their task so elegantly and cleanly. I've rarely seen code that did the same (in the workplace).
Health is simply dying at the slowest rate possible.
This is soo true. I believe that a major reason software continues to be disturbingly buggy is the lack of a quality control standard. If something is wrong with your house you have a contracter come look at it, if he finds that your walls were insulated with used coffee cups from McDonalds (found one of these in my wall) you nail the builder; there may even be legal options available to you. Same thing with a car or furniture. Average user may only notice that his door makes a noise, but the mechanic will notice that the manufacturer neglected a couple bolts. Very few people are going to find someone to crack open their source code to look for the origin of a problem when they notice a bug. In fact we are so far from a quality control standard that most people won't even report an obvious bug. Problematic software is the accepted norm. Also, going back to the car analogy, most software is essentially a car with it's hood welded shut since so little is open-source.
ôó
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 :)
maybe your house is going to fall over but mine is strong as steel. Mindstorm steel that is. course its only 5x4x6 but hey those are the breaks for stability.
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
A reason perhaps that designers do not open source their (closed source) projects after they've gone past their intended usefulness, is that their code was done terribly messy and they gain no benefit from going back and cleaning it up - and releasing this 'embarrasing' code may potentially harm future sales (No one wants to hire you after they've reviewed your past projects and seen how poorly they're written).
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,
oh come now... in most cases software doesn't last long enough for it to be designed like something that does. technology moves too quickly for any company to invest time into writing perfect code. all these people who write about extreme software quality are the same people who get fired for making a project run late, very late. i don't know how many projects that i have been involved in, in one way or another, that were killed by the people who come in and say "let's design (and redesign) the whole thing to make it perfect, maybe we can even use the latest whiz-bang methodology i read about in the latest software engineering book". i still deal with people who get upset if something isn't perfectly designed documented and critiqued by a committee. maybe this kind of thing will make sense in the future when Moore's Law is repealed and there's a static technology base on which to engineer something that will last decades. but that senario is not within anyone's lifetimes.
right now its all about time to market. microsoft knows this and profits by it. few other companies do hence they fail.
I work a bit with TI-92 assembler, and you haven't seen ugly until you've seen this baby.
I think you should spend a little time fixing a bridge or remodelling a house before you hold them up as examples
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.
For XPLC, I do this "internals should look good" thing.
There are some functions and code fragments that I re-wrote a number of times because they didn't have the right aesthetics to my eye.
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.
Him and Stallman must be good buddies.
IBM's Jalapeno JVM is written in Java..
You kill me
I saw nothing to disagree with.
And that's really quite rare.
Good houses often look like ropey software:
(Yes, of course I'm talking about an English country house. Software is complex and doesn't correspond to a two-up, two-down.)
A good house got that way to serve the needs of the people who live in it. Not to satisfy the desires of the latest school of architectural thought. I always remember a TV program on a house designed by a minimalist architect. It looked like utter hell to live in; very aesthetically pleasing, though. Tom Wolfe's From Bauhaus to Our House is a pretty amusing read on what happens when aesthetic theory gets hold of the steering wheel.
I like good software aesthetics. And there's a lot of advantages to having a good, well structured design that can accomodate the vagaries of user needs gracefully. But, ultimately, the aim is to provide something that is comfortable and natural to a user. The result is often going to look organic and messy.
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.
>> 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.
These lines have been so overused they are beginning to sound a tad trite. The fact remains, if the principles of engineering as applied to software, without the inadequacies of the development systems we get saddled with, software would be as robust as the bridge or the house.
It is poor management, insufficient development time, impatient customers, and crappy infrastructure which are to blame for a large number of the wrecks out there. I have met and worked with many talented engineers who are given the same sort of commands Scotty got on the Enterprise; "Make it happen yesterday!" is the motto of our time, instead of make it happen right.
Try just figuring out the exceptions to logic in the latest version of MSVC. Ad hoc operating systems aside, engineering anything usefull with the tools at hand can be quite an arduous and unnescessary adventure.
Software engineers make an easy target, since what they must product takes more time then all other segments of a project. But you have to ask youself: Why does it take so long?
The answer: When hardware engineers design a chip, whenever the come to a flaw in their design, instead of forcing a reexamination of the specification, they call it a feature and so the Software people have to work around that pothole. In addition, marketting wants a little more bang for the buck, so they want the software crew to slam in a new feature better done in hardware, but "oh, it can't wait for the next spin" Charlie wants it done in software now!
Needless to say, poor communication in the analysis phase, poor modelling in the design phase and poor execution in the coding phase (read: programming is designing while coding, instead of designing before coding), result in a Frankenstein monster with more features than a Japanese microwave and twice as many bugs.
If the managers could get off their cans an ensure these phases are followed AND supported, then the product would come out of the house rubust, usefull, and on-time (by realistic human standards).
NOTE: There are 1278 bridges in California alone, which have failed federal safety guidelines and are in need of urgent repair. Have you seen the way they have been building houses lately?
Grumble, grumble, grumble...
...now where is that coffee machine again?...
Fast machines, powerfull AI, impulsive invention,... All I lack is a good espresso machine!
Last year I was talking with some high-ups in Boeing (VPs perhaps, I forget) about the need for licensing software engineers as Texas had recently begun doing, wondering what they thought of that move.
While they agreed that there was need for accountability for software engineers (IIRC, these guys were planning YA-air traffic control network) their argument against licensing was that there were no defacto accepted standards for code. That is, it's obvious to license a structural engineer - there are building, seismic, etc. codes to adhere to that have been written down.
Software has no such animals. No state (these are all state labor board issues) has ever written down that you should free a memory block after you're done with it, or check a pointer to see if it's null, and so on. Sure, these are accepted practices, but they aren't requirements.
As to previous posters that suggest that buildings are chaotically built, they seem to be overlooking tiers of state and local building codes, building permits, inspectors, plus the need for contractors to be licensed in most states. There's a lot of checking and balancing to be done and if it's wrong... Well, in the case of buildings that engineers need to sign off on (3 stories and up + special purpose, in most states) structural failure can result in criminal malpractice suits and jail time. If people die and the engineer overlooked something, possibly manslaughter.
Next time you are writing code, consider how you would approach the project and your boss if the prospect existed of the code causing bodily harm and you could be sent to jail? What if your code is used to control a traffic light, a power grid, an anti-lock brake system, an EKG display?
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....
But it is engineering already. Engineering is making of useful things by applying science, if appropriate science exists, or hacking (trial and error) until we build the thing we need.
You should read some books on engineering (for example To Engineer is Human by Petroski).
Someone described the difference between science and engineering by saying: "A scientists discovers what is, an engineer builds what never was".
...richie - It is a good day to code.
I fully agree with the point of this article. Being a programmer, myself, I sometimes find little "hints" into the operation of commercial software. Some of the most disappointing were applications written in "C" that the programmer used a "Bubble Sort" or other proportional to N^2 algorithm for sorting records. Never mind that "qsort()" is included in the standard 'C' libraries! Let me not even talk about Windows, with its unspeakable API's and grotesque inefficiencies. Some of which is so bad that I could program applications in assembly language faster than I could develop them to run under Windows.
I am actually "getting out" of the IT industry, because I'm just plain frustrated. You can say that I can work with Linux or other alternative platforms, but the problem is the "accepted standards". Let's face it, most large companies have not gone to alternative operating systems for fear of "support"...never mind that these alternatives are far superior to the garbage turned out most commercial software firms.
Some of the very old 8-bit computers had usable (and powerful) word-processors, spreadsheets and even development environments. They ran at 1-7 MHz. Our 1.2 GHz computers are choking on today's software! What is the problem! That PC in your home would have passes as a super-computer not that many years back. Most of what we are dealing with today is:
This last item would clean up a lot of the filth that clogs our hard drives. Can you imagine if Microsoft could be held responsible for the buffer overflows that worms like Code Red I and II take advantage of? Was it my imagination, or was this about the 50th one that was announced by various security organizations?
We need to get back to the basics, and re-evaluate both the operating system platforms and the software design. People may scream that they would have to buy all new software for a radically different OS...But doesn't Microsoft force us into this already? We had to buy all new when 95 came out. A lot of things start to break as you go from 95 to 98 to Me to 2000 Pro. It's time to trash it and start fresh. And get back to basic, functional applications.
Ever notice that cars seem to be holding up a lot longer these days. There is no fundamental change in their design, just a lot of attention to minor details. In order to do this, ever notice how little cars change these days? A Ford Taurus is pretty much the same deal as what they introduced back in 1986 apart from a multi-valve engine that is an expensive option.
If Microsoft could stick with Windows 98 for 15 years, they may be able to make that reliable too.
s/Extreme Programming/Design Patterns/ or any other modern software practice and it makes just as much sense.
You can't prevent programming from sucking because it's a mess from ground up. The good programmer knows the mess and deals with it. That's about it.
PL design is my personal interest. I challenge anybody out there to show me a decent PL that's being widely used! Our systems are all flawed. C and C++ are not things that let you build beautiful structures. Any code beyond some scale written in these languages and on current systems will suck, especially if you get clueless programmers in the mix. (And I'm not saying that a _good_ language exists. Screw python,perl,java,... [and the list goes on] )
Ah, and to those who claim that the mess can be elegant: NO WAY. 95% of all code on my GNU/Linux system is NOT elegant. No C code can ever be elegant as long as it is not the implementation of a simple sorting algorithm. Forget the language, everything is a mess. Our build/config systems are total kludgery. The UNIX *is* the biggest heap of junk, and what are we talking about? I'm not even talking about the 'doze side. This side is heaven compared to that hole of stupidity.
That's what programming is like.
It's got so little to do with physical construction. In the software world, what we build is logical, and it *is* complex. Humans are not smart enough to handle that much of complexity, and here we are.
My point, though, is that even if we honestly wanted to build very good software it wouldn't be possible. You just need talented, smart and experienced programmers, and that's something you don't have. You can't just teach good programming like you can teach a simpler profession. It's sort of an expertise, like being a heart surgeon.
--exa--
Or at least that's the attitude you'll get from some managements. They'd rather ship something barely workable and pay as little as possible in order to maximize their profits.
Who loses? The consumer. Mostly becuase they don't know the difference between good software and bad software. I don't think Consumer Reports tests software the same way they test cars, for instance. One day, they'll figure out how to do so, and we'll see reliability ratings for different software packages.
The day they start doing so, I guarantee you, software quality will improve. Companies listen to nothing and I mean NOTHING like declining revenues tied directly to product quality.
Or maybe, just maybe, software quality doesn't matter to the consumer?
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.
CowboyNeal isn't pretty. -Jason of the 4th dimension (that means I'm stoned).
Ok, I've been browzing threw a lot of these threads. And some of them comment a little bit about WinCE devices. I was once an Visor DLX owner. And I got a ton of modules for it. Total cost after buying the Visor and mods. (software no on really buys, they just find the cracked versions) The total was about $800. Then after realizing that the batteries (rechargables) started to last less and less I began to think. Why do i have this. what am i using it for. to play games, to transmit files, and to have a programmable remote. (I did use it for other things, but those are just examples) I was then thinking about just buying a Laptop. then I could just bring whatever I wanted where ever. Unfortunatly the cost was to high. Then I looked at a friend of mines Jornada.(actually a fellow worker) when He wasn't playing around w/ it I was. At 1st I admit it was a little confusing and was a little slow. but yeah, now I find out thats basicly because its a jornada. (the worse pocketpcs out there. Like an m100 is in the palm series. only one work. Yuck) but i got to basicly see how the operating system worked and played around w/ its features. I desided to look more in depth at what pocket pcs were all about (I work in a computer store so i have the luxury of trying these things out a lot) I came to the conclusion that I would but an Ipaq 3635. the reasons. number one. because its color. I was really getting sick of the grayscale ness of the visor dx. I wasn't about to spend $450 for the prism. When i got my ipaq for $440 again because of where I work. I think i would've only payed $380 or $390 for the prism. but seriously only $50 more and the improvement is a lot. you prism guys are proboly thinking. the prism is 16bit color where as the ipaq is only 12bit. the prism is better. unfortunatly there is no palmOS program that really uses all 16bits. So your 16bit Prism picture or game is going so show the same on the ipaq. the ipaq screen is also much much brighter then the prisms screen. the ipaq's cpu is a 16bit chip so in theory you could replace the screen, but im not going to risk that. next reason why i upgraded was because of the batteries. I was sick of the AAA batteries. even though i did have 6 rechargeable. they were only lasting for 2 days when i was running the visor. and about 1 - 2 weeks when i would just leave it off. w/ the ipaq with the screen light not on, it will easily last for 12 hours. when the screen light is on about 6-10 hours. this also will varry depending on what programs ur using and how much power they take. Turjah Episode II takes a lot of battery power. BTW. It takes 15-20 mins to fully recharge the Lithium Ion Battery in the Ipaq. With The PC Expantion card the Ipaq will last for 20 hours w/out having to recharge very easily. There is an external LIon battery also in the pc expantion card which will also recharge. Third reason, syncing is automatic. From the time I change something im writing on my paper to the time its on my Ipaq it takes 2 seconds and because i have officeXP it automaticly saves to whatever time i have it set to. thats for my excel, word, powerpoint, and outlook (calender/contacts/tasks/notes). Also with my ipaq I can send palmOS programs to anypalm device(peacemaker, came as part of the software package with the ipaq3635). But as far as i know WinCE will not recieve unless it is copied from another windows device/pc. I can send as well as recieve contacts, notes, and calender information. BeamWorks(palmOS) is an example program that can do that. the 4th reasons can basicly be found on this website.www.goipaq.com not only can i hook up a solarpanel to it and use the suns rays to power/recharge it. but i can but 2 5gig pcmcia cards in a duel pcmcia card expantion to make a total of about 10gigs of hd space. in the palm of your hand that is a lot of space. i can easily take out one of the 5 gig cards to leave 5 gigs still and have wireless internet or wireless LAN and use a broudband or even just a simply 56k connection to browze the internet anywhere in my house/ outside on my deck. and becuase i can put a keyboard and still keep the expantion slots i could do even more. on the ipaq you can change the os from Windows CE to a bottom down version of Linux. this bottom down version of linux is usb compadible. so there for, w/ a pcmcia card -> 2 usb adapter then 2 usb 4 port hubs you could have a lot of other devices, but if ur doing that much thats when u just goto the laptop. The next version of windows CE (4.0) is to have better USB and Firewire support. It is supported now. It's just a little tricky to use. Because there is also a pcmcia -> 2 firewire. as well as PCmcia -> VGA. and everything. I will proboly be posting more about these kinds of stuff on my website. www.kevintm.com .
wow that was long. and only took 20 mins to write.
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)
Whiney-assed users.
Remember when you looked on in awe the first time you saw someone code
10 PRINT "HELLO!"
20 GOTO 10
Many times you would go to the store and see this endless loop running on a vic20 or c64 but you knew how to stop it via CTL-C and replace the HELLO with your own name. (or "ATARI RULES" if you were an commodore hater)
You're Just Jealous Because The Voices Are Talking To Me.
If I had a dime for every time a misguided marketing type confused a research demo or proof of concept written (heaven forbid in VB) by a summer intern for a working product and then promised a fully functional, fully tested, competively priced package tuned to a customer's whims inside of a month.....well, I probably wouldn't be spending the hours trying desperately to make it happen.
technomom
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.
Have you seen what they call houses nowadays, its pretty darn sad. Sure they don't fall down much, but they are stuffed full of fiber board, polypropylene, and blown insulation(where required by code). They stamp them out of cookie cutters and cut corners wherever possible. Shitty rugs, ugly linoleum, flat white paint, laminated cabinets. These things aren't build to last, they don't look good, and nobody cares! They drive their suv out to their suburban home and sit on their asses in front of the tv. art!? whats that?! Shakespeare in love playing on the movie channel?
The general lack of quality in current software apps is a reflection of our society. Quality Craftsmanship is a thing of the past, mass production is where its at. Businesses and managers are pressured to bring products and services to market As Soon As Possible. Process design, peer review, and quality control of central components fall by the wayside as new useless features are added willy nilly in an effort to bolster sales. I try to write good software, but without proper project planning there is never enough time or thought allowed to enter the process. Sometimes I feel like writing quality commercial software is like trying to swim upstream.
I have written some good tools that are used by many of our applications to quickly build linked customizable html displays of database data. I used another project as an excuse to build the tools. No time in the workplan for that! And have never been allowed time update and extend the tools even though it would clearly be beneficial and save time for many other programmers. Projects could be created with object oriented reusable code and modules well planed, organized, optimized etc, but clean code doesn't sell.
We have the best government that money can buy.
p.s. I don't have a tv either,
Then get one and bore yourself instead of boring others.
The real issue though is that of the gross abuse of over-extended analogies and metaphors from other fields to justify one's own strong-headed opinion. Comparing software design to home building or civil engineering as exemplified by Connell is typical of this type of wrong-headed fuzzy thinking.
Software design is software design. It is its own unique endeavor that may share all sorts of attributes with other activites but ultimatlely stands on its own. Software design has evolved into what it is now because that how it fits as a societal activity as determined by its practioners and product users. This means that software doesn't drive like a car, look like a house nor oink like a pig. And as Gabriel has pointed out, in the software field sometimes "worse is better"!
is Excel.
Why? Because, unlike NT or Word or whatever, it's the main application used by the people who sign the cheques.
NT is not marketed to the poor bastards who administer it; it's marketed to their boss's boss's boss. And Word is not marketed to the secretaries. Excel is used by the people who sign the cheques, so they get something decent to use, that does its job well ...
http://rocknerd.co.uk
but crappy design and piss-poor implementation is everywhere, not just in software.
When was the last time a vehicle was recalled because of improper wiring?
The last time an airplane went down because of bad rivet placement
Have you ever actually looked at the frame you house was built on during construction? I've seen frames with studs spaced out 30%-50% wider than the building codes spec out.
K5's front page has a picture of a very famous bridge. (Who knew harmonics would do that?) And I bet no one, even the engineers themselves, thought anything was wrong with it 5 minutes prior that bridge came crumbling down.
The devil is in the details. Don't assume that the next bridge you drive over is an elegant peice of engineering, I assure you it too has it's hacks, brute force tactics and hidden weaknesses. But like software those ugly pieces are hidden from the user.... right untill the point of failure.
I feel your pain -- BUT -- Visual Interdev is NOT VB! VBScript is indeed an abomination against God and Nature, but VB is maligned only because its early versions were implemented well enough to allow idiots to use it and thereby proliferate mounds of horrific spaghetti code (written without a plan, to be sure).
I do often wish the idiots had been left out of the VB game, since I now have to go clean up after them (like on the project I'm working right now -- yeesh!). But to compare VB unfavorably to a language that still requires you to manage memory BY HAND in this day and age does everyone a grave disservice.
Ask your doctor if getting up off your ass is right for you! -- Bill Maher
Note that armies can toss up a bridge over a river in quite short order, if they really, really need to get across.
Enabling warnings is all well and good, unless you're using poorly-written system or third-party libraries. Then you're just stuck with all sorts of warnings filling up your log files or your console.
[but not so great at an overall architectural level]
Try turning the "refactoring" knob up higher... be more willing to make architectural enhancements. With plenty of tests in place (acceptance tests, not only unit tests), and minimal duplication in the code, it's remarkable how radically software architecture can be changed in a short time.
At a recent computer software engineering course in the US, the participants were given an awkward question to answer:
"If you had just boarded an airliner and discovered that your team of programmers had been responsible for the flight control software, how many of you would disembark immediately?"
Among the ensuing forest of raised hands only one man sat motionless.
When asked what he would do, he replied that he would be quite content to stay on board.
With his team's software, he reasoned, the plane was unlikely to even taxi as far as the runway, let alone take off.
-----
If the company I worked for made the software, the plane would start to burn, slowly. The cabin crew run around busily telling everyone that the plane was NOT on fire. The crew wouldn't tell the captain. That's because the captain is passed out. The plane is slowly consumed by flames, however, the passengers don't notice, because the temperature only rises very slowly. The plane then explodes (too late to do anything about it, after all, they believed the cabin crew), killing everyone. Falling back to earth, the captain wakes up and starts screaming "REBOOT IT!!!!!".
How many of YOU would trust yourselves or the people you work with software that deals with life or death?
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.
In so far as programming is an art it is the art of the tradeoff. As the old saying goes: You can have it fast, you can have it good, you can have it cheap. Pick one.
Among the issues that a programmer has to balance are:
features
reliability
maintainability
efficiency
development time
To a great extent, satisfying any one of these requirements means shirking the others. The resulting work is a compromise that will annoy and offend most of its constituents to some degree.
The art, therefore, is in the process, not the result. As such, programming resembles politics in that a deal must be worked out between conflicting interests.
A programmer can be artist but what he produces will rarely look like a work of art.
But if companies insist on hiring H1-B programmers who can't speak English and have dubious credentials, we get low quality software.
Bridges are rated for a certain weight -- technically they could carry much more if built to the n'th degree -- should builders be ashamed that they did not maximize their material and design specs?
Netscape needs to learn the lesson that bridge builders and carpenters did long ago -- it's not perfection, that's what trim is for, it's delivery on time and on-budget that counts. MS is learning that/has learned it (latest version 2 months ahead of schedule...).
If a builder is a perfectionist they go out of business... they do good enough with trim, on time and under budget and lo and behold are considered true craftsmen.
The sort of craftmanship most GNULinux people seem to think is required for software is limited to a very small set of craftsmen in todays world -- mostly in the furniture business for custom, expensive and trendy furniture. Not general purpose -- marginal players.
the clipboard. I keep cutting and pasting the same crappy code.
But, seriously, a lot of software has short life cycles and is written to do a very specific tasks. So a quick, ugly hack is sometimes preferrable over a well (long) thoughtout chunk of code.
{ local $^W = 0; Third::Party::crap("foo"); }
Or use the newer "no warnings" statement, and you can selectively silence the poorly written 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
I usually find that a system, once analysed, comes down to a bueatiful, elegant set of systems and flows that integrate and encapsulate the problem and often provide generalised solutions that alow for future growth and expansion. This usually happens afte r a lot of talking to the end users and pouring over the requirements spec and really understanding the problem.
Then there's a pause. This may take hours or days or weeks (several months in one very large project I managed with several other code architects workingon the job too). In this period to the rest of the world (read: bosses) you're doing prtty much nothing but talking about stuff and having coffee.
Then The Design hits like an epiphany, descending from on high and you just *know* it will work. The final implementation may have to make compromises in the name of speed or resources or the language, but the elegance is always there. You can see this in well written code.
Try to explain this process to a non software person (like a mechanical engineer or a manager)...[sigh]
pithy comment
Just for kicks I decided to check the HTML of the article. Not surprisingly, I find the following markup repeating:
<p class="DefaultText" style="text-indent: 0.5in; line-height: 150%">
Truly elegant HTML would have defined another class for this style. I suggest the author of this article pick up a copy of The Pragmatic Programmer and follow tip 11.
DRY - Don't Repeat Yourself.
--Steve
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.
If we compare software to Architecture, we see that at first the program only require that it meets the users needs. We look further and see that the software must be robust and allow for further expansion for new versions, or additions. Finally we see that if all is done properly, with an eye towards aesthetics, this software can be a thing of true beauty.
Long ago it was proclaimed that Commodity, Firmness, and Delight are the attributes of Architecture. It is much the same, me thinks, in software design.
Ada95 is widely recommended for safety-critical software systems. If you really want to write reliable, quality software, check it out.
I watch Brit Hume on Fox News
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".
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 the author has some good points even though they have been told before. I do think, though, that in all fairness to all software engineers the comparison with buildings is too simplistic.
It is true that if the first design is awful, the engineers are to blame, but in reality I believe that most designs are - maybe not perfect - but at least suitable for the given problem. The biggest hurdle is when the requirements for the project changes, which could be compared to a regular house, that needs to hold a 70-story tall office building.
It is no problem to do that, but to do it on top of a regular house might not be too easy. Is this then due to bad design?
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
Silly, Cooper. Not the Inmates, it's the Wardens. The Wardens and Paroll Officers types are the ones running the Inmates in our asylum.
Look at all your PHBs and examine your PMs. See the PHB requiring Developers to do work of the Business Analyst. Watch the PM repeatedly nag the Developer for a piece of code.
The Inmates... they are doing as told, fighting to keep Monkeys off their back.
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.
actually, DNA does have "comments" (in a manner of speaking). It's called DNA Methylation
This is nature's way of "commenting out" pieces of genetic code.
from the link:
And I always get in trouble for leaving commented code in--it's actually Nature's way!
You know, if God/Allah/(insert your Creator here) would just release the source code ...
It is called DUST.
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.
Actually, a lot of software is written, THEN ABANDONED. Only the software that makes it to the customer first lives long enough to be maintained.
Herein lies the problem: most software that "survives" in the market is crap that was thrown together to beat the other systems. Unless you're in a well-funded, stable environment with customers who know _exactly_ what they want [i.e., developing life support sytems, etc.], you have no choice but to produce software this way.
If your program survives, you can go back and "refactor" your code to be prettier
(I _really_ hate that word...
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.
Addresses most of the author's valid concerns. http://free.be.com. Get some (TM) before it's Too Late.
Steve Klingsporn
steve@seapod.org
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
so up yours! :)
if you want people to think you know what you are talking about, just put ".com" at the end of everything you say.com
- Features
- Quality
- Time
If you fix any one (or more) of those parameters, the others have to give.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
..or they _think_ they can.
To use the building example:
If I need a building to conduct my business in, I don't go and build my own building. I know it's hard and I know that I probably won't be able to do it. Neither do I get someone who has just completed Jimbo's DIY bricklaying course to build a building. I know he won't be able to do it.
Yet, many business are doing exactly that when it comes to writing software. They think that because they have a compiler and a "Teach yourself C++ in 24 hours" book, they can do it...
Similarly, if I'm a researcher and I wan't to research the effects of weather on, say, a brick wall, I don't build the brick wall myself. I'm a researcher, not a builder. Yet (case in point - I work in a research organisation), we have all these Masters and PhD people who think that writing code for their research is easy. I spend hours getting their code to compile because they don't even know the first thing about scoping rules (for example)..
Charles Connell's essay presents appealing ideas; it'd be nice to think software could be "more aesthetic". However, the truth is that Worse Is Better -- as Richard P. Gabriel will often argue (and other times refute).
Exactly those things which make software "ugly" -- complexity, poor modularity, leaky interfaces, and sacrificing design and comments in the name of rapid deployment -- can also help make it more successful, commercially and socially, in the long run.
Exactly those things which make software "beautiful" -- such as Connell's qualities of "appropriate form", "minimality", "component singularity", "functional locality", "simplicity", and even "readability" -- can in fact make software fail, as "great programmers" spend a bunch of time making "elegant solutions" that never catch fire, because they lack the immediacy and approachability of more haphazard solutions.
While this idea may sound like an excuse to avoid doing up-front thought, it's actually a hard-earned lesson that what aesthetically appeals to good, well-intentioned programmers may in fact involve all the "wrong" tradeoffs.
Read all the stuff on this topic at Gabriel's Worse Is Better pages, then revisit Connell's aesthetics peice, and Connell may seem downright naive to you.
It didn't work. After many delays and much miscommunication it became clear it was going to take too long to produce a product solid enough to replace what we had, if that ever happened at all. Eventually the company abandoned the whole project and went back to the old ways of doing things, fired all the XP guys.
XP is not a panacea. It, too, can fail.
I play Nerd-Folk!
Another no-no is multiple Dims on the same line:
Dim AgeNumber As Integer, YearsToRetirement As Integer
And line continuation?
Msgbox "Are you sure you entered the right age? It should be between " _
& MIN_AGE & " and " & MAX_AGE & "."
No error handling around CInt?
Simple or complex.
Straight forward or beating around the bush.
Keep It Strictly Simple, or make it as messy as possible.
It's ALL up to you.
I write software for a living.
I can produce speghetti code, if I want to. I can make the software as complex and as difficult to use as possible, if I choose to.
But why should I?
Simple things come easier for me. I am a simple guy, living a simple life. Sometimes I make a mess out of myself, but most of the time, I ain't that messy.
Therefore, before I start to code ANYTHING, I think, I plan, I scheme. I look at other people's code, I steal ideas from them, I mix and match things that I like, and I incorporate whichever is useful in the program I write.
When all is said and done, what I aim for is to produce something that is simple, and yet powerful.
Clumsy software not only hurts the users, it also hurts the authors too !
Muchas Gracias, Señor Edward Snowden !
IBM developed the Chief Programmer Teams which included lots of mentoring and non-author code reviews.
There was proof of correctness via p-notation. (I never really mastered it, but I thought that was my fault.)
There was truly structured code. Dahl, Dijkstra, and Hoare had "Structured Programming" published in 1972. I only saw Dijkstra mentioned in thie discussion. Pity.
There were Truth Tables, which presented all of the operational variable names and the affected variable names as column headings. The rows of the tables were all values (or irrelevacies) of the operational variables and the resultant values of the affected variables. (I never used the single Truth Table generator that I ever saw, but when I ran into very tricky logic, I would write a truth table for the situation. I could alway determine that the table was complete and that my encoding was a valid representation of the table.)
Back, I believe, in the late 70's, there was a French firm named, IIRC, Mellisind. They had supposedly achieved good success by a business approach where they contracted for an analysis period which they felt adequate. Then they would inform the customer,if they regarded the job as feasible, how long it would take and how much it would cost to finish the job. Evidently, their success was overrated, but was it really?
Were these all false hopes or do people just forget?
Your statement "Beauty for beauty sake makes crappy software" is rather vague.
What is YOUR definition of "BEAUTY"?
The word "BEAUTY" can mean DIFFERENT THINGS to different people. Beauty can be used to describe scenary, or bimbos.
On the former, when beauty is used to describe a certain scenary, most of the time it means serene, gradeur, or simply pleasant.
For the latter, yeah, it's "beauty" alright. Just that other than that skin-deep beauty, there's NOTHING ELSE.
So... if your definition of "BEAUTY" rests on the BIMBO kind, then, you're right.
Software developers who write beautyful, bimbo-ous software - such as Micro$oft's Windows - will get all the praises from people with a big vacuum in between their ears.
However, the software developers who create beautiful software - in the sense of gradeur, awesome, and/or simply pleasant, need not worry about the "crappiness" of that software.
Muchas Gracias, Señor Edward Snowden !
Otherwise known as the wibbly wobbly bridge. Top architectural firm, key site across the Thames, modern computer software, and they forgot to take into account the 0.5Hz horizontal impulse generated by a crowd walking; only the 1Hz vertical impulse was designed in.
So they have to redesign it, adding dampers to the bridge so it doesn't shake...
So no, we still don't know everything about how to build a bridge.
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
-... ---
People seem to mix analogies and comparison now. If there's a _some_ similarity between coding on top of which an analogy can be made and bridge building. It does not mean that every aspect of bridge building and coding can be compared.
:)
Bullshit remarks like "we've been making bridges for centuries" just make me sick. (Heh, we've been making fire since the days when we didn't even wipe our butts and we still have fire departments.) Making counter examples than stating general laws seems easier, atleast for us, so why not use that on one's own remarks?
Perhaps "that argument might do it" kind of thinking may very well be one of the major reasons so much of our software is so disfunctional.
As a personal opinion, that is close to _the_ reason. Most people I know of, heck, even most people I work with, are sadly incapable of approaching in a sort of cruel, cold, strictly abstract way that some tougher areas of coding requires. And what creates problems is when these areas are being poked at without the programmer realizing that. Anyone who has studied or has some passion for maths knows that seemingly simple tasks may hide underneath overwhelming complexities. I guess that's something that programmes everywhere learn as they grow older and more experienced and get their beard and own set of horns on their forehead.
1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
A half-assed job is the American way, right?
I suffer from attention surplus disorder.
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.
Physical engineering is every bit as bad as software engineering. Bridges frequently fall down, buildings frequently fail, construction projects frequently go way over budget and fail to meet user requirements.
My grandfather, who was a civil engineer, discussed this with my father (a programmer), when the argument first reared its head. He said that the job of being "first across the bridge" is the most horrible job, and no-one wants to do it - because no-one trusts the designers or builders, even if they are the designers or builders.
A lot of code is badly written, I'm not going to deny that, but we're not going to fix it by worshipping another industry which has almost as many problems itself.
Find another argument, people!
Instead of posting these things saying our software is awful, why don't you go off and do a university course which teaches you formally the problems of Software Engineering.
Because thats this article is pointing out. The bleeding obvious.
If you've had any formal training in it..
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.
This article argues for code clarity, fitness for purpose and elegance and then uses Visual Basic to illustrates his point. Now that's ironic isn't it?
Even a quick python hack looks (to me) more elegant than his example...(note: brevity, multi-line strings, doc strings, printing multi-lines etc)
I can go along with the sentiment of this article but the specifics gall me, I would argue that if you want code to be readable then TEXT isn't the best display mechanism at all. If you want to document your code then doing it in the same medium (text) as the code is non-sensical, it takes up real-estate when you're trying to focus on the task in hand, documentation should always be showable and hideable. ( If you've not guessed I'm an ex-Prograph user)
I find it saddening that although lots of people recognize ugly software and coding environments, but their suggestions for improvements to the situation are so so limited. I mean, is tidy VisualBasic over ugly VisualBasic going to change anything?
tom smith
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.
Just because you can paint, doesnt mean you're an artist, I've known lots of builders, painters and decorators, and none of them were artists!
When are they gonna grow up, and go out and buy a computer and write some truely beautiful code????
eh? eh? eh?
come on then!
Which begs the question,
What is your job?
Are you a programmer, or are you "providing solutions"?
You see, I think this whole thing with specs and software engineering is a hoax. Having the customer sign off on requirements, gives the development team an excuse point. The only way to completely spec a system is to write it. Any missing feature in the spec is a possible mistake or short for the development team. Now, if the spec writer can write down a spec that is as detailed as the final system, then why the hell didn't he/she write the system in a compilable language to start with and eliminate the chance of mistake due to translation from English to code?!
My favorite mode of developing systems, is to get high level requirements, then prototype, then prototype, then prototype, then prototype, then prototype, keeping in mind that rewrites will be necessary, but should be incremental (rewrite chunk A this week, then chunk B next week, so that I never have to ask for 6 months to rewrite the whole system). The way, the spec is the code. The user describes a feature, I show them my interpretation, they describe another feature, etc. Very little room for miscommunication.
just now ramping up on coffee...
Joe
Joe Batt Solid Design
Probably nobody wants to think about changing for the better. Anyone read Ghezzi, Fundamentals of Software Engineering allready? The book is allready ancient but still stands.
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.
To be a chemical engineer, you must have training in chemistry. To be an electrical engineer you must have training in electrical engineering.
To be a software engineer? Any self-taught hack can call him/her self a software "engineer."
Change all existing code that looks like this:
void myfunc() {
while(1) {
}
}
to look like this:
void myfunc()
{
while(1)
{
}
}
Obviously more aesthetic, symmetric and eye-pleasing. Its step one towards prettier code.
Magius_AR
I'm lucky if I get a post-it note with a little chicken scratch on it.
Actually the only time I get a "spec-like" thing is when I get it from other programmers. It takes a lot to teach the average user how to write a spec. Most of them never quite get it.
I'd love to have real specs, ahhh let me dream....
Sean D.
"Hmm. I am to metaphor cheese as metaphor cheese is to transitive verb crackers!"
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
oh gee, like what this article says is like, obvious.
And oh gee, looks like you've got hundreds of replies already.
What does the old adage say ?
`Those who can... do. Those who can't... talk.'
How many actual developers in that thread ?
I suspect part of the software quality problems are given by the idea that programmers are like artists. Engineering is 95% "simply applying rules", 5% is creative, when the engineer has to find out how to do something new. 95% of software is "simply applying rules": but often programmers do not like rules. Or perhaps, due to the young age of Computer Science, we still lack believable rules.
In the medical field, a change is ongoing regarding the approach to patient care, by means of the so-called "Evidence-Based Medicine". Following this paradigm, decisions should be brought following the most up-to-date scientific evidence about diseases, and not basing just on feelings and intuition, as some doctors do, thinking at Medicine as an art. There is a lot to discuss about how scientific evidence can be stated and so on (it's not the right place, here), but something similar could be needed also in programming, and it could be reached if programming practices aimed at real reuse of software components (tested and "certified" to work), at easy debugging and readability are introduced into work.
However, the time constraint still remains (all efforts towards readability and reuse cost time), and is perhaps the most influencing factor for quality, in a short-termed programming strategy.
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.
Crappy programmers are cheaper than good ones. People prefers to buy cheap software with lots of features, even if it doesn't work!! So right now the situation is that, or either you make crappy cheap software with lots of features fast and keep selling like crazy (Microsoft way), or you built expensive great code with only a fraction of the features (belive me, to add features to a given soft takes lots of time) and no single person will buy it.
!!Don't kill the messanger!! Kill the software buyers!!
Crappy programmers are cheaper than good ones. People prefers to buy cheap software with lots of features, even if it doesn't work!! So right now the situation is that, or either you make crappy cheap software with lots of features fast and keep selling like crazy (Microsoft way), or you built expensive great code with only a fraction of the features (belive me, to add features to a given soft takes lots of time) and no single person will buy it.
!!Don't kill the messanger!! Kill the software buyers!!
If it was hard to write, it should be hard to understand.
Krispy Cream is people
I agree wholeheartedly that many 'professional' developers have no appreciation of the importance of correct, maintainable code, but the comparison with house builder is rather flawed. Most houses are built to pretty standard designs. There are standard components (screws, tiles, bricks) that have standard ways of being assembled. This is not the case with software (or at least not the software this I tend to work on). Most software is custom-built to the design of the user (or possibly the programmers guess at what the user might want).
:-) ).
There is a program on UK TV at the moment called 'Grand Designs' which documents people as they attempt to build their own homes, usually to a very individual and inovative design that they, or an architect working with them, have produced. This is much closer to most typical software development, and almost every house that has been built is overbudget and overschedule. Many do not get finished. As for quality, have you never seen reports of cowboy builders on house extension projects. Again, these are often ad-hoc projects, not working to existing design.
Most house development is much more analogous to things like web shopping carts, that take a standard basic design and just build the new bits that customise the site. From my experience, most of these tend to be pretty smooth and successful projects (usually unlike the e-businesses that buy the sites
I agree there is a problem with software engineering, but exactly the same problems occur in the design and build of many other things, especially when the projects are not properly managed.
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!
I work on a data wharehouse for a bank and everytime my client ask for a change or an addition to this system, we propose him a clean and elegant solution. 9 times out of 10 he says that it's too expensive (looking only a the short term investment and not the long term benefits). And we have to come back with a minimal solution, sometimes he even demands a throw-away one-time solution. I hate it when we have to do ugly programming like that...
Try it! Library of Babel
...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?
So what is the big deal?
to make it bullet proof. lol
It's also worth pointing out that a professional engineer approves and signs off on bridge designs when they are filed for building permits. An engineer who approves a substandard design can be held personally liable in the event of a failure, or he can be barred from practicing the trade.
How many of you design well enough to take legal liability for your work?
Sometimes people get lost in the idea of pretty code. The fact of the matter is, most people wouldn't think ANY code is pretty, because most people aren't programmers. Code is messy. It's like having a rock, coin, stamp, sports card, and (insert next innane collection here) collections kept in a huge cardboard box in your basement. It works. It's contained. It does what it's supposed to do. If you were moving, or planning on selling it all to someone at one time, is there a need to go through it and sort it out? No.
Maybe that was a bad analogy, but the fact of the matter is, the organization of the code, has very little to do with anything. I'm not saying people shouldn't write effcient code, because there are always reasons why code should be smaller and faster, but does it matter how pretty it is if it works? That's like complaining to the garbage man that his truck is dirty. It comes by once a week and helps me out a LOT. I don't question his activities or the condition of his equipment. He's there and he's dirty, and I love him for it!
And they said zombies weren't real!
Engineers of Dreams at amazon.
Read a good book lately?
A server is meant to stay up for 99.999% of some time period, normally a year.
If a Motorway or Interstate were so built it would require 3.5 hrs of maintenance in 40 years, it would never be stopped for snow, car pileups, dear crossings, or grannies loosing their marbles and driving the wrong way down them.
Interstates are the complex mix of rebar and concrete laid in more or less straight lines. They have no natural beauty.
So why the heck need software that has to operate under the same rules need beauty?
And why does this dolt think that goto's are pretty.
Ellegance in software creation is at the writers discretion, if it is specified in the requirements then use a code beautifier, if its not then just make sure that the next sucker to maintain it has enough guidance to be able to carry out the job effectively.
Expert: Ex, Has been; Spurt, Drip under pressure.
Have you seen the Discovery/TLC shows where the forest people of the Amazon are building a bridge over a steep-sided river? It's a few trees tied together with some vines or braided bark ropes. It's got spindly supports. The hand rails are for balance, and wouldn't hold you if you fell against it. By our standards you could hardly call it a bridge. It'd never hold up to the traffic we see every day. For those people who have no other choice though it's an incredible benefit. Sure, it's a bit unstable and dangerous to use, but they've got to get from here to there and they've no other choice. They've used the skills and materials they have, and it's better than the alternative. Some day one of them is going to have a better idea. Some day they'll figure out that bridges with stone supports and nice flat boards are better. When they get there they'll build a better bridge, but their skills and materials are going to have to improve.
Software is the same way. Most people dont' have an alternative. They can't make it themselves. They can't do without it. Meanwhile, we're looking for better boards.
- Sig this!
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."
Quoted from the article:
"... For many years, programmers were taught that global variables and GOTO statements are poor programming practice. In some situations though, these constructs may be exactly what the software needs to marry form with function."
This poor guy has just ignored more than half a century worth of Computer Science developments in order to tell us to go back to the way of the GOTO, even for "some situations", because it has been proven mathematically by Dr. Edsger Dijkstra himself that every piece of code that can be done with GOTOs can also be done using if's, while's and their kin. (And it's more *koff*aesthetically pleasing*koff* that way, too, as opined by Dijkstra in his article)
IMHO, marrying form with function is what this whole evolution from spaghetti code to structured programming to object orientation (and especially object orientation) is all about.
Pet peeve: Profane people propagating perfunctory pedantry.
lol
[man, this lameness filter really sucks!]
room101 -- how much can you stand before they break you?
(they always break you eventually)
Yeah, but the problem is how few "good" programmers there are.
Let's fact it, most programmers write awful code but nobody
ever gets to see it. I would estimate that of all the programmers
I have worked with over the last 18 years that less than 10% of
them could actually write well designed, well structured and
maintainable code.
Flame me if you will....
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?
A system's archtitecture is the programmer's user interface. With that in mind, the goal of the interface is the same as any other: be pleasant to use. We usually say 'maintainable', but it's the same goal. To help achieve that goal, software architecture should be beautiful, because a beautiful architecture is easy on the mind. A well-designed system is easier to remember and reason about.
Consistency and symmetry are the first two design guidlines that come to mind when people think about well-designed software, and of course software has to actually do what it was written to do. But beyond that, there are thousands of choices that depend on the engineer's aesthetics, and hundreds of choices where bending the rules gets better results. Classification is much more difficult that consistent variable names.
A lot of these 'beautiful displays of complex information' problems were solved by old-school drafting fifty years ago.
I want to make a linked list in Java. Ooops, no pointers, sorry.
As Procrasti mentioned, every variable in the Java language not of primitive type (int, etc.) acts as a pointer. Just because you don't see a * doesn't mean it isn't a pointer.
I want to pass a variable to a function and have it modify it, oops, no pointers.
So pass a reference. If you're passing an object, don't clone() the object before you pass it. If you're passing a primitive, wrap it in an object (i.e. int foo; ... Integer bar = new Integer(foo);).
I want to write a program that takes as little memory as possible, or reuse memory, or optimize it to use common options of the processor, oops, no memory management, no assembler.
Reuse memory by calling System.gc(). Write assembly language either with Jasmin (an assembler for JVM bytecode) or JNI (a way to link in unsafe native code).
Technically you could [write a JVM in the Java language], of course. But you'd have your JVM running on a JVM
Not necessarily. GCJ can compile Java language source code into a native binary using G++'s engine.
Damnit, I want a programming language that gives me access to the freeking carry flag! =). I've done math routines a lot, and the code is literally 10x faster when you can optimize it by hand in assembly.
Then design a language that does such a thing. GCC is free software; you can start from that. And if you don't like the quality of optimizations that GCC does on your code, contribute a better optimizer.
Will I retire or break 10K?
Software has no equivalent, and it shows. Typically, no one reviews a software design before implementation begins. (Hell, you're lucky if a design exists before implementation begins!) There are no minimum standards for the quality of the components (e.g., programmers routinely create a new linked list implementation instead of using a standard library). There are very rarely inspections during the building process (go ahead, try to get code inspections adopted at your work site).
The result is that a sloppily built house, barring actual dishonesty by the builders or officials, is unlikely to collapse unexpectedly, leak uncontrollably, or explode without warning. Newly "finished" software programs, sadly, are likely to do all of those.
I agree that "People cut corners if they think they can get away with it." In the construction arena, we don't just wring our hands about it; we put mechanisms in place to deal with it. In software, we just look for excuses.
Programmer time is usually much more important than machine time.
I see your point with respect to comments. However, unoptimized code and inefficient algorithms are unacceptable for many server-side tasks where adding more hardware to a large computing cluster would incur prohibitive costs. For instance, an optimized renderer may help an independent motion picture studio's render farm finish a movie in 2 years instead of 3.
Will I retire or break 10K?
Nice resume.
"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.
Bridges would fall down much more often if:
- people didn't go to jail when bridges fell down (just when they copied/de-rot-13-ed their competitors blueprints.)
- the distance spanned by typical bridges doubled every 18 months... continuously over a period of several decades.
- every bridge site has multiple competitors starting construction simultaneously; if you finish last you probably won't paid even if your bridge is slightly more elegant.
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.
throw the article out. Anyone who's had to do any serious type of Lotus Notes Development can tell you that he's being hypocritical, no matter how knowledgeable he is.
Clever,... My article and someone else's negating each other in a huge explosion. I'd like that.
Chuck