Slashdot Mirror
Why (Most) Software is so Bad
Rivard was one of several to point out that
MSNBC
says software sucks.
My opinion is that in software fields where the monetary gap between market-leader and second-place is large, we should expect bad software. Good design, good execution, good debugging all take time, but users can't see under the hood -- and wherever information is scarce or not readily traded among consumers, the free market bogs down. (Note what the article says about McAfee VirusScan.) So companies that don't plan on releasing a crummy 1.0 and fixing it later go under. That's just the way some markets work; if you're a coder or engineer who doesn't like that, find yourself a job in a niche without that monetary gap. Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has
sued.
Update: 06/18 14:10 GMT by J : Readers point out the story is a reprint
from Technology Review
(one of the few good magazines I get -- but this issue hasn't arrived yet :).
Rivard continued his writeup with an interesting point of view, saying that while we all know software sucks, we just accept it:
"Even though 'plenty of reviewers, pundits, hackers and other outsiders' will point out problems, often intentionally left in the product, no one has brought a liability suit against the makers of the known-to-be-vitiated product -- because the software gestapo (the End User License Agreement) has been 'able to avoid product liability litigation partly because software licenses force customers into arbitration' of poorly designed pith."There is a light at the end of the tunnel, believe it or not, and it's Bill Gates. Microsoft suspended coding for two months to seminar on bugs and how to fix them. Gates told his employees he wanted to make 'reliable and secure' software Microsoft's 'highest priority.' If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."
MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued
Alright, let's sue 'em then...
Micro$ofts problem is that they forget the "and fix it later" part.
Never underestimate the power of human stupidity.
Yeah, yeah... do as I say, not as I do. :)
If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not theregister.co.uk) MSFT-criticisers. This is typical of them.
a) Preaching to the choir.
b) Old news, I've read most of it elsewhere.
c) a thinly veiled Microsoft bashing coming from within.
d) fodder for Slashdot's editorial slant of objective stories.
now there's something i'd like to see. maybe it could enforce algorithms, understand design specs and anticipate customer mind-changes, too.
i think the next version of C# is suppoed to do all of this, with some kind of XML voodoo scheisse.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."
"There's no silver bullet" -Fred Brooks, a long time ago.
I mean honestly, I've seen some of the potheads in my freshman CS courses write more coherent code than that. If you had been taking my class, I would have failed you.
"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
I disagree; take a look at other industries. Some of the highest-quality products are produced by the tiny, niche-market manufacturers. The best cigars in the world are not from Phillip-Morris. The finest cuisine on your block is not the mega-corporation with the giant yellow 'M'. The most accurate watches don't come from time-giant Timex. The finest literature on the bookshelf isn't necessarily from the biggest publisher.
Software is hard to compare to other products. It's intangible. It's complex. There are a million different ways to get "Hello World" onto your screen. Maybe that's the problem?
Software is also relatively young. Not just in the sense that it has only been around for 40/50 years, but in the sense that the tools evolve so quickly, that it almost seems like every few years, you're working in a completely different manner than before. And it takes time to become familiar and comfortable with the paradigms associated with your environment. Just when you've got a system worked out, everything changes again.
Before, the customer wanted a library of CGI scripts to run their e-commerce website. Now that've got a handle on scripting design patterns, the customer wants EJBs. By the time you learn what to expect to go wrong with EJBs, the customer will want a cell-phone interface to their inventory.
Sometimes, I'm amazed software works at all.
Like woodworking? Build your own picture frames.
Im working with 2 other developers and one source of fundage.... the client.
I has been an enormus task to get the software: A) bug free B) functional C) better than the compitition in a year.
There are problems, and there are alot of thing that I would like to do different.... but its just not possiable...
I can only hope that it does well after release. but it makes me wonder what I could have done with more fundage...
The Code Ninja is swift with his tool, precise in his delivery, and deadly accurate in his execution.
Software's so bad because it's still handcrafted, and the interchangable parts don't. Cars sucked too when when they were done the same way. OSS isn't the solution. The solution is for Computer Engineering to someday become as rigorous as other areas of Engineering.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
As the army boys (and gals) say...
Keep It Simple Stupid
Today's programs (and O/S's) are horrendously complex so this in it self is a problem. Sure there are other problems, but the more complex a system the more likely it is to fail.
"like creating a programming language that forces good code"? I doubt it. It's my impression that even where languages do enforce various checks - perl in taint mode, for example - there are always ways around it or issues that the code can't check. After all, a significant proportion of "bugs" aren't faulty code per se, but correct code that is based upon incomplete or incorect assumptions and design.
The fact is, there are well-researched, well documented means of achieving quality control in development. They're simply not practiced by many because the implementation overheads are just too great. Many coders don't plan their code adequately, don't document their code adequately, and don't test their code adequately. However, this isn't necessarily a 'bad thing' -- frankly, in many circumstances it's just not that important if a few bugs sneak through which can be patched at a later date. As is always the case in such matters, security/stability are sacrificed for convenience and speed of development. And that's not necessarily a bad thing, especially in an industry where a product can be superseded or otherwise rendered obsolete even before its bugs become too much of a problem. (Although I'd admit that there are dangers in taking this for granted, as seen with the y2k issues..)
We should expect bad code because we expect code that rolls out quickly and at a low budget. We should expect bad code because most coders don't want to spend their time testing and documenting, and because most companies don't want to spend money on dedicated testers or on implementing rigid development processes. And we should expect bad code because even bad code can work 'well enough' to keep most people happy most of the time.
Or anything else, for that matter, ignorance can be bliss.
This article is out of the July/August MIT Technology Review. My copy of the magazine proves their point in an ironic fashion.
./ probably could--isolate the bug in ten minutes given the source. Likely it assumes that either the first city is valid or that the likelihood of two cities beginning with the same two letters in the same zip code is too small to consider.
The zip code I live in covers two cities, let's call them Appleville (tiny village) and Apricotland (large, sprawling concrete wasteland.) I live in Apricotland which is asciibetically second (based on the third letter.) Note that the first two letters are the same. MIT TR's mailing system lists me as living in Appleville. Why would it assume that zip code 12345 is the smaller village instead of the sprawling metropolis?
Yup. Buggy software. I could--as anyone reading
The joke's on you, MIT.
To me the largest factor in determining whether the 1.0 release of something will be acceptable is time.
Given enough time for proper design and testing, a 1.0 release could be acceptable, but companies hiring consultants do not want to pay for the time, and companies that produce software for the general public have to rush products to market to beat company X, whose competing product is due for release, and (more importantly?) they need to please their stockholders.
Once in a while you get a Mozilla-type thing that takes forever, but puts out somthing worthwhile with 1.0.
The revolution will be televised. Blackout restrictions apply.
"but users can't see under the hood"
perhaps this is why software is bad moreso than anything else?
When you copyright a book: anyone can pick it up, read a few paragraphs and compare it to another book. The reader can decide for themselves whether one book infringes on another's copyright, which one is "better" and can add that information to his/her accumulated knowledge. It's an OPEN copyright!
But when you copyright software: you get a (collection of) function(s) that you can run on your machine. A tool that you use. There's very little learning here... no using it as a foundation to the next level (like learning to add is a step towards learning to multiply). The user can't compare the program to other programs except through the GUI. He/she can't tell whether it infringes on another progam's copyright, and all (comparable) programs pretty much look the same. Not to mention that when it crashes... no one knows why.
Yes this is basically the open software vs closed debate. BUT, I don't understand this "welding the hood closed" approach that software copyrights are allowed to take. You don't see many books on Amazon with their pages glued together?!
Rivard was one of several to point out that MSNBC says software sucks ... MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued.
Several pointed this out???
MSNBC does not say software sucks. MNSBC is a content re-provider, printing a piece by journalists, Charles Mann, who was writing for (Copyright © 2002 Technology Review) Technology Review magazine.
The opinions expressed by blah blah are not necessary representative of blah blah MSNBC.
Jeesh.
...because of a bug in the JavaScript which prevented the menu selections from working. Clearly this wasn't tested properly.
I believe that we are seeing the increasing development of issues that were first coming to light in the late 90's, when the Y2K problem was starting to be recognized as a problem for society at large. As the economy comes to rely more heavily on properly functioning software based systems, the push to make the designers and constructers of these systems responsible for them. Too often in the community the various proposed approaches to design and implementation (now being expressed as the battle between methodologists and agile methods proponents) obscure the basic need to build the right systems, in the best known fashion. This is, at heart, being willing to accept responsibility for what has been promised. If the community will not do this, then legal sanctions will be imposed which force the issue.
"If it doesn't spit out an error message, it must be done correctly, right?"
Well, that IS how they teach people to do it in college...
I'm disappointed that this article didn't mention open source even once. The process of writing an open source project is much different from that of a proprietary piece of software, and (as far as I'm concerned) the open source method is much better equipped to deal with things like sloppy code. But to the average computer idiot who reads MSNBC, this article makes it seem like all software systems are going to kill U.S. Marines and crash ambulances into each other.
1. Smart (or dumb) guys form startup around good idea. Version 1.0 gets written in a frenzy of caffeine and beer, riddled with bugs because it has to be delivered before the money runs out.
2. Mistakes made in version 1 are sworn off as version 2 is designed. Version 2 is built by the swell of 2nd-generation coders, hired as fast as possible and sent to work unsupervised by the overworked 1st-generation engineers.
3. Version 2 is delivered with all the good ideas on the surface, but implemented by less-than-excellent coders.
4. Widespread adoption funds much additional hiring. Anything vaguely mammalian is hired to fix bugs and work on new features and new products. Most 1st-generation engineers leave with their money. Product design and development is run by people who don't know what they're doing.
Just like cars, refrigerators and houses, the quality of what you purchase is not perfect. And you should not expect software quality to be perfect any more than you expect your car to be perfect. The more money you pay, the more quality you get. It's an asymptotic approach where increasing quality costs a lot more money.
Just because of a long-standing close relationship with mathematics, people buy into the idea that software should be as ironclad as a theorem.
It just ain't so.
Real software becomes complicated, much in the same way that PDE's governing real physical phenomena become complicated. Small pieces of software can be verified for correctness pretty easily, but complicated interacting pieces of software rapidly will exceed your resources to check for behavior under all circumstances.
There are so many ways for it to behave and misbehave that closure is a process of endurance, enumerating and testing as many options as possible under as many likely and important conditions that you can think of.
At some point, you decide that you've reached an acceptable level of quality (does our regression tests and stays up and running for 99.99% of the time for the sample of typical users) and release the product.
[Bill Gates is another matter altogether. I think he's responsible for some distortion of the software marketplace and, thereby, responsible for software not needing to be up to higher standards. That said, however, even without his influence, software will never be up to perfect standards.]
"Provided by the management for your protection."
I believe commercial software is bad because the companies and programmers have no real incentive not to make it so. I believe part of the problem is not the gap between the market leader but the gap in the corporate org chart where the techies meet the technots.
The level of people that SHOULD care about high quality don't understand enough. Not only to they not push for high quality code, but the push the other direction entirly.
Scale of big vs. small means nothing. I have seen some fairly high quality open source projects with a programming team smaller the their commercial competitors secretarial pool.
-Pete
Soccer Goal Plans
There is a light at the end of the tunnel, believe it or not, and it's Bill Gates. Microsoft suspended coding for two months to seminar on bugs and how to fix them
Does this sound like hidden Microsoft propaganda to anyone else?
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
We were given unreasonable deadlines - as with every project I've been on. When I mentioned that the aggressive deadlines were unreasonable, I was told that I "had a bed attitude" or "I didn't belong here". Never the less, we produced complete shit while we were working our mandatory/voluntary 80 hour weekd. (They told us that we didn't HAVE to work that much, but if we didn't, it would affect our reviews. Some people didn't and they were later on laid-off.)
The company was able to bury the costs of the law suits in their books and hide it from their stockholders - sigh.
I hate this most, though. Every project I've been on had these unreasonable deadlines. Don't managers get it? Rushing around only produces crap.
but what are you personally doing about it? Everyone can help to make software better, from documentation to testing to actually coding. I find that most people bitch (including me), but then they don't end up doing much about it. A lot of software's terribleness lies in our hands.
Great Linux Site
Software likes to think of itself as 'engineering' but it's not. It's not structured, it's not methodical, it's not repeatable, it's not quanitatively quality controlled, it's not maintainable, it's not documented correctly, it's not impervious to new flaws after it's finished, it's never finished.
Project managers don't, requirements assessments can't, cost estimates are from Mistress Cleo. Nobody understands what success is supposed look like and no one can tell the difference between success and failure.
It's neither mass produced art nor is it artistic engineering nor is it special or inciteful. It's an ordinary product made by people who have to be extraordinary simply to overcome all of it's other failures. It's the dancing bear - interesting not because it dances so well but because it dances at all. It is a controlled crash.
Unbelievable that we should take seriously the complaints of TV, which drowns us in commercials, covers us with misinformation and biased reporting and is soft on corporate abuses until they reach the Enron-like level that can't be ignored.
While all software contains bugs, and it may be impossible to root out all bugs in adequately complex programs, most software does it job almost all of the time. My word processor processes words, my spread sheet spreads sheets of numbers and my browser allows me to browse. These are MUCH more reliable than TV!!
I'm against this notion that people want good software. As a software consultant, who has been involved one way or another in a varienty of fields, I can say with authority that companies want software *cheap* not *reliable*. When companies want reliable and secure they pay for reliable and secure. Companies have an absolutely unrealistic expectations of what can be done in a short and cheap development cycle, yet that's what they demand from their consultants. I have an client (a rather large health care provider) that still hasn't changed the default password to the publically available administration section of their system... which is more common than one would care to think. This is a testiment to how high companies consider security important.
Check out my podcast: DreamStation.cc Video Game Show
So that's all fine and dandy, but it's not like you can just take one from each column and have something that makes sense. For example, were bugs in an operating system due to inefficient code that would be fixed by component-based design with an eye towards cost effectiveness? Well, uhhh, maybe, I think.
It didn't help that so many of the people quoted had no idea what they were talking about, and the ones who did had their quotes taken so far out of context that they made no sense. It seems a lot of people who never worked at Microsoft know how Microsoft develops software. Oh well.
It would make more sense to talk about a particular class of software and bug and then discuss why it is there. E.g. why do Microsoft systems products have buffer overflows. Even then you would get a bunch of different answers.
- adam
P.S. Comment first posted by me on Techdirt.
Well, that IS how they teach people to do it in college...
Thats not necessarily true. I am a college student now and I just finished a tough course in advanced data algorithms. Our programs were graded heavily on if they did what they were actually asked to do. It was not so important how it did it, but rather that it obtained the correct results. (The projects were assigned in such a way, that making smart intelligent software made you work easier in the long run.)
Great Linux Site
From Dictionary.com:
lacuna n.pl. lacunae
In the spirit of "the glass is half full", Steinberg recently released a new version of their music software "Cubase" and, on the very day it was available, released the "x.1" patch. Yes, some of you "the glass is half empty" people will say they should have waited on the major release, but I say this is a step in the right direction.
And until we're all running the exact same hardware I think we're going to have to settle for "less than perfect" from the software industry. When there's a bug with every sound card on the planet I fault the software company's lack of testing/research. When it doesn't work with a sound card only 116 people on the planet own, it's still listed as a "bug" and, lumped together with the other statistically insignificant "bugs" looks awful when reported together.
Finally, to all these estimates of how much $$$ "bad" software is costing....How much would it cost WITHOUT the software? Do you really want to jump in the WayBack machine and return to the glory days of a totally manual world where every problem was described as, "It's somewhere in the secreatarial pool?"
+-+-+-+-+-+-+ "I don't know what's wrong with you, but I'm quite sure it's hard to pronounce."
This sums up the state of ICQ. I stuck to 99b for a very long time, then tried 2000a to alleviate the connection problems and then dumped it for trillian. If they had developed from 99b into what LICQ has instead of their AOLised crap, maybe I would have kept with the official client.
I find the automatic assumption that, journalistic integrity goes out the window (no pun...) the second that there's a merger, very odd. I have to say, I haven't seen any reason to think twice about NBC's news yet. Is the MS-paranoia getting out of hand, or are we just conditionned to reading one-sided "Editorials for Nerds. Stuff that we think."? *Sometimes* journalism isn't about ramming a political message down people's throats....
the "code now and fix any bugs latter" mentality is what CS students in their first 2-3 years in a CS program are taught... do you know how hard it is to get a group of people to break out of that mentality. Where I work, you see a lot of lets "code now (with perl) and glue it together and pray that it works, and if there's bugs, apply a quick fix" Which is fine, until you have a complex program such as a data pipeline...
Also, we have end-users screaming at us for software... they don't care if there are bugs, becuase they assume we can fix them over-night. End-users like software released often and perfect.
Accentuate the positive, don't waste your mod points on the negative.
to design you a house,
then when he was almost done, said that the walls must be made from foam.
....except the one on thats in the swamp....
....and now that you've disigned one house, it shoudln't take you long to do a few more...
..and did i say there has to be a high speed rail link between them...It must travel faster than the speed of sound, but never hit any animals that happen to wander on to the track.
..and can you make that house bomb proof....
whys that house got walls made out of foam?
thank God the internet isn't a human right.
In A.D. 2002
....
=>
Bankruptcy was beginning
00
00=>00
00
CmdrTaco: What happen ?
CowboyKneel: Somebody set up us the economy
CowboyKneel: We get financial report
CmdrTaco: What !
CowboyKneel: Main screen turn on
CmdrTaco: It's You !!
Creditor: How are you gentlemen !!
Creditor: All your linux server are belong to us
Creditor: You are on the way to chapter 11
CmdrTaco: What you say !!
Creditor: You have no chance to survive sell your stock
Creditor: HA HA HA HA
CowboyKneel: Taco!
CmdrTaco: Sell off every 'thing'
CmdrTaco: I know what I doing
CmdrTaco: Sell 'thing'
C - A language that combines the speed of assembly with the ease of use of assembly.
is like creating a car that doesn't crash.
Oh wait, you can do that; it just means it won't run.
So I think it explains itself.
"no, i'm sorry, the correct answer is 'who gives a @#$@?'"
in spite of the mix-up about which part of the Greater Fruitbasketland area you live in, you obviously still receive your magazine. hooray for ZIP codes.
[just defending MIT's honor (just kidding... i'm sure the addresses/mailings are handled by some separate contractor)]
At the very bottom of the page:
MSNBC is optimized for
Microsoft Internet Explorer
Windows Media Player
Reminds me of the GPL bashing story that was hosted on a linux machine.
- adam
While this is true, I doubt that the Navy ship that was coerced by faulty software to shoot down a civilian aircraft was running Microsoft software. And the operating system still wouldn't be at fault here. This type of thing would be due to faulty design and coding on the part of the weapons targetting systems. This software that probably runs on some sort of Unix system--Software that is most likely unique and proprietary to this ship.
While Microsoft is undoubtedly the most highly publicized proprietor of poorly written bloatware, there are many others to be held acountable here. This isn't just about operating systems, or office applications. This is a fundamental problem that I'm beginning to see in all software created recently. From game publishers, to shareware, to P2P clients, to proprietary data systems there is a lot of poorly written, and even more dangerous, poorly planned out code.
Game developers are frequently rushed to the point of putting out a sub-par error-riddled game because the publisher wants the game out on schedule, not when it's ready. We've all seen numerous stories about how the majority of the P2P file-sharing clients are filled up with bloat and spyware. A lot of us have worked for companies that have their own IS department that writes proprietary code for many of the business's apps, and I think a good chunk of us can agree that many of those apps are poorly written and not very well designed.
I don't know what the solution is myself to this problem, and I don't think Bill Gates's plan to create a programming language and compiler that will resolve all these errors will work either. I think that this will only lend towards more reliance on the compiler to do the coding for you. Only a good Software Engineer is going to know which search routine to use in different instances, or how to write a proper algorithm for the proper circumstance. Software compilers, until they develop intelligence on par with humans, will not be able to do this for us.
I think the only solution is to go back to our roots and examine the way we teach and train the upcomming batch of computer science students. Teach them not to rely on the compiler to fix their mistakes for them, but instead to thoroughly plan out the code they're about to write (on more than a napkin preferably), use the fundamentals of programming to pick the proper routines, use modular design to produce a better product, and also to write code correctly the first time. Think of it like this (if any of you hunt that is), when aproaching your prey in the wild with a bow and arrow as your weapon of choice you must be sure of your shot, and be sure that your first shot counts or you may not get a second one. I think software designers need work towards making sure their first shot counts. Do it right the first time, and don't rely on the equipment to do it for you as only skill will prevail.
Duris MUD - The best pkill MUD. Ever.
1) Slashbots cannot fix problems themselves.
2) We productive members of society have better things to do than to look at POS slash code. Slashbots don't.
3) They, subconciously knowing #2 but dare not admit it to themselves, feel that they shut us up with that mantra. After all, we DO have better things to do.
Knowing a bit of how mass mailings work, specifically how you figure out who is where through zip codes, the actual city that gets printed on things mailed to you in that fasion is determined by checking the Post office database, usually through a program such as AccuZip.
Lots of times, the city the post office has you in isn't the city you actually live in, but it will get to you all the same, because the Post Office can't assign multiple municipalities to a single zip code. They probably picked the small town because it didn't have any other zip code, or whatever criteria they have. Don't blame the software for something that isn't it's fault. It's just doing a query based on the official database.
Anyway, I am wondering how complex a car would be considered vs. an operating system. For example is an OS roughly as complex (therefore as hard to get right) as a car...or is it more like 10 times as complex...or maybe 100 times as complex? I would say it is more like 100 or 1000 times as complex.
Remember cars aren't perfect either. Almost every car Consumer Reports tests has a few "sample defects" in it (something they could have worked out in the manufacturing process with more time/money/care/design), plus they have "bad design" (unclear controls, etc), and some of them have real "bugs" (occasional stalls, hunting for a gear), and then some have real major bugs that result in recalls.
- adam
In other engineering disciplines, there is little room for error and your mistakes are readily apparent -- you screw up, and you'll probably wreck a few million dollars worth of equipment during testing or kill someone when the product ships. Software engineering, on the other hand, allows the mediocre on the team to hide behind truly talented individuals.
Code doesn't work? No big deal, just fiddle around and recompile. Still doesn't work? The other guy will probably fix it. Product's shipping and the problem still isn't fixed? Eh, who cares? It's not going to kill anyone, and nobody will notice.
It is precisely because no one can "see" the shoddy workmanship of programs that such behavior exists (and I'm not saying open source programs are immune to this -- patching a crappy open source program is akin to patching up a crappy car engine with duct tape and staples). All those slackers who couldn't code a binary tree to save their life and were generally mediocre college students are writing the software you'll be using. Their mediocrity is hidden by the anonymity and zero-accountability inherent in large software projects. Essentially, they're doing the same thing in the real world as they did in college -- slack off and hope nobody notices.
This, folks, is why colleges need to implement tougher CS curriculums. This is why you need to be able to write code on paper. This is why colleges insist that you don't collaborate on projects in lower-level CS classes. This is why there shouldn't be curves that allow mediocre students to graduate with a CS degree when they should have been weeded out during their freshmen or sophomore year.
I'm almost finished with my CS degree, and it's depressing, even at this level, how few students there are who really have an understanding of and interest in computer science. Most of the students enrolled in CS at my school have never coded before college. The most popular reason for choosing CS? "I used to make webpages, and I figured it would be easy." No joke. Of course, this sort of behavior isn't strictly limited to CS -- I've met more than a few EE students (freshmen, admittedly) who couldn't identify basic electrical components, didn't know Ohm's Law, and chose EE because "I used to take apart telephones and put them back together, so I think electronics is fun." Inevitably though, these clueless students who enroll in other engineering disciplines tend to migrate over to CS since it's not as "balls-to-the-wall" difficult as say, EE or ME.
In short, software "sucks" because our colleges are allowing mediocre students to slip through the cracks into the professional world. Personally, I feel that the CS curriculums should tighten up a bit and put more emphasis on solo projects (and moderately challenging ones, at that) and writing code on paper at the lower levels. A message has to be sent to those students who want to be engineers but don't really have what it takes that CS is NOT an "easy major". Perhaps then it might not be the haven for slackers that it has become.
Well, that IS how they teach people to do it in college...
Any school that does that should lose their accredidation. Reality is that no school does that nor would any teacher advocate that. The key idea is teaching the student the difference between a compiler error (ie, missing semicolons) vs. a run-time error (adding 1 instead of subtracting 1).
I'm in college now (will be a Senior in September), the freshman are taught C++, and one of the first few lab sessions involves being given some short code (written by the prof) that compiles correctly, yet contains a logic bug of some sort. Likewise, the textbook contains a discussion along similar lines, including that famous quote from MIT that says something to the effect of "We were amazed by how often we had to go back and fix errors in code that we wrote"
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Lots of smaller applications companies that are just hanging on right now will die if strict standards are put in place.
Development companies are already in trouble: fewer applications are being built and sold today, there are no new "killer app" categories and Microsoft tends to embrace and extend any new features customers might want. Lots of companies are just making it by.
Do they deserve to die? Many do, since they're being run just as badly as the article states.
But I wonder how many will survive. Will we just get a few huge BigCo's that have the deep pockets for the kind of remedies suggested? Won't be as interesting to be a software engineer then, I think.
I'm sorry, but unless I'm severly mistaken the author seemed to think that C# prevented the coding of certain errors.
I'll give C# it's due, it does prevent some very basic coding errors, but with it's backward compatibility enhancements (aka raw pointer artithmetic) it's not nearly as foolproof as it could be, but that's missing the issue.
The answer does not lie withing language A or B (heaven bless all who know B). The answer lies in an engineering practices that design software for maintainance. Such processes are only in their infancy and are usually ill-adapted to dealing with the ton-of-code(tm) that already exists in the market.
I like the newer engineering practices that are coming down the line, but how can I apply them to my 10 year old project with a mix of C / Fortran / SQL / C++ / sh / csh / Tcl / Tk / VBasic which was designed emphasizing output over maintenance?
seems to stick just to MS products for it's examples? I don't know about you guys, but I've only seen software which locks up and takes my whole machine with it from MS.
The only time GNU/Linux ever goes down is when I shut it down.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
....what is that, some kind of sense of humour? I mean... it is MicroSoft NBC, right? Are they facing reality or what?
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)
"there are other solutions, like creating a programming language that forces good code;"
Is this on the line of "get rid of GOTO, it is evil"? What we don't need is a programming language that forces everyone's idea of "good code" on everyone. We need programming languages that are flexible enough to handle different programmers and different tasks.
While there is plenty of truth to the problems of lack design, poor coding practices, etc. there are other factors - just as important - that contribute to the state of software today. many companies have product plans that are put together a year(s) or more in advance, and there is tremendous pressure to meet those dates. rush your time to market and quality is going to suffer every time. thus, buggy commercial software is often the responsibility of executives as much as developers.
Leading the way where? Speak of the blind leading the blind...
And here I was thinking *BSD's whole principle was solid, (mostly) bug-free code. Guess they aren't "publicly" leading the way, so they don't count.
You can read all my screens, printouts and help pages, but you don't need to see the code to use the application.
In the same way, you don't get to see authors' notes and earlier drafts.
What you get is what you see.
--
(if you're still looking for the point, it was back there, in the post. </sig>)
Excuse me? I don't know how everyone else does large software projects, but I don't know of any company that designs these large software projects on the back of envelopes. This article is a flawed, and dumb article about software engineering. Software is getting better not worse (ok, that's argueable. But software development proceedures are getting better). Sure we can rip on Microsoft's applications, but how many projects were 12 million lines of code in size 10 years ago? Most software they discuss is relatively new software. Old tried and true software is really quite solid. Has vi every crashed on me? Not once. Bleeding edge software is quite complex. What do you expect? There is no silver bullet, but as the profession grows, more and more tools are developed. We currently use Quantify to profile our C code and Boundschecker to check for memory leaks and dangling pointers. These tools continue to get better and better. The main problems the article harps on stem from poor development processes. Books such as "Writting Solid Code" and "Code Complete" cover much of these issues.
And of course the arguement that open source produces quality code through peer review is not even mentioned in the article.
As a developer, I've seen this happen first hand, but in most cases to blame the engineer is incorrect. In my case, pointy-haired boss types pull a deadline out of their asses and expect the Engineering team to hit the deadline. What happens then? Well here's one quick anecdote.
The company I used to work for decided in February of last year that we would ship version X.2 (where X is greater then 4) of our software package at the end of June. Only problem was, there were still approximately 10,000 known bugs, and the only reason to ship in June was to announce the release at the company sponsored trade show. That, and there wasn't a single engineer asked for an esitmate, unless you count the moron owner who thought he was a developer and was notorious for being way too aggressive in estimates (among other bad habits, like not even building his code before checking it in to the source control system).
Clearly, there was no chance in hell we were going to hit the deadline. Management's solution? Mandatory unpaid overtime. 15 hours a week. All requests for vacation were denied until the product shipped.
To make a long story short, 2 developers quit (myself being one of them), 2 were laid off because they didn't have a new version to sell because X.0 was such a piece of garbage for a lot of the same reasons.. and the company finally trotted out version X.2 to very little fanfare with 3000 known serious defects still not addressed.
And, like X.0 before it, it's a POS - a piece of shit. Engineers get burned out when they are overworked just like anyone else, and are forced under threat of termination to make poor decisions to keep their jobs. Management then oversees the creation of a poor product and then are completely oblivious that they are the root cause of the problem. Instead, the development department gets blamed and in this case the director got canned. (When really all he did was take his marching orders from the owner. No authority to make decisions, and yet they held him accountable.)
The truly sad thing is, all this can be avoided if management would just back off and let developers do their job without micromanaging and shoving their nose to the grindstone, spending the investment capital to pay your employees overtime when appropriate, staffing up your Quality Assurance department (5 Analysts testing code put out by 10 engineers is not enough by a long shot) and not releasing it until it's ready.
One excellent software release can make your company very rich. One poor software release can kill your company. (And in the case of the company I used to work for, I must admit I hope that happens. The world would be a better place without that third rate company run by a fourth rate pompous jack-ass developer who thinks he's above you just because he went to an Ivy League school, and you just went to the local University.)
And don't even ask me to name the company or the product, I won't, I still have close friends that work there. Even if I do wish they'd quit drinking the Kool-Aid..
6. Fixing even the shallow defects would break backwards compatibility and the customers all swear they will go to your competitors.
People say software is bad because they are arguing a strictly technical view.
My observation of software projects in FAA and DOD realms is that the projects are focused on
maintaining a problem, not solving it.
Sure, the code itself blows chow; but the software accomplishes its mission of
employing the maximum possible amount of people.
All this disgruntlement is indicative of immature perspective.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I should know better by now, but it still knocks me for a loop that popular media still idolizes Gates and Microsoft. In the same article where they state that Microsoft has cost consumers billions they go on to say that Microsoft will be their savior!
Give me a fscking break!
This is the same problem that's gone on for years. Microsoft has been so successful at integrating themselves into the psychie of America that no one thinks there could ever be an alternative. Here's what we have to thank Microsoft for:
Thanks to Microsoft crashing computers and daily reboots are accepted as normal by the public! How many Slashdotters can testify that they've had to reboot servers because Management, clueless though they usually are, has bought the idea that servers just have to be rebooted every now and then to function? I sure as hell can. Software crashes and Operating System crashes mean that something is wrong! Fix it damnit! But the first thing Microsoft will have you do if you call them for support is reboot your server. "Oh, you're using that version of Windows? That's your problem, the latest version is so much better." I hear this so often it make me want to puke. Give me a stable OS the first time around. Give me stable applications the first time around. Up time should be measurable in months, not hours. Thank you Microsoft!
Don't tell me that the software is too complicated, that's just an excuse for bad practices. I've got an installation of NetBSD running at home that's been running ever since I moved in. Don't tell me that Free OS' can do this because they aren't full featured. I've got an OS X box which is in the same boat. Uptime measured in months and it's a commercially available OS.
Face the music people, interface design counts and Microsoft has always been behind the curve. Apple's studied it an their results show. Adding a plethora of widgets does not make a good interface. Moving those widgets around constantly means that people have to relearn every new release. Consistent interface design counts. Most people are users, not geeks. They just need it to work reliably and repeatably. When systems work reliably and repeatably you don't have to think about how you do your work, you can just do it.
Finally, the next revolution that Microsoft is bringing the masses, software leasing. No you don't own the software and if you don't continue to pay them money annually your software stops working. Your data will be held hostage. Let me repeat that, your data will be held hostage! If you want access to your data, pay up. Sound far fetched? It's not. This is the direction they've been moving the whole time.
You want to know what steams me the most? It's our fault. Yeah, that's right. The geeks in the trenches. Most of us just accept what comes out, thinking that we don't have a choice but to submit. What a bunch of fscking sheep. Get involved with your management and make yourself part of the decision making process. If you let yourself be rolled then you will be. If you submit to bad software then who's fault is it really?
Is this a rant? Definitely. Is this a troll, possibly. Do I believe I don't have to submit to, or thank, Microsoft for anything? You bet your fscking life I do. No one holds my data hostage.
Gates and Microsoft are not the saviors. They are part of the problem and as long the public lets them get away with it, they will.
"The avalanch has already started, it is too late for the pebbles to vote." -Kosh
A lot of people complain about how buggy software is. And I will stipulate that yes:
(a) Most software produced has scads of inital 'bugs' oozing out of every oriface you can think of.
(b) It's partially due to the fact projects are rushed and coders tend to be careless (My favorite phrase: "Oops... I was supposed to put a semi-colon there")
But I think that if you check it out, alot of these so called bugs are due to people misusing their computers (or someone else misusing their computers). What percent of all bugs that need to be patched are "security holes" that are exposed by people who enjoy trying to break into someone elses system?
A lot of people come out and say that we wouldn't tolerate so many problems in our cars/airplanes/nuclear reactors. Tell me, when was the last time that having ones tires slashed was blamed on the guy that made the car? Or how about car bombs? Are they a defect? How about the guy who gets drunk and drives the car? People die in these cases, but the problems are caused by the end user, not by the programmer.
Programmers are partially at fault. Big business and the drive to survive everyone else is at fault. But lets not forget that most problems start with the nut behind the keyboard.
HUH? Sending too many messages is a problem. Wow. Amidst all the Outlook viruses and buffer overflows, that's the first I heard of that. This guy must have an ordered life.
"The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics," says SRI's Neumann. "If it doesn't spit out an error message, it must be done correctly, right?"
I've never met a single programmer with that attitude since I was in Intro CS class.
Just as houses are built with standardized two-by-fours and electrical fittings, component-based programs are built out of modular, interchangeable elements: an example is the nearly identical menu bar atop every Windows or Macintosh program. Such standardized components, according to Wallach, are not only good engineering practice, they are "the only way you can make something the size of Microsoft Office work at all." Microsoft, he says, was an early, aggressive promoter of this approach -- "it's the single best engineering decision they ever made."
No real idea what he is talking about, anyone else?
. The most widespread example is Windows itself, which Bill Gates testified in an April session of the Microsoft antitrust trial simply would not function if customers removed individual components such as browsers, file managers or e-mail programs. "That's an incredible claim," says Neumann. "It means there's no structure or architecture or rhyme or reason in the way they've built those systems, other than to make them as bundled as possible, so that if you remove any part it will all fail."
It baffles me when people claim this shows no design in Windows. Gates did not say if you took out the email program it wouldn't work, just that if you took out IE it wouldn't. That's because it was designed that way.
At Microsoft itself, according to Amitabh Srivastava, head of the firm's Programmer Productivity Research Center, coders are working with new, "higher-level" languages like C# that don't permit certain errors.
No idea what the PPRC is (new name for the marketing department maybe?), but trust me Windows XP is not being re-written in C#.
"The mindset of the industry is to treat quality as secondary," says Cem Kaner, a computer scientist and lawyer at the Florida Institute of Technology. Before releasing products, companies routinely hold "bug deferral meetings" to decide which defects to fix immediately, which to fix later by forcing customers to download patches or buy upgrades, and which to forget about entirely. "Other industries get sued when they ignore known defects," Kaner says. "In software, it's standard practice. That's why you don't buy version 1.0 of a program."
Deferring minor bugs is standard practice. Otherwise software would never ship. So what does he want? Nice paranoid idea though that bug deferral meetings are actually fiendish plots to generate future revenue with updates and patches.
- adam
Many years ago a programmer told me "I express myself through my code." I've since seen and heard something similar in most coders. Running a software project is like herding cats. So many "artists", so few engineers. When you get rid of the artists you'll see solid code. When you get artistic engineers you'll get awesome code.
And how do you do all that? Start a self-regulating body (with teeth) like any true profession. Doctors have them. Real engineers have them. So why don't software engineers put their own together.
But I don't write code well at all on paper. I can design code in my head or on a white-board, but to actually write the code, I need to be at a computer just as I would imagine that many composers need to be at a piano.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Please forgive bug in parent Subject: line.
Someone once told me:
Software doesn't just appear on the shelves by magic. That program shrink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by way of an elaborate path, through the most rigid quality control on the planet. Here, shared for the first time with the general public, are the inside details of the program development cycle:
1. Programmer produces code he believes is bug-free.
2. Product is tested. 20 bugs are found.
3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.
4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.
5. See 3.
6. See 4.
7. See 5.
8. See 6.
9. See 7.
10 See 8.
11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.
12. Users find 137 new bugs.
13. Original programmer, having cashed his royalty check, is nowhere to be found.
14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
18. Programmer produces code he believes is bug-free.
19. See step 2
UNIX/Linux Consulting
Go ahead, remove my karma points, I don't care. I've had enough already of those idiots who keep wanting to sue everyone for anything. And if MS will actually concentrate more on security and stability instead of features and fun, then I'll go get myself a Mac. I prefer using a somewhat buggy Windows 2000 instead of a perfectly stable and secure Windows 3.1.
Besides, no software is perfectly secure. Perhaps they should concentrate more on suing the crackers.
"The ship had to be towed into the Naval base at Norfolk, Va., because a database overflow caused its propulsion system to fail, according to Anthony DiGiorgio, a civilian engineer with the Atlantic Fleet Technical Support Center in Norfolk."
Find the complete article here: Windows NT Cripples US Navy Cruiser.
So, closed source, anyone ? :-)
I really enjoyed reading this article.
I think that it points out something that we all know: If there is one good thing about free/open source software, it's peer review of the source.
And whose fault is that?
Face it kiddies, when lawsuits for software quality start becoming commonplace, you'd better be able to speak the language of software engineering, quality control, configuration management, coding standards, documentation, and so forth.
And if you think software is the one product in the US that will remain immune to litigation, please tell us why you're so deluded. Because nothing else has ever remained immune.
<disclamer> I don't feel that microsoft nessisarily applies here because of the constant poor quality, I'm mainly talking about companies like Macromedia, Adobie, and the major game developers </disclamer>
Sigs are out of style, so I'm not going to use one...oh wait..
From what I've seen, when it comes to documentation, whether it be long or short, (most) developers do not:
have it,
know where to get it,
want it,
read it,
understand it.
Maybe this has something to do with why (most) software is so bad?
That MSNBC is criticizing the "MS" in MSNBC.
Could MSNBC really be the "fair and balanced" newschannel that others claim to be?
Probably not.....
It would have been nice if the article had delved more into licensing programmers as engineers and the associated affects on liability. In the absence of licensing, liability would be a nightmare.
However, you could create a legal (ie, government-granted) license to engineer software. If the design, as well as some proportion of the testing and coding, of a program were done by licensed engineers, that program would be able to carry a certificate to that effect. You could also exempt from liability programs that made the source code available for review before user purchase of the product.
The government would require, as part of the law, that after some date all government software purchases would be of certified software only, or of open source software that had been reviewed and tested by a licensed engineer, who accepts liability for the product.
The market would quickly take care of the issue. Since only software carrying the certificate would be subject to legal liability, companies would simply not deploy software in critical areas if it did not carry this certification, and software that did carry the certification would be forced by the liability to get better. Also, developers would only be subject to liability if they claimed the certificate, so that amateur projects would not be subject to liability.
These rules in combination, and better thought-out than I have presented them here in outline, would tend to make software better, as either the program would be open source (and thus peer reviewed) or it would be subject to liability or it would be unable to make a reasonable profit (since corporate and government customers wouldn't buy software that was not subject to liability).
Further, there would auxiliarty benefits as well. There would be more of a push for standard components, because there would be no reason to reinvent them. (Right now, there are profit and market control reasons to do so in many cases.) There would be more examples available for new programmers to learn from. There would be less testing required by companies that purchase software (my company spends about one fourth of its project budget testing the off-the-shelf software used in the project).
-jeff
-- Two men say they're Jesus. One of them must be wrong. - Dire Straits
"Game developers are frequently rushed to the point of putting out a sub-par error-riddled game because the publisher wants the game out on schedule, not when it's ready."
Like Duke Nukem?
Look,
All he's saying is that changing languages ain't going to fix the problem.
Ya wanna know why?
Because the problem isn't one of compilers, or ironically of technology.
Its an attitude and approach problem. Its the lack of peer review of architecture and design that is the problem.
Let me put it in a form that even you could understand:
Take the smartest, best programmer in a room. Let me come up with a solution to a non-trivial set of requirements using whatever language you think "helps".
I guaran-g*ddamn-tee it that the program will suck. It may suck obviously, it may suck subtley, but it will suck.
That's because one person isn't smart enough. Albert Einstein didn't figure it all out. Its through peer review of design and architecture that you get results.
And the magic number is 3. Three smart architects or designers will change the world. One smart guy will just hurt himself and do something that has a high suck quotient.
There is nothing more disingenuous in this article than Nathan Myhrvold's statement that: "Software sucks because users demand it to." Talk about shifting the blame. Take some fucking responsibility, fat pig.
Let's do some more quotes, hmmm. From http://users.aol.com/machcu/mspquotes.html:
The ever-growing size of software applications is what makes Moore's Law possible: 'If we hadn't brought your computer to its knees, why would you go out and buy a new one?'
-NATHAN MYHRVOLD, Group VP, Microsoft
The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard.
-BILL GATES
--Lawrence Lessig for Congress!
My sentiments exactly. Good call, my friend.
"I have lots of thinkgeek (TM) shirts and I wear them all the time so people think I'm a Linux god. It's scary when I come across someone who actually knows what he's talking about - then I get very nervous and try to keep out of sight. In my free time, I write horribly ugly and unmaintainable perl because it's the cool thing for 'geeks' to do. I claim to know both C and C++ despite only the most rudimentary grasp of C and no experience whatsoever with C++ (what are templates?) I think that it's cool to write perl and make it look as complicated as possible - not for any good, functional reason, but to impress others who are looking at it. I know absolutely nothing about good software design patterns, and disdain languages like C# and Java for being too high-level (despite never using them). My case is covered with stickers I got from thinkgeek ("FOO" and "UNIX"), so I can show it off to my friends and feel important. I don't have a programming job because I'm nowhere near good enough, but I do work as tech support operator. I tried to convince my boss to replace our company's 200+ machines with Debian GNU/Linux, but he said that users needed a standard set of powerful applications. What a moron! With the source available, anyone in the company can fix problems (or add features to) any program on their machine - I'm sure they have nothing else to do with their time. My boss just has no business sense..."
boo-yah!
From:
"When PC Magazine tried in 1999 to run a head-to-head comparison of Oracle and Microsoft databases, Oracle used the license terms to block it"
Of course...MSNBC wouldn't check the Microsoft Database product...
From:
"e. Benchmark Testing. You may not disclose the results of any benchmark test of either the Server Software or Client Software to any third party without Microsoft's prior written approval."
Kombat's Law:
Before, the customer wanted a library of CGI scripts to run their e-commerce website. Now that've got a handle on scripting design patterns, the customer wants EJBs. By the time you learn what to expect to go wrong with EJBs, the customer will want a cell-phone interface to their inventory.
Observation on Kombat's Law:
Technologies become fashionable soon after they are introduced, usually when the libraries are still version 1.0 or one-point-epsilon.
Related observation on the software industry:
It's standard practise to push a buggy pile of kludges still in need of major debugging out the door to meet overly optimistic deadlines and call it version 1.0.
Sum conclusion of it all:
We're all fucked.
Those who like to use exciting new gizmos are even more fucked. Those with bosses who are attracted by shiny objects are the most fucked.
One of the possible solutions that was presented in the article was litigation, which, according to the article, is inevitable and coming soon to a software company near you. But one of the problems for the plaintiff outlined in the article is the fact that many of the problems with software that one might sue the company for are highly technical and would require the hiring of expensive computer experts to build their case. I was wondering if Slashdot, a site with numerous computer experts, could help build such a case by providing expert analysis? Obviously there are some problems with that, such as the lack of being present in court, the safety of anonymity, the unfailing bias against anything Microsoft or even anything proprietary (I don't think it goes over well in court when you roll your eyes and say "That's what I've been telling you for years. Idiots." You know what I mean?). I'm not a lawyer, so I can't think of any more problems with it, but somewhere in there is a good idea waiting to be used...
Lack of eloquence does not denote lack of intelligence, though they often coincide.
I think software sucks because people don't care. They don't consider reliability when evaluating solutions, at least at the consumer level.
Cars is a great example, in the past they were terribly unreliable, and people didn't care, they still bought them because they wanted the product despite its flaws.
Now we have consumers who want reliable cars, and they make more reliable cars. This is the way the market works, companies produce what people will buy, when people stop buying unreliable software, the companies will make more reliable software. As long as you keep buying it, why improve?
From article:
"Software sucks because users demand it to."
Does anyone remember signing that petition? I sure don't. Maybe we should get a counter-petition going and give this guy a clue.
Last I heard, the demand was for software that did its job, and didn't crash/return errors/suck constantly.
http://thechubbyferret.net - Ferret pictures and informative links.
On the other hand, in applications where stability and predictability are far more important than new features, software quality is excellent.
Automotive metaphors for computing are almost always useless but since the article relies on one -- cars may run reliably, but the AM/FM radios they put into them are frequently useless. Does anyone complain that the automotive industry included them for decades, instead of waiting until cassette/CD players were available?
What I'm listening to now on Pandora...
Most bugs are found by the developers themselve while doing code review, this help if their schedule have time geared toward review and not only coding.
Then using the right programming langage and the right engineering practice help.
Most modern langages don't suffer from buffer overflow and have eliminated most memory leaks. Increased support by tools af design by contract and the like will help.
Good testing practices like those used in JUnit (unit testing) help tremendously too.
To their own amazement, these people have found themselves wondering if the real problem with software is that not enough lawyers are involved.
The reason most buggy software is put out the door is because it's cheaper to release buggy software and deal with angery users than to spend more time fixing it. I bet if these users started suing and hitting software developers where it hurt, in the pocket, then software companies would start shaping up and putting some more effort into their software.
Outdoor digital photography, mostly in New Engl
It sucks!
There, and no one can sue me because I didn't buy it, I pirated it.
--just general comments addressed to no one in particular--
--I'm not a coder, but I am a consumer and user. I have spent cash on computersw since the 80's. This article is right on! There are WAY TOO MANY TITLES out there now. What is needed is far fewer releases of alpha software that is mis-labeled as beta or "stable". It's blatant consumer fraud, and was partially addressed in an earlier slashdot discussion on liabilities and the lame EULA nonsense. Maybe PROGRAMMERS don't mind buggy stuff, but buy a clue, most folks AREN'T programmers and as consumers are getting turned off. Just yesterday I was at an auto parts/repair place, talking to just some "normal folks". NONE of them had anything nice to say about computers or the net in general, even though all of them had been exposed to it in one for or another. Their biggest gripe with computers? THEY DON'T WORK with the software they get. Get it? They DON'T WORK AS ADVERTISED. The one couple I was talking to are keeping their two boys completely away from computers because after one month online they were totally unable to keep their children from even accidentally seeing porn and worse. You can't have any email account and not get spammed with porn and viruses. You can have all the firewalls you want, most folks are still gonna get nailed with trojans. None of those lame filters work, and violent video games are just stupid and a waste of time for children. They don't WANT to be a programmer or a beta tester. And this means the OS AND the apps. BOTH. I know several people who have just given up on computers and closed their internet accounts-the hassle with virus coders never getting arrested and STOPPED, and then buggy programs and buggy OS is just too much. One of those folks was saying how despite having the latest and greatest, they spent serious folding green on both a PC and on apps, including anti-everything- they still had to unhook all the wires, haul their PC into the shop, and pay someone 60$ an hour to fix it-not from the hardware being broken, just bad OS and virii. Why is this still happening in 2002? Really, why?
I'll answer that, it's because the mindset of the programming community is "nothing is my fault". Well, it IS the programming communities fault! If it's not your fault, how again exactly is it the consumers fault? Because they aren't programmers? Because the average person really has no interest in spending time everyday upgrading and patching? why should they? Would you fix your car EVERYDAY? No? Then why are we as consumers forced into doing that with computers?
The computer market needs two things, black hats need to go to JAIL for years and years and years, and it's NOT happening and the coding community is HIDING the blackhats in their midst (generally speaking here), (I can guarantee one of you blackhat assholes is reading this you jerkoff) and OS and software companies need to be FINANCIALLY LIABLE for their products working or not working, same as any other product. Stop releasing stuff you know isn't working. And that goes from whopper companies like microsoft all the way to the one guy shop.
Take it from people who are one way or the other providing your paycheck coders, STOP releasing crap that doesn't work, enough with alpha and beta software. WAIT until the stuff actually *works*, THEN release it. If it means you have to code another month, do it that way. This is called the better mousetrap idea. If you need a programmers guild with some basic common sense minimum guidelines, then do it. You've had plenty of time to get your programming act together, and you have been well paid over the years-again generally speaking. You WILL make money if you can all just develop better stuff BEFORE you release it. Computers and software should NOT have to be upgraded every two days, this is totally bogus. And if you are a blackhat, stop it. And if you know of any blackhats, swallow your ego and pride and TURN THEM IN to the police, enough's enough. Failure to turn in criminals is in itself a crime, didja know that? Well it is in most places/states in the US. And I would bet a years pay every self described "whitehat" out there knows at least one blackhat, and you probably don't do anything to stop them. We as non programmers really don't know who they are, BUT YOU DO. Do your civic duty. If I knew some guy who was raping women, tough luck, I'd turn them in. Or a home burglar. See? It's up to you guys first to help clean up the net and make basic everyday computing better and more secure, not more complex, more buggy, and less secure.
Part of the problem might be the fact that most of the programmers are Comp Sci, and not P. Eng's.
I say might be, because I can't speak for Comp Sci programs, but I know what most engineering programs will drill into you as far as standards and quality control. Anyone who has the experience to provide knowledge of what's taught of QC in a CS program, feel free to correct the "might be" part.
For all of those P. Eng's in software and systems out there, I strongly advise you to NOT sign off on faulty software. In any other field, only the most unscrupulous P Engs would even consider signing off on a project with major flaws.
And remember: if you're hired as a P. Eng, being fired for not signing off on a project because of quality issues is clear-cut wrongful dismissal (at least in Canada).
Dark Nexus
"Sanity is calming, but madness is more interesting."
lots of software sucks, because a lot of software companies didnt spend money, time and effort in building a good software QA team. Also, the software QA team are often burned out rushing to test a product at the last minute, plus no recognition for their effort.
Just look at your organization, when is the last time your software QA team get recognition? more likely, your software development team, follow by sales or marketing
Will people stop spouting off about needing production line reliability in software development.
The software equivalent of car manufacturing is stamping a CD. It's very reliable. What software developers do is design, not manufacture.
The problem is that they ship half baked and unfinished designs (that they call products) without really thorough testing and refinement.
Have a look at the concept cars from an automobile design shop. How reliable and safe do you think they are? Its only after a couple of years of prototyping and testing that they have a design that they would risk manufacturing.
The problems with software stem from manufacture being too easy, not too hard.
Software companies could build a rock solid word processor or PIM , even MS, but no one will pay for it. We all scream that the retail price of MS Office is far too much. The corporate world looks at the per seat cost of MS and say, "I wish we could switch to something less expensive." Every product has a price point and software has a very low price point.
The odd part of the problem is the marginal cost of production. As we all know, once the development is done it cost next to nothing to produce. Once a producer has a product that the market will pay for there is little incentive to keep droping millions into making it much better. We would all love to use perfect" software. If "perfect" software can only be done using "traditional" engineering approachs such as is used in aircraft design that means putting massive teams on a word processor. Each team does one function including the code, hand checking the machine output from the compilier, checking it's performance againsta massive design document. We all know the story of how this kind of effort almost sunk IBM. Computer science has progressed to the point where massive effort should be able to be implimented, but no one would be willing to pay for it.
The article claims that the defect rate is going up, and software used to be of high quality. Nonsense. The defect rate is the same as it always was - there is simply 3 orders of magnitudes more code these days in a typical application. I would hope that an embedded system made in 1978 with only 512 bytes of instructions ought to work correctly - you can practically assemble it in your head. Reporters - get a grip. People want cheap software, features, performance and reliability - in that order. Market forces have proven it.
In fact, I remember Gates several years ago bragging about how he prefers not to hire CS grads because they come out of school with too many limitations programmed into their brains.
Yeah, limitations, like how to write good code, how one should avoid side effects in functions, write black box functions, learn how to develop testing functions to push a full range of possible inputs to functions to test them, how to document properly, etc, etc.. You know, all that stuff that cuts down on the number of lines of code per day a programmer pumps out...
Also knowing a bit about bulk mailings, the problem could stem from "Apricotland" not having a Post Office.
In our area, we have a community within another incorporated city's zip code. Anyone within this zip code may choose either city as their home, and mail gets there.
But mail arrives faster if you spec the correct city or use the Zip+4... because the mail doesn't have to traverse an extra postoffice to get there.
-sid
I wonder why people - especially IT Pros - often just don't get it:
The gap between now and an age where computing is a subtatial part of cultural techniques in a way that we can't do without anymore is about as big as the gap between the stone age and the industrial revolution. Aside from the fact that technology evolves "a little faster" now, that is.
In 100 years people will remember those awkward times when people fought for "Browser Standards" or some other stuff - just like when Tesla and Edison fighting over which type of current is best. Nobody would even consider rasing the debate nowadays - because it would seem (and be ) utterly silly.
We have Zillions of Standards and Platforms that have such a short lifetime that they will be considered something like experimental sidesteps in 50 years from now. Considering the fact that IT is redefining itself every odd year - just like, lets say, the railroads in the beginning (anybody know how many trackwidths they had back then?) - the discussion about why "Software is bad" or if it's not, is somewhat pointless.
We suffer more in our imagination than in reality. - Seneca
But it's hard to convince someone trying to make money that their programmers, regardless of previous experience, will not be productive from the first day at work because they need to be coached into the company's own standards.
They would prefer to have them producing code that works, as soon as possible, even if it means bringin into the code repository their own habits, good and bad, picked from their previous jobs, school or their intestinal tract.
If a manager at a construction company is building a bridge, it is likely he will not be satisfied JUST because the bridge seems solid. If the bridge looks unlike anything he has ever seen, its structure defies comprehension, and he's not entirely sure the thing stands by anything more than chance or will survive the touch of a maintenance crew, there will be hell to pay.
On the other hand, if the software works, the manager is probably satisfied.
This may not have as much to do with the programmers' or managers' discipline, but with two other simple facts:
a) Everyone knows how a bridge should look, and if it looks any different (new design), they will be extra-paranoid about it. Soon the new design will join the ranks of ways a bridge should look, and there are not that many.
b) Most of the bridge's features can be seen at first glance, without a peek at the designs.
On the other hand, concerning software:
a) No one knows how software should look. There are a million gurus who think they do, with a million different versions. Given a piece of code and an expert, he will be unlike to tell you if it looks solid or not at first glance, so a non-expert will judge by whether it executes or not.
b) Most of the software's structure is hidden from view in the final product because software is not physical. It's all design. Judging the quality of software, even if you knew what to look for, will depend on a through review of the designs (code) which is as likely to happen as a voluntary visit to the dentist.
Freedom is the freedom to say 2+2=4, everything else follows...
I didn't know about the restrictions McAffee imposed on it's user. But since I'm an X-User, I guess that no longer applies to me :). Their firewall seriously slowed down my cable-connection, making me a very unsatisfied customer and instantly switching to Norton, which is good!
--I was sub contracting to an independent mainframe guy in 1985, he first told me of the y2k deal. He assurred me the new boom in desktop pcs would have it fixed.
.001b all the time.
Well, it WASN'T, and programmers cost this countries economy over 100 billion dollars because they KEPT CODING IT IN for 15 more years. ya, ya, I read all the excuses, "my boss wouldn't let me", etc. Phooie, that was a cop out then. More of the "it's not my fault" syndrome.
Programmers need a guild or a union, and they need to make quality job #1, not just releasing billions of bytes of crap with numbers after it, like bugs_b_us vs.
I'm reminded of another industry that relies on software and hardware. The console gamin industry while slightly different because the hardware is more stable, still has similarities. Just take a look at Nintendo. People may gripe at how they take too long to release software, but they make sure they get it right. If it goes to play testing and a tester says that the software dosn't "feel right", it goes back into developement for another few months. Not to harp on them too long, but take a look at Zelda ToOT. That title took 3 years to make. Conkers BFD took 4 years.
To be honest, I think its more of a cultural thing than anything else.
13 year old white supremacists are shitty web designers.
This was indeed one of the first things taught at University: syntax error - easy to fix/find and easy to avoid (yet I still forget the occasional semicolon), and semantic error - hard to fix/find and easy to avoid (provided you thought about your design).
Any school not teaching these idea's, isn't doing any good to it's students.
I guess being a C/C++/CORBA programmer for a living who has in fact contributed to open source projects doesn't mean much. (Actually, I assume you'll just ignore this line, or say I'm lying, or whatever suits your fantasy world.)
/. code is crap. I dont doubt it. I'm just going to do everything I can to annoy those who criticize labour of loves because they desperately need a reason as to why they have no personal investment in what they 'produce' for a living. If you havn't got anything constructive to say, you're no better than those who construct crap.
If an avoidance of realistic evaluation is a common Slashbot trait, I can assume the ACs have mastered presumption of character.
I'm sure the
Asides, when we are both taking time out of being productive to sling mud at the walls, its hard to accept that somehow you are productive, and I am not. The difference is, I place my name beside my words. Productivity doth not make the man - the balls to accept accountability for what one produces does.
"Old man yells at systemd"
I read an article a long while ago in one of the trade mags that talked about this.
According to the article, software is so bad because it takes legions of software designers/coders to put out the latest version of SoftwareX. The reason it takes legions is that software has become so complex. You used to be able to install Word with a couple of floppy diskettes. Now you need a CD.
Where did the extra 600 Meg come from? Spell Check, grammar checking, clip-art, spread sheet functionality, clip-art creation software, fonts, thesaurus, templates, auto-correct (like spell-check isn't enough?), macros etc, ad infinitum.
Developers spend their time writing new functionality, instead of fixing the broken "slightly-less-than-new-functionality." So, why are they doing this? Simple, because their managers are looking at their artificial time table, and saying "We promised this version would be done by (insert artificially generated date here). We need to get it done yesterday." (Side note here: Apparently, to stay competitive, companies need to release SOMETHING new every 6 months. If they don't, they die. Notice the emphasis on SOMETHING.)
When the development team finishes their newest widget, it heads off to a completely separate team of QA specialists who don't actually understand the interoperability of the new widgets. They miss things. Managers know this but they think, "Well, we can always release a patch later." In really large software companies, this patch is created by an entirely separate team, who had nothing to do with the product's creation in the first place.
Most of the time, the patch team has to consult with the original development team to create the patch. Unfortunately, the original development team isn't available to talk, because they are creating the next great widget for the patch team to fix in 6 mths.
Never mind "Help" files.
It's a complete wonder that we actually get anything that works at all.
So, why do companies do this? Why does Word have clip art creation capabilites? Why does it come packaged with a Thesaurus and a Dictionary, when they are both online, and Webster's Dictionary is the third best selling book of all time (third to the Bible and Quotations from Mao Tse-Tung, which was compulsory reading for all Chinese from 1966 to 1971, Source)?
Simple - you asked for it. Companies have spent hundreds of thousands (dare I say millions?, okay. Millions.) of your dollars on determining what you want. You WANT spell checking. You WANT clip-art creation. You WANT better, faster functionality, and you want it NOW!!!!
That's right, the crappy software is YOUR fault. The &$%@&^'ing OFFICE ASSISTANT is YOUR fault!!
You have nobody to blame but yourselves. Don't you feel ashamed?
BTW: If you don't believe me on this - Our company had over 300 phone calls to our internal IT help desk within a week after moving to Win 2000, because we didn't load Solitare on the computers.
The Dopester
"Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
Real programmers ship. (quote from un-remembered source)
You're right, and it's a shame. In all of the programming courses I've had, the grading criteria are simply "Are there any errors generated?" and "Does the output look correct?" Nobody takes into account that a programmer might have done something sloppily, inefficiently, or even in a way that might be dangerous.
Programming classes at my university need to concentrate more on programming theory than on correct syntax. We can pick the syntax up along the way, but bad programming style will stick for a lifetime.
-- "Complacency is a far more dangerous attitude than outrage." -Naomi Littlebear
I can agree that most of the software I've used on my PC has had at least a few bugs. It's worth noting that I run nothing but OSS/Free software, so this can't be pinned on MS.
However, most of the software I've used that wasn't on the PC had no obvious bugs. I found one bug in Tony Hawk's Pro Skater 3 that involved a reflection in a window in an out-of-the-way location being rendered strangely. Other than that, there were no bugs. It's really pretty rare for me to find a bug in any video games, actually. The software I use on my Visor is the same. And I've never had my synth give me any problems. Now, obviously, all of these other platforms share one thing in common: they are not moving targets. My PS2 is the same as everyone else's. There are a few models of Visors and Palms, but generally, they haven't changed terribly. And a Korg X5D is a Korg X5D no matter where you go. This, I think, is the major problem with PC software- the hardware and software environments are always changing.
Anyone that's written software for Windows knows this is a gigantic problem. I wrote a simple program that used the WININET API, and the functions to open a connection worked fine on 98, 2k, and XP, but not at all in ME. The CreateIconFromResource function wouldn't work at all in 2k without installing the service pack. While working on this program, it became painfully apparent why end-user software doesn't always behave as expected.
where it belongs, on the shoulders of the software manufacturer/publisher.
If anyone goes bankrupt or dies from using your code then YOU are responsible for their fiscal or physical death and deserve the fines, jail time or death penalty that a jury will hand you.
If you want software quality, you have to wait because it takes the time it takes. Infact, that is the power and promise of open source. By not being dependent on a single source for the software and not being limited by the same source for product design and evolution, software can develop much more rapidly into much more robust products.
Software created to solve a problem has a chance to evolve into something safe, secure and usable. Software created just to make a killing has a chance of killing somebody.
You'll have quality software when people can't create it to make a quick buck. That's the power of open source.
Regardless of how big a pile Bill Gates amassed unethically, ripping off unsuspecting buyers by arm-wisting and back room dealing with the PC manufacturers.
Cmon. NOBODY WANTS to BUY blue screens of death, no matter how pro-M$ and "Fuck You Steve Jobs and Linus" they might be.
Not even "Manic Monkey Boy," "Barmy" Balmer particularly WANTS to SELL 'em. But he DOES want the money. He does indeed. He gets wet dreams about his stock market share value.
But now, to save our lives, we have to make sure that NOBODY can sell BSsOD.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Popular software isn't reliable, because reliability isn't the highest value. Compatability with a legacy is (e.g. you want to run this application under MS Windows?). Or cheapness (e.g. Do you want to be billed 2 hours of my time (very little testing) or 6 hours (more testing)?). Or having lots of features (Would you like a flight simulator with that spreadsheet?). Or something else.
When reliability is important, you can have it. But it will cost you. Most people consider the cost to be too high. That's why more people run bleeding-edge Linux, Windows, or MacOS, than OpenBSD.
And there's nothing wrong with that. You just have to accept/enjoy the power/responsible that goes with the choice that you made, instead of whining that someone else should have chosen for you.
Irresponsible XP users whining about XP, ispartcularly pathetic. Yeah right, you didn't know what you were getting into. You never heard of this "Microsoft" company before, so you just assumed that they valued reliability over other considerations. Discovering that it was crap primarily intended to play video games and keep MCSEs' jobs secure, was like a cold knife in the back -- such unexpected treachery!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I don't think "misuse of copyrights" is quite correct, but not being able to see under the hood is a standard argument against closed source. Surprisingly the article didn't directly discuss open source, but I thought the following part was pretty interesting:
"Not wanting errors to cause delay, coders -- who in the early days tended to be trained as mathematicians or physicists -- stayed late in their offices exhaustively checking their work. Writing software was much like writing scientific papers. Rigor, documentation and peer-review vetting were the custom."
Nothing that hasn't been said before, but probably something that isn't said enough. Open source, collaboration, and peer review are not new ideas and sometimes proponents do disservice to them by acting as though they are new and revolutionary. They're not - they're a throwback to a time when software was simpler and more robust.
As programs became increasingly large and complex it became near impossible to take advantage of peer review - you couldn't ask a fellow professional to check your million lines of code. Without a good way to peer review large projects, it makes sense that software became increasingly reliant on a proprietary closed source approach and also became increasingly buggy.
Using the communicating power of the Internet, along with the growing open source community, programmers (and managers) can now apply peer review and collaboration to these much larger and complex projects. This development should be embraced (and promoted) as a return to the roots of effective programming, rather than as a whole new paradigm. While there are some fundamental constraints to testing programs, we should expect that the proper application of engineering techniques along with this somewhat unique ability to use peer review and collaboration could actually make software more robust than other technologies.
My next sig will be ready soon, but friends can beat the rush!
I have seen this for Decades. Not Years but decaded! Every few years there is a scheme to try to make somthing ovious ovious and failes. I have program just about everthing from A to Z more than once. Each is unique and different.
1) Know what you want and where you are going! You CANT program in the dark or a vaccum. It must be in the mind before its in code. Like a panter or sculpture no ideay nothing on media.
2) Tell marketing to get its order in early! Else get lost!
3) Build on solid sections. Not quicksand or swamp. Else you will sink!
4) Think a few seconds on it. Measure twice cut one.
5) Value Engeering. Remove all parts not need to function.
6) DONT OVER-ENGIEER IT! This creates bloat and each line of code can be a bug.
7) Bandages are for human not programs.
8) Solid core first. Fluff never!
9) Programming does not conform to the physical world and cant be times.
10) Never ask a problem if its a problem. It always lies!
11) Tie modules through some easy to interface key connections. Complex interfaces creates bugs. Look at a 74xx TTL series chips. A ton of ccompanys make it internally there way but they all interface the same. Simple.
12) Just because X company has that in their product does not mean you need it. Greed and envey is bad!
On the last one. I had a program that was simple, elegant and worked. Did not have the ten billion unneeded features the other had. But mind did one thing theirs did not and that it did not fail on the main function the client bought it for! There is too much junk out there that makes a Swish Arm knife look like a piker on functions Esp when all you want is a blade to cut somthing.
Windows should not be a be all-end all everthing but what it started out to be a std user interface. Not a Swish Army knife with blades for everthing. That is marketing talking over engieering and leads to disaster.
A car has been engeered to do one function very well in a certain window of opperation. It does not fly, float or darn your socks but gets you from point A to point B. Same for software. A compiler uses this concept. Anything not inside its fence is an error. Simple. Windows... Too much trying to do too much and failling at it core function.
I recommend two books:
Mythical Man Month.
Code Complete.
Both have solid what works and what does not examples.
My last car used to go "beep" when it ran low on gas. I hated it. I wished it had a parameter somewhere that I could tweak and make it not beep. But having that parameter would mean increased complexity for the car. And complexity would mean more things to break, more places where bugs could creep in.
Software engineering is a relatively young discipline. Still, it exists, and it lays down rules and methods for creating software.
The reason most software has as may bugs as it does is not a matter of not having the tools or the methods, it's largely a matter of not using them.
Take the smallest piece of software possible, a "hello world" program, for instance. It it takes no input and just prints the string, there are very few places a bug can creep in. Even so, you have to be able to ascertain that you do have a standard output on which to write. But the minute you have to process the command line, you start increasing the complexity of your program, and immediately raise the risk for bugs.
Many bugs happen at software interconnections. The calling of functions, the invocation of an API, the parsing of inout, the access of files and devices. Why does this happen? Largely, because there is no clear contract on what the caller is supposed to do, and what the called function is supposed to accept.
One of the largest causes for bugs is lack of a formal contract between every two pieces of software, between every two parts of code.
Lack of existance, and lack of enforcement. If a function is supposed to return a positive integer between 2 and 8, why does the function itself not validate that its output is always within the range?
Some languages, namely Eiffel, impose a form of "programming by contract", in which both parties of any software interaction validate their own inputs and outputs, and check each other's, as well. But we can take this a lot further. Capabilities based operating systems. Deep granularity in software capability attribution. If a piece of code never needs to access the file I/O functions, don't let it do so.
One idea that comes to mind is the notion of a public key based operating system. Issue key pairs to every piece of harware, to every device, to every directory. Then issue key pairs to every program, to every major block inside every program. And then use a broker to validate every program's access to every device. If a piece of code wants to write to memory, it must code the data in its own private key, and access the memory using the memory block's public key. But don't just make public keys available. Grant them only after approved requisition, as you would in a capabilities OS.
There are many ways to improve overall quality and safety of sofware. most of them already exist. It's a matter of using them. It's a matter of getting powerful buyers to enforce the usage of advanced engineering practices. The government should set the example.
free the mallocs!
I think the article has it right with respect to lawsuits, and the current pass companies seem to have wrt accountability and quality in their software performance. I can envision a future in which companies buy each other's product, beat the crap out of it, and if it fails to perform as advertised, sick a team of lawyers on the offending producer. Think of it as greenmail for the software industry.
The point of "no silver bullet" and "still no silver bullet" and indeed the awesomely brilliant Mythical Man Month is that no one thing will ever be the silver bullet and that the most important thing are the people. Doing one of these things won't help but doing all of them certainly will. Peer review doesn't replace compilers though, its about bugs not semantic and syntactic errors.
Fred Brooks was and is right, but that doesn't mean the processes of good software engineering are wrong, just that its a combination that will deliver success with smart people.
An Eye for an Eye will make the whole world blind - Gandhi
okay, I must have stepped into a new dimension
I can't believe it's not lard!
This has been one of my longest standing gripes about my profession. I've worked a tiny companies and huge companies, and I have yet to see any one who builds good software. Just like the article states, this is due to the gap concept between first and second place. It also has to do with money issues.
BUT, to date there really hasn't been any (or very few) instances that would provide a contrary opinion. In this I mean that there have not been two competing companies, one who frantically gets their product to market and the other that spends time on engineering.
I would go as far as to say that if this happened, and the company who engineered their product better, would probably come out on top, even though they released second. The customer would have more features, more reliable use and probably a better looking and usable product.
Guess this remains to be seen.
Brian Pontarelli
CEO and founder of Inversoft.com : Invert Your Mind
AC makes a good point.
As Microsoft's online Knowledge Base blandly explained, the special backup floppy disks created by Windows XP Home "do not work with Windows XP Home."
Very, very funny. And rather familiar - MS-DOS 3.x included a backup program which created floppy disks that could rarely be used for a restore.
That's just plain irresponsible. If you can't get the feature to work right, don't include it!
I know this doesn't address the software engineering concerns, but this quote from the article sort of ticked me off,
"In most engineering fields, Pfleeger says, such disasters trigger industrywide reforms, as the collapse of the World Trade Center seems likely to do for fireproofing in construction."
The fact is, from everything that I've seen and heard, those buildings staying up as long as they did is a *testament* to the fire protection installed in the buildings. I believe they had asbestos covering at least a portion of the metal beams (seems like they had to switch to a different form of insulation at some level, maybe asbestos wasn't allowed anymore?). Regardless, the fact that a building falls down when you run an airliner loaded with lots of jet fuel into it does not speak badly of the engineering practices, and it's sheer stupidity to suggest otherwise. There are lots of reasons to examine fire protection in this country, but 9-11 is not one of them.
The disheartening trend for CS to be an "easy major" is not common at all universities... I know that the CS program I am enrolled in at my university is considered one of the very hardest majors available at the school.
5. All 2nd-generation coders are laid off and replaced with $1/hour replacements in India. The CEO buys his seventh yacht a few months later.
Seriously, though, I think the largest problem in software design is that the people who ultimately make the major decisions have no idea what the hell they're doing. The suits issue an edict, and the programmers are the ones left scrambling to cover the big holes left by forces such as common sense and the laws of physics. Software, at least in big business, is ultimately controlled by people who don't understand it. And therein lies the problem.
The article misses a few points, but otherwise gives a good explanation of why software has devolved from engineering to hacking. The primary cause for this state of affairs is a lack of design and testing, and every programmer needs to seriously consider what they do and how it's done.
Blaming it all on "management", however, is naive at best. Yes, managers want everything now and have no patience for planning beyond the end of their budget or product cycle -- but programmers themselves have a real responsibility for the quality of their work. In too many cases, the professional discipline that was computer programming has devolved into amateur hacking. We take more pride in cute little tricks than we do in writing solid, maintainable code; a pretty user interface may be unusable, but it looks so nice that managers and consumers ignore or tolerate underlying flaws.
Free software suffers from such problems as well; read the daily mailing lists for the Linux kernel, or the GNU compiler collection, or any large "open" product, and you'll see that many eyes do not necessarily mean better software. Someone finds a "bug" or wants an enhancement, so they dive in, create a patch, and submit it, without any real concept of how the new code fits into the overall product. Ever wonder why so many "free" software projects lack documentation? It's because the programmers are more enamoured of coding than they are of design and writing.
Not to say that I haven't made my mistakes over the years, or that my software is perfect. In many cases, "mistakes were made" because I was programming as a job, where my paycheck wasn't determined by the perfection of my code. Writing books is no different from writing code for an employer; time pressures and the need "to get to market" supercede any requirements for reliable code. Until we change priorities as an industry, I don't see the quality of software improving. Programmers (like all people) are only as good as their environment and ethics allow them to be.
All about me
Most of the time it's some other process that causes my computer to lock up in Windows (in the rare occurences that it does). I've had many many third-party apps kill my computer and I've subsequently dumped them, while I've never had a total freeze from Windows XP (Granted, this is a new phenomenon). However, I have had several unexplainable lockups (big, full-system lockups) in RedHat...
But I thought they were asking us where we wanted to go today.
Nope, no sig
There is a tremendous difference that these kinds of analogies ignore.
Software IS different from non-software engineering, in that it is mutable. You CAN make changes after the fact.
Some of your points are valid (impossible performance requirements, and users forgetting what they specified), but comparing construction of software to construction of a building is one of the most incorrect (and unfortunately common) false analogies in the trade.
If you disagree, and you are a coder, programmer, analyst, software architect, or software engineer, I challenge you: for one month, do your job according to the constraints imposed by the world of building construction. I'm guessing I'll get no takers.
That's like sacking a church "just because you can." Just because you have an idea is a LOUSY reason to waste time on it if there's no demand.
And open the source and welcome people into your consortium rather than pretending that you can do it all and watching your enterprise go tits-up when you find out that you're bad at something or other.
The pension funds of millions of people have been decimated because some moron, or worse some shifty lawyer-type, comes up with "a bright idea" (like an Enron,) without first checking if its a wise idea and people buy into it without first checking if its a wise idea...
Everybody was criticizing Warren Buffett for not rushing into the Web craze. He never saw a business plan he could back or a company management team he could respect.
Do you know how much money Warren buffet lost when it went bust? Zip. Nada nothing.
Do you know how much he didn't lose because it never made sense to him to take Berkshire-Hathaway finds and sink 'em into the dot coms? He's still a billionaire and rock -steady at it.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
The article misses a basic concept. People LIKE THE SOFTWARE that they are using. That explains why they are not suing en-masse for stuff like the "I Love You" virus. That explains why they are still demanding more and more features.
The day they create a law for software development, and the pace of the industry slows, there will be an OUTCRY among customers that they want new feature XYZ. Customers will get the law repealed so they can have the new buggy feature.
Customers have made a decision with their check books, they have decided that buggy software with lots of features and security holes is more important than secure/stable software.
Just like the drug problem, this is a DEMAND issue, not a SUPPLY issue. Cutting off/regulating the SUPPLY of crappy software isn't the answer you have to educate consumers so they know why they should want stable/secure software. If you cut off the supply, people will start buying software with the features they want (on the timeline they want) online from places that are not limitted by these laws/regulations.
I find it really stunning that jamie, one of the Slashdot editors, has posted such a comment. It shouldn't be stunning at all; and if jamie thinks it is, I wonder about the relationship between Slashdot's editorial staff and OSDN (the company that owns Slashdot).
Presumably, MSNBC wants to be regarded as a journalistic enterprise, and not a marketing instrument for their owners. That means that they must scrupulously and uncompromisingly see to it that the commercial interests of Microsoft and NBC do not interfere with their editorial decisions; if they find it newsworthy to publish reports critical of their owners, then they must do that, and let them suffer the consequences. Anything else would be a scandal, and a devastating blow to MSNBC's credibility.
Not to say that this doesn't happen to journalistic businesses sometimes, but when it does, it is properly viewed as corruption, and the reputation of that business deservedly suffers. A good example of this is portrayed in the film The Insider with Al Pacino and Russel Crowe. It's about CBS's attempt to quash a "60 Minutes" story exposing the tobacco industry's deliberate efforts to make cigarettes more addictive than they already are, because they feared getting sued, and because (IIRC) their parent company Westinghouse was planning a major deal with Brown & Williamson. CBS was villified for it, and deserved it. I recommend the film highly to anyone interested in freedom of speech and the duties of the press.
But jamie thinks that such a thing is really stunning. I hope that, despite that, there is a similar wall standing between Slashdot's editorial decisions and the interests of its owner. If someone submitted a story to Slashdot that's critical of OSDN, would they publish it?
Always keep a sapphire in your mind
#define LAG_JUSTIFICATION 6
/= LAG_JUSTIFICATION
while (OPEN_SOURCE_PRODUCT_VER >= COMMERCIAL_PRODUCT_VER)
{
OPEN_SOURCE_PRODUCT_VER
}
printf("We're only at version %d, Just wait 'till we get to version %d", OPEN_SOURCE_PRODUCT_VER, COMMERCIAL_PRODUCT_VER);
taken! (by Davidleeroth) Thanks Bingo Foo!
Bringing a suit against Microsoft is not the answer. If everybody did that, Microsoft would make damn sure that their software was bug free and that if there were any bugs, that they would have plenty of lawyers to defend themselves. Yeah, a copy of Windows XP would cost $25,000 per copy and the computer age as you know it would cease to exist - but at least you would have stable code. People don't think of the consequences of their actions.
Wow! I was enjoying the article until they suddenly started saying how Microsoft set a precedant by forcing all developers to stop writing and start testing software. From then on I quickly got the impression that they were trying to tell us how great Microsoft are because they changed their attitude towards bugs.
The only thing about this message that is a troll is the subject. What I mean is that I have written bushels of software for myself and none of it sucks - because I wrote it for me. I didn't contract myself to write it and I didn't pay myself or sell it to myself when I finished it. I've even written some computer games for myself which I still play.
The point is that, IMO "software sucking" has everything to do with good engineering and capitalism going together like water and oil. Even with freeware, you still have an economy.
So what's the answer? Part of the answer is that we (as developers) are in too deep with the commercial world - whether it's out of a need to feed ourselves and our families or because somwhere between the Altair and the Apple ][+ we got greedy and climbed into bed with big business (or big business seduced us). Geeks need money for better hardware.. lots of it.
The other part of the answer is to write it yourself. That takes money too, but I am here to say that we have far fewer problems with software that we have written for our company from scratch than we do with ANY other systems - off the shelf, customized/modified, coded by contractors, or otherwise.
So, if you want good software, learn to home brew... and get a brewmeister who knows their stuff. Do I always build brick sh*thouses? No, but sometimes only a brick sh*thouse will do.. and Microsoft isn't going to build one for you.
Vortran out
Knowledge is like ignorance.. too much can be just as bad as not enough.
"...once companies have a gun to their head, they'll figure out a way to improve their code."
Do programmers in totalitarian states produce better code? Government regulation doesn't ensure quality - in fact, it can give consumers a false sense of confidence.
If quality were more important than new features and pizzaz to consumers, then software companies would cater to that need. The truth is that consumers don't need, and wouldn't pay for, NASA quality code for personal computers.
"Give a man a fish and he will ask for tartar sauce and French fries!"
Why do people complain about software?! Sure, Microsoft puts out buggy code. It's an easy platform for virus creators to attack because so many people use it. If you can't stand Microsoft, stop complaining and install Linux!
http://www.forum-addicts.com
Also, in the companies which do have software QA departments those jobs are seen as "entry level". After all, all those people have to do is use the software to find bugs. Right? Once again, management's lack of understanding of the QA process causes them to under fund and under staff those positions.
In a perfect world, as soon as the business requirements were released the QA department would start designing a test plan full of test cases which touch each variation of each requirement. And if you want to have an even higher level of confidence then you would higher actual programmers in your QA department. They would write test IN CODE that call each method of each class with all the variations of parameter values and actually unit test individual classes and methods.
We havn't even touched on the topic of automated testing tools that drive the GUI with pre-programmed mouse clicks and key strokes. You can build an automated script that can test thousands of regression test in hours instead of days.
But here's the truth folks: As reasonable as these suggestions seem, very few companies implement even a few of them.
The real reason software sucks is because companies don't want to allocate money and resources to this cost center called "QA". And yet, the sooner a bug is caught and fixed the less the cost to fix it. Once again it's a case of the short sightedness of the corporate checkbook that's the real problem.
2. Companies don't want to pay enough $$$ to hire what really counts---EXPERIENCE---so they hire low-cost H1B programmers instead.
3. There's rampant AGE DISCRIMINATION so older experinced software engineers stop prorgamming and become managers, or go into other fields.
I joined an R&D group when I turned 40, after spending years managing software products that have earned billions of $$ in revenue cumulatively over the years. Why? Because I didn't want to be forced into managing products staffed with inexperienced and inexepensive programmers, or be involved with shipping non-glamouous tasks (device drivers, etc) to India.
--
Ask the Ya-Hoot Oracle Anything!
Some software sucks these days. I used to work for a company that built sucky software, I quit. But I learned something very important...
We are still in the beginning days of software development. There is a notion that anyone who is computer literate can program computers. This totally discounts all of the training that one would learn taking CS classes in college. But that fact is largely ignored by many of these companies who jumped on the software bandwagon years ago. As a result, they are slowly discovering what software engineering is all about, but their code is decades out of date in terms of concept and design.
But just look at some of the developers that hire people appropriately trained, the Shuttle Group at Lockheed Martin comes to mind. These guys do not make mistakes or people die. So they employ good software development practices every CS major learned in school and their code just works. All software should be developed using good practices.
I believe that the importance of these practices and concepts are slowly being recognized in the field, but there are still a lot of faux programmers out there. As time passes, the people employing software developers will come to know the value of a properly trained developer and software quality in general will go up.
First, out of curiousity... Did you bother to think about this a bit? Maybe try to understand exactly what might have happened based on your wealth of experience on computer system design?
6 .h tm
Did you consider that they probably were talking about the custom database software and not the OS itself? Or do you complain that the Internet is down whenever your modem fails to dial out?
http://www.gcn.com/archives/gcn/1998/november9/
"Human error, not Microsoft Windows NT, was the cause of a LAN failure aboard the Aegis cruiser USS Yorktown that left the Smart Ship dead in the water for nearly three hours last fall during maneuvers near Cape Charles, Va., Navy officials said."
There's been numerous articles released over the years that all point to CAE Electronics custom software being at fault, yet for some dumb reason morons keep posting this old tale and claiming Microsoft was somehow at fault.
"This is one of the better comments on this thread."
To me, these comments seem utterly out of touch with reality. I find bugs and insufficiencies in open source software. But generally open source software impresses me as an attempt to do a good job.
In contrast, Microsoft software seems just sloppy. For example, Microsoft's Internet Explorer has 18 unpatched security bugs (when this was written). These active security risks are different from the recent 15 that have already been fixed. This is sloppiness, not mistakes, and I don't find anything like it in the open source world.
When I have a problem with open source software, I find that I can get help. When I call Microsoft, I find that, usually, no one with whom I am allowed to talk knows any answers. Right now, for example, no one seems to know how to repair a new, Intel Motherboard, Windows XP installation that won't create a virtual memory paging file. It's buggy, and nothing can be done other than re-install the OS and all the applications.
If you find a big problem in open source software, chances are that you will communicate directly with the main authors. With Microsoft, I have not been able to get answers. This article says that the Psychic Friends Network is equally as good as Microsoft technical support: Microsoft Technical Support vs. The Psychic Friends Network The conclusion of the article seems reasonable considering my experience with Microsoft. Neither organization has useful answers, but The Psychic friends Network is more friendly and less expensive.
Cheap commodity hardware, system stability, numerous applications, feature packed applications, support for the latest hardware and software, enterprise level support, cheap.
Software isn't "bad". Charles C. Mann just wants everything at fire sale prices and whines when he doesn't get it.
~~ What's stopping you?
You are complaining about $8.75 billion.
Here is something more to consider:
From the article:
The potential risks of bad software were grimly illustrated between 1985 and 1987, when a computer-controlled radiation therapy machine manufactured by the government-backed Atomic Energy of Canada massively overdosed patients in the United States and Canada, killing at least three. In an exhaustive examination, Nancy Leveson, now an MIT computer scientist, assigned much of the blame to the manufacturer's inadequate software-engineering practices. Because the program used to set radiation intensity was not designed or tested carefully, simple typing errors triggered lethal blasts.
Despite this tragic experience, similar machines running software made by Multidata Systems International, of St. Louis, massively overdosed patients in Panama in 2000 and 2001, leading to eight more deaths. A team from the International Atomic Energy Agency attributed the deaths to "the entering of data" in a way programmers had not anticipated. As Leveson notes, simple data-entry errors should not have lethal consequences.
No shit.... Since when should such a machine not have safety mechanisms in place to keep this from happening? Doesn't it seem obvious that one should do SOME sanity checking on the final result when someone's life is at risk?
Would a mechanical or electrical engineer allow this sort of thing to happen? Why should a software engineer?
LedgerSMB: Open source Accounting/ERP
Isn't it proven that it is impossible to solve the halting problem?
Checking if a program won't hang (hanging is a form of bad code, IMHO) does just that.
If you can define a model of computation for which this doesn't apply, but which can carry out any algorithmic process, you are probably a millionaire.
So, "forcing good code" is an illusion for the time being.
Yes... apache owes my ISP huge. We switched to linux/apache for web serving. Our servers were configured 'industry norm' and closed to the outside and with a secure root. Surprise, suprise when I4viKtus hit our farm and blew out all but two server loads... these are machines that were NOT logged in as root no less. We were down for a week and lost 1/3 of our paying customers while we reloaded over 200 servers. Funny think was that Red was running rampant at the same time, but our patched IIS server never even hicupped thanks to packet filtering and a solid firewall. We are switching back and kicking ourselves in the head over and over... alot of people lost their jobs, especially the supposed linux experts that did the conversion and system images.
I think the issue is simple. It's a personality thing. On the MBTI, the final letter is the J/P preference. Js, the judgmental, schedule-minded people do only one thing at a time, and then until they are done. Ps, the perceiving, anything-goes people like to do many things at once, but don't really like to finish things.
Js are *much* better at programming, and thinking designs completely through. (Especially NTJs) Their code works, and works well. Ps are horrendous programmers, the code is usally buggy, and worst-of-all, they just don't care.
However, Js don't necessarily end up coding. They becomee the DBAs, or project designers. They are recognized as being better, and put in authoratative positions. However, they are then ignored!
Ps like to code. Either because its an exciting new area (SP), or because of the new challenge (NP). They recognize Js as being better at design (usually) but are reluctant to listen to them. They see the Js as being authoratative, closed-minded, and taking all the fun out of it.
In the real world, Ps dominate as coders. They believe anything can be done quickly, and are willing to do a bad job just to get it done (SP, expecially).
Bill Gates did a fantastic job when he started. Being an ENTJ, his judgemental attitude defined a decent system (MS-DOS). (I wonder what Linux Torvalds is.)
And that is only the J/P preference. The other big one is N/S. Ns are better at programming, simply because they understand it more. But many SPs see a great market, and use their not-as-good skills there, flooded the market with low quality software. The SJs (Keirsey's Guardians) have been seen in programmming circles, but they usually can't grasp the ideas.
Many people mention money as an issue about buggy code. And true, many SP managers just want to take whatever works and shove it out the door. I think, however, that the personality of the programmers themselves is much more important.
Have you read my journal today?
Here they are.
5. ?
6. Profit
Nope, no sig
Comment removed based on user account deletion
I'm surprised that no one has blamed the tools developers must use as one source of the problem. Obviously no single thing is to blame for the current state of software. There are quite a few problems, mostly because software development is new and all the kinks in the process haven't been worked out yet.
I'm mostly just a web developer and most of the projects I work on are quite small, but even so there are several times I've noticed that certain tools - launguages, mostly - greatly influence the quality of the end product.
I usually write in PHP or Python. Once I had to write a cgi in C (don't ask). I'm no great C programmer so I spent a lot of extra time to make sure it was working right. Despite my efforts the cgi didn't just have a few bugs, it even segfaulted from time to time. None of my PHP or Python apps have ever done that.
From the article, "Instead of meticulously planning code, programmers stayed up in caffeinated all-night hacking sessions, constantly bouncing results off the compiler." This seems to imply that if a compiler were better at having ideas bounced off it then the code might be improved. I think this is true, as some compliers are more useful. Python for example gives excellent errors, at least compared to PHP. Imagine if a compiler could warn you about potential memory leaks or such? This reliance on the compiler not as a tool but an assistant may be why the pair programming of extreme programming works so well.
I really don't want to start a language war, but I think there is a strong case for the suggestion that some languages help the programmer produce a more reliable end product. I know that C will be faster than Python, but as the article says, processing power is cheap. If Microsoft really wanted to make their operating system more reliable wouldn't they stop coding so much of it in C++?
The comparison between the assembly line, and software development is a very very poor one. A better comparison would be between the R&D process that goes on in the auto industry and software development.
That is: There are concepts that come out at trade shows, some are working, others are just ideas/smoke and mirrors. Then a timeline, a few years if not more, is put into place to turn the concept into a reality. The real product then goes through 6 or more months of testing, before the real product comes out. Once the product is out, changes take place on an annual time scale, and the R&D team begin to show their new concepts. The cycle goes on.
There are few software shops that take this approach, but their code/product is stable, and robust.
Problems with this, other companies go straight from smoke and mirrors to product in a few months, ie internet time. They don't allow real R&D to take place to make the product the best it can be, and cause other competitors to rush their product to market.
If we all slowed down, and were not rushed by marketing types, and could resist those who push for incomplete products to go to market, software quality would improve. However, the idea that it may improve to the point where point/click/drag/drop application development could be a possibility is false, since there will always be a need to do the thining intensive research before hand.
Developers are to blame for creating a "boss jock" culture in the workplace that stresses quick results and sheer brawn over correctness, literacy, and maintainability. Developers are to blame for wallowing in and encouraging over complexity and churn of APIs, platforms, and programming languages. Many developers seem to get their rocks off on "being superior" to each other rather than creating something that is truly usable. Most developers have no conception of the key tradeoff between "fragile" and "simple but robust". Many developers are also to blame for "resume engineering", putting needless complexity into products because they want to justify new buzzwords on their resumes.
Companies are to blame for having absolutely no quality standards beyond profitability, and for creating sheltered sandbox playgrounds of idiot savant techies (the programmers competing with each other for kewlness) that encourages churn of tools for its own sake. Often, there are no grown adults with an ounce of clue paying attention. Also blame dual track career systems that encourage ghettoization of developers and which grooms the incompetent to lead and manage activities that they are demonstrably not good at (the Peter Principle, or the PHB plague.)
Consumers are to blame for demanding feature bulk in new products without being discerning enough to notice that the useful, core features are not well implemented. Consumers are to blame for buying and accepting crap with no comment or protest.
Everyone involved deserves each other. Consumers wouldn't pay the bucks to buy conservatively engineered and reliable software (beyond tiny product niches.) Companies would definitely not fund development of products that didn't have some incredible short term payback potential. Developers won't willingly work on stuff that isn't bleeding edge cool.
In this equation, everyone involved is pushing on each other HARD to make and ship crappy, fragile, bloated products.
bwahahaha... *goes off looking for mod points*
But it costs a lot of money to do that. And computer software is no different than any business. It's worth it for a business to let 5 or 10% of their customer base leave if that customer base is costing more money than it makes.
It isn't typically profitable to have a professional mechanic pick up the phone every time you call your dealership (unless it's a luxury place), and it isn't typically profitable to make relatively bugless software. Welcome to the World Of Business.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
Quality is important, but how we use software is more important in our buying decision. They made a good point that given the plus side of the equation, most software is worth what you pay for it. Otherwise, people would not buy it.
Quality however is not free and the consumer must, in almost all business equations pay for it. In the case of dropping a Space Shuttle on Atlanta, our willingness to pay for additional quality controls is going to be much higher than testing a text editor.
Using the automotive analogy, I want my car to go 250,000 miles without any upkeep (oil changes, filters, etc.) The diffence in the engineering is that no one considers the auto example reasonable but they do with software for which they are paying 1/20th the price.
If, indeed, Code Red cost $8.75billion (and I'd like to see the analysis that arrived at that figure), that cost was incurred in the process of using Outlook. Presumably, the consumer derived some benefit from using Outlook, at least in their judgement they did.
Users have already paid that. However much they paid for the software, that is the extent of what the seller is entitled to. If a court finds that the manufacturer is liable for defects, they don't get to deduct how "valuable" the product was to the user from the damage caused.
Nope, no sig
Today there arent anything that warrants writing comercial code better than "it works, mostly". Until there comes either market advantage of off writing stable secure apps it wont get much better. GNU/Linux, apache and other succesful projects has put the torch on some corporations but not near enough. If they dissapear its buissiness as usual. Liability would be good because fear of loosing big bucks works. Nothing gets your attention lika a magnum pointing at your head. liability wouldnt affect open source since its given away for free. The state of software today is just sad, it could be like hardware, faster and smaller. Imagine an OS that ran faster with each release! Not impossible, look at beos.
HTTP/1.1 400
Besides time pressure, there is another reason why programmers write bad code. If your code does just what it needs to and nothing else, you will have a job next time they want a new feature. Especially if you make sure you are the only one who understands the code. If your code is buggy, you can even be sure to get more work, although that is tricky practice because it harms your reputation. The other two are widely used (and supposedly accedpted) paractice, though.
---
I am not sure what this is, but an 'F' would only dignify it
Please correct me if I got my facts wrong.
------ FROM ------
COMDEX SPRING and WINDOWS WORLD 95
Power Panel - "What's Wrong with Software Development"
** In The U.S. Only **
$81 Billion = 31% of software development gets cancelled before complete
$59 Billion = 53% of software development has cost over-runs of 189%
16% success - project success and failure ratio
61% customer requested features and functions make it in
Maintenance and repair is where most of the U.S. dollars are going,
instead of new, better, easier to use software.
---- Overall ----
Problems - all-around lack of complete documentation and weak training, faulty user input and feed back - self contradictory user request, lack of project leadership between developers and users, management created problems and low quality control standards, feature creep and software size increase, advancing technology rate of change and lack of general standards, solutions around the corner but never arrive and our tools are better than theirs attitude, lack of a value chain structure for value added abilities, failure to produce a functional model before coding and constant remodeling, etc.
Solution directions - code re-use, object oriented programming, component-based programming, distributed components, better tools, better programming methodologies, leaner software, a splitting of code writer types into two catagories - architects and assemblers, better effort to establish a working vocabulary between developers and users so users can in some way lead development, etc.
---- A Few Comments from Panel Members ----
A culture needs to evolve that respect software engineers as crafts-people. Writing code is not just writing code but like the field of writing where you have technical, creative, documentary, etc., there are different types of code writing. (Authors' note: I agree with this but also realize end users are even more specialized in what they need and do. Respect for the end user needs and abilities is needed even more so. Without respect given to the end user, the software engineer will not be given respect in return.)
A fundamental change in the programming environment needs to happen that allows the tools to work together more. (Authors' note: the panel member making this comment, did not specify what tools or who the tools would be used by. It was a very general comment pointing to a fundamental programming environment change. A lead in to the concept of componet programming. But, there was no recognition given to the concept of componet software or componet applications. At least not in the sense of being outside of "plugins". Read on!)
Jokingly - one of the best ways to copy protect software is to put it in a dll, give it an obscure name and put it in the windows system directory. Because you'd never find it. (Authors' note: This does not make it any easier for the end user in keeping their system organized, clean and optimized. This attitude of constraints, though humorous, cost end users alot.)
The meaning of "intellectual property" became questioned. Did it mean you take the best ideas or something owned? (Authors' note: it was the panel supporting "best ideas" but wouldn't the correct term for this use be "intellectual value" rather than "intellectual property"? What would happen, regarding this, in a court room? The audience member whom brought this up, was a bit angry about the distortion. Her question was: Is it the developers whom are creating the problems? And what are the developers going to do about it? The responce was "that's not the problem!")
Users shouldn't develope software but know, better than the developers, what they want and need. (Authors' note: users don't have the time to write code, it's not their job or duties!!! I can cut the lawn, I know how, but if I don't have the time, I hire someone. And because I know how to better communicate what I want done, I'll get what I want and know I'll not be greatly overcharged.)
Analogy used to start off power panel: Getting the right software development tools is alot like dating. And it evolved to something about programmers not being able to get dates, while touching a nerve with a panel member. (I do wonder if Phillip Khan (sp? borland, ever got a girl friend.)
(Author observation from attending this gathering - alot of good points where brought up from both the audience and members of the panel but it became clear there was no solution being brought forward to satisfy the majority. The audience saw this as it thinned out over the course, as they perceived the power panel struggling for a sales pitch. There where two on the panel not biased due their position, leaving six biased. Microsoft, Borland, Powersoft, Oracle, Software Associates, and IBM were the biased parties.)
Panel mix - Tools developers, Data Base Developers, Application Developers, Application salvagers, and software consultants.
------ AND FROM ------
SCIENTIFIC AMERICAN - Sept. 1994
Article - "Software's Chronic Crisis"
The article covers much the same ground as the above but with a focus and flavor of the magazine. The article also goes more into solution efforts with software development on large scale projects. But finding consistent solutions are still hard to come by.
Mass-produced PC products makes up less than 10% of the $92.8 billion U.S. software market.
Mary M. Shaw of Carnegie Mellon University, observes a parallel between chemical engineering evolution and software engineering evolution. However, this evolution has not made the connection between science and commercialization required to establish a consistent experimental foundation for professional software engineering.
---
What this amounts to is the lack of Computer science to develope Autocoding machinery that can be more widely used and further developed.
Programming is the act of automating complexity, that is made up of simpler things, so that the reuse of it is made easy. Be it for the developer level or the newbie end user.
The field of programming seems to be able to automate any other field but their own and that results in the limitation of just how much can actually get done in a given time period. Not to mention all the bogus junk it allow to happen.
If you are involved in a large complicated software project and you write 10000 lines of code then that code will have many conditionals, loops, and branches each of which involved a design or implementation decision. Bad programmers think that not much is involved in those choices, good programmers are still internally debating the choices years later. The more I do software development, the more I believe that there is a general lack of awareness just how difficult it is to write a good useful sellable software program. Every few years there is some new methedology that is going to revolutionize software development (remember when you could find Object Oriented Programming Gurus at every software convention). None of them have a technique for naming a function so that two years later you do not regret the name because a.) it is not specific enough. b.) violates the thematic pattern of other function names. Or c.) no longer precisely describes the purpose of the function.
I went to Western Michigan University. There it didn't matter what you coded. Most of the teachers didn't grade anything anyway. If you had an American instructor and you were white you passed. If you had a foreign instructor and you weren't white you passed. Not all of them were this way but many.....
It was frustrating for those of us who consistently did good work.
Software Is Bad Because the Experts Say There Is No Silver Bullet
Software is bad because we are doing it wrong. We are doing it wrong because our so-called experts tell us that there is no silver bullet to the problem of unreliability. So now they want to bring in the lawyers and even more clueless experts. It won't work.
The brains of humans and animals are the existence proof that there is a silver bullet. Complexity wise, there is nothing in the universe more robust and reliable than the brain. In fact, the more complex the brain gets (as it learns), the more reliable it becomes. By contrast, the reliability of software gets worse as it gets more complex. Why is that?
The primary reason is that software is based on algorithms (threads) whereas the brain is a parallel, signal-based system. The reliability of the brain comes from the strict enforcement of precise signal timing: neurons always fire at the right time, under the right temporal conditions. With algorithmic software, it is virtually impossible to guarantee the timing of various processes, which leads to program decisions happening at the wrong time.
The secondary reason for bad software has to do with connection types. In the brain, signal pathways are not connected willy nilly. Connections are made according to their types. We should do the same with software. All message connectors should have message types, and all connectors should be either male or female to ensure robust connectivity. Plug compatibility should automate over 90% of software construction.
The Solution
We must imitate nature. We must forever stop basing computer programming on the algorithm and we must stop using algorithmic languages. Software should be more like hardware with parallel modules and their input and output connections. One of the reasons that electronic circuits are so much more reliable than software is that timing problems are immediately nipped in the bud due to the inherent parallelism of hardware. The circuit simply will not work if timing is wrong. We can create the right software construction tools to solve the reliability crisis. Damn the experts!
I'm seeing lots of comments about how software isn't "engineering" or a "science." Well, I hate to break it to you guys but engineering is just as much hackery as anything else. Yes, there is some science to figuring out how much stress a material can take, but it's not like you can mathematically prove that an airplane is safe. Products are recalled all the time because of oversights and design errors. And planes do crash because of mechanical failures. Aerospace engineers are more afraid of flying than the general populace.
I see two big problems with modern software. The first is that computer systems are much, much, much too complicated, to where people accept lines like "no sofware can be bug free." Sure it can! How depressing it is that we let that be spood fed to us! But not when you have a huge operating system and huge language libraries and huge OS libraries and huge hardware drivers and so on. Heck, there's more code in one of Nvidia's drivers than in OSes from the 1970s. You see many fewer bugs on less complicated platforms, like game consoles and PDAs. PCs are pretty much a lost cause in that respect, and that's not going to change. One day I hope that we can return to more reliable systems, even at the expense of expandability (who cares about expandability any more?).
The second problem is simply that most developers don't give any importance to producing reliable software. In the telecom business, there's no way you could getting away without writing comprensive test suites and a huge amount of work from a dedicated testing group. But you hardly see automated testing for any software these days, outside of embedded systems. And you'll see silly newbie developers argue that they need to use C++ to write some silly app because "it is faster," when they actually should be using Python or Lisp instead.
.. but it all boils down to poor design.
Even Linux suffers from this, so it isn't just closed-source software... (how many different totally-rewritten VM systems so far??).
I think it hits the head right on the nose when people talk about rushing a product out the door, or caffienated hackers working obscene hours eliminating compiler errors and getting something that 'seems to work ok' so it can be rushed out as a 'production quality' product.
Not enough time gets spent on proper *design* in the first place, and as someone mentioned, by the time the flaws in the original design are found its version 2.x and nobody wants to spend the time (money) on a complete rewrite to fix the basic design flaws. At least on this, open-source has an advantage that money isn't involved.. just dedicated programmers (free as in beer).
In your average company, it all boils down to the bottom line. Sure, we can hire security concious people and QA testers to check the "feel" and consistency of our interfaces (and spelling, God I've seen some atrocious messages -- database repair status: "finish to rebuild index files")... but this all affects the bottom line cost of creating a product.
You want the best QA environment out there? Well, in reality Linux/Open-source probably has it... but for a company like Microsoft?? Ok, so roll out the alpha release of your *next* product, say Windoze ".NET workstation" or whatever the heck they call it, out to the secretaries and non-technical people in the company. Let them beat up on it and find bugs for a year. Have a team of dedicated "hackers" trying to break into the boxes around the company...
It disgusts me, personally, to hear microsoft say that Windows (which, excuse me, I thought was supposed to be built on top of a mach-style microkernel architecture) is full of code thats so intertwined that they can't seperate it from the OS. Umm... isn't that what a microkernel architecture is supposed to do is enforce *modularity*???
From the article
"In the last 15 years alone, software defects have...induced a U.S. Navy ship to destroy a civilian airliner"
Will someone inform me as to what the author is implying? KAL Flight 007? TWA Flight 800?
I'll admit there is plenty of bad software out there, but what about all the benefits software has brought us? And technology in general?
Amazingly, software facing the public often degrades with time (I'm not talking about bitrot) relative to the fall off of support it has.
Say I went with OpenBSD 2.8 for my firewall. Now that 3.1 is out patches for problems in 2.8 are no longer actively maintained. Thus in order to protect myself I must walk close to the edge but those have to upgrade the least are the ones who jumped to the bleeding edge of the stable releases since you can go two new releases without having to upgrade.
Sooner or later something forces you to upgrade.
software that looks harmless by itself at the beginning can be a deadly combination with other programs or just by mankind's abillity to destroy evertything...
Programs should always be checked on bugs and be docuimented to prevent doing harm to other programs.
I don't have the time for an intelligent comment on this...
One of our sales people promised that we'd have this project done for the end of June.
The only thing that we learn from history is that nobody learns anything from history.
I wasn't intending to use version numbers as the justification, just a supporting argument. Age was my arguement. IIRC GIMP was started sometime about '96, and photoshop sometime about '88. Odds are I'm wrong with both dates, but the seem reasonable even if wrong.
Sounds like we're rehashing what Richard Gabriel stated back in the early 90's: Bad software released early seems to outlive software that is engineered completely before it is released (paraphrased). You can take a look at it here for the complete argument.
Interesting to see how Unix was once viewed in the light M$ is today.
Perhaps I didn't make what I was trying to say clear enough. I'm not even talking about logic bugs; I'm talking about sloppy programming.
Recently I took a course in assembly language at my university, and we were graded solely on performance. Nothing on style, nothing on technique, just how fast your program ran. It was competitive enough, too, that style went out the window -- people would write the most god-awful code imaginable just because it ran faster, and they learned to take that attitude automatically. Whatever works, works, regardless of the consequences.
Now, granted, most schools do teach their beginners about the merits of style, and some (like mine) even grade the introductory C++ classes on how well they comment their code. Sometimes higher-level classes will give you a higher grade for having good style and structure, but I don't think teachers require it as much as they should. I see a lot of CS majors graduate with the idea that any shortcut is acceptable as long as it produces the desired effect; they wouldn't even consider for a moment that they needed to re-think a badly designed project, they'd just find ways to work around its flaws.
That, I believe, is what the article was referring to as well, and that's what really causes problems for software -- not logic bugs, but just plain old sloppiness.
Schooling is about merit and good work, not about skin-colour.
I agree. All of our assignments were handed in in hard copy form. No one even bothered to run them. You were given a data file and if your program produced correct output for that data all was well. It didn't matter how it behaved with the rest of the infinite number of inputs that were possible.
I don't even want to get into the level of cheating this encouraged. The worst part was the attitude of many in the faculty. I know someone who brought up the cheating to an instructor and this person actually rationalized it by saying, " Well people cheat in other departments too!"
I know of another instructor that told my friend to be proud of his 'B' because he earned it. Many of the people who got 'A's had cheated and the instructor seemed to be okay with it. It continues to make me sick to this day.
To Do: 1. Take over world 2. Pick up Milk and Bread on the way home
I am a hardware/networking guy. That said. I think that code sucks so bad because all I ever do is THROW hardware at servers to make them faster - and I can do that...
I know that this doesn't really make sense to a programmer - but when they write code and install it on a box - the complain to me that it's not fast enough. You need more proc's - you need more RAM - you need 2 nics - etc...
I really think that people should write code on a 386 - then it would work great and run like the wind. Programmers ALWAYS have the fastest machines in the house, always. And I don't think that it should be that way.
Like I said - I don't write code - so I could be talking out my ass here - but if you guys did have "specs" for writing "good" code and did it on hardware that was about 5 years old - we wouldn't have any problems.
Now this isn't geared towards home systems - people at home want it all - but server systems is where this needs to be addressed.
I know that the "standards" (if there are any) for writing good code are pretty loose and there are very few of them - and getting this end of it fixed up would help a lot. But I think that it would be hard to do when there is 7000 languages out there to choose from.
Not to be a dick - but RFC 1925 #(12) "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away." is the way that programmers should write code. And if you did it on old slow hardware - you would have to.
Duke
FreeBSD: Nothing runs like a daemon with a pitch fork.
I don't see any numbers indicating worse-ness or sucky-ness of software, or even how much more complex it's become (and that last point is actually acquireable.) I agree that it probably is worse, but they certainly aren't trying to confirm it.
It seems irresponsible to base a professional screed on the fact that some trainer starts his PowerPoint presentations with a slide that says "Most Software Sucks".
What a waste of server space. I mean, 90% of EVERYTHING is crap. Food, music, art, people, governements, laws, clothes, fast food chains ... why would software be any different? When the market is driven by quantity, not quality (as has been the case since the industrial revolution) most of what you see in ANY field is going to be garbage.
... switch to a Mac, baby!
And I hate to belabor the point, but if you want to see a plethora of nice-looking, intuitive, and usefull apps
I submit to you that the 2001 refrigerator is approaching perfection.
It is perfect. The 1950 fridge is less efficient than the 1970 fridge, which is less efficient than the 2000 fridge. Off the shelf, the 2000 fridge is cheaper to run and keeps things colder.
The 2000 fridge is also an improvement on the 1950 fridge in one very, very significant way - it breaks sooner. Lighter materials, and lots of stupid little unnecessary components add up to a fridge that will be on the scrap heap sooner.
What? That's not an improvement? It is if you sell refrigerators. Companies that make fridges sell them.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
Hey, I'll take you up on it, if for that one month, I get union benefits, overtime pay, a reasonable set of responsibilities, and a truckload of Mexicans.
Well that's kinda the point, Software is more of a art/science disiplin and not an engenerian disiplin,
There are two feasable ways of enginering software.
1: Have precise specifications, and take the type to perform all mathamatical analysys on the project. e.g. Space projects.
2: Re-write the whole thing, now you know what your doing.
1, isn't praticle for most things, You frequently don't know the requirements before you start and it would take forever to write word that way.
2, This is great for reverse enginering projects, but most companies need some return on investment, a Re-write/re-work would be thrown out [I usually re-work modules is a sneeky way, and make sure all the missing/assumed business requirements are resolved first]
And the third option,
Release somthing you know has bugs,
Have full regression tests for the software,
when a bug is found get a test case,
Fix the bug,
Check the test case,
Re-run all regression tests and check that any descrepancies were caused by the bug and are now fixed.
Re-build all regression tests.
Repeat
Most companies I';ve workd for don't do 3 either, so you just get hack-ware
thank God the internet isn't a human right.
Software only does what the requirement-writers (or the jackass managers who "write" requirements on the fly) say it must do to get shipped.
Stability, being in general unprovable (how do you validate a MTTF of 10 years on a two-day project? you don't. we've been around this question before) is rarely a requirement for software.
And software isn't only hidden from the user. It's invisible to the programmer. Every coder knows that his debugger only tells him the things it tells him. The rest of his understanding has to be kept in a mental model, which often contains only those short sequences of code that he's picked up from Other People's Listings. The human brain is capable of turning any meme into any other meme; it's about as reliable a mnemonic device as writing on a sidewalk in chalk in hurricane season.
Code works acceptably to the standards of the organization at the time it decides to deliver it.
Look up the SEI CMM quality standards or DO-178B to improve yours.
--Blair
Zip+4 is always a good idea.
Using the city name instead of the name of the post office is not always a good idea. What screws most people up is that a mailing address doesn't list your geographical location in the city field, but rather the name of the post office that services your address.
To make matters more confusing, some post offices have multiple branches. I have a post office three blocks away from me located within the territorial borders of the municipality in which I live. However, this is a branch of the post office for the megapolis next to which my municipality resides. Hence, my mailing address is that of the megapolis and not of the municipality.
Consider a city I used to live in, Beavercreek, Ohio. When I lived there, Beavercreek was serviced by three different post offices: Dayton, Fairborn and Xenia. The zip code depended on which post office serviced that section of Beavercreek. Most people that used the city name Beavercreek instead of the name of the post office that serviced that area had their mail returned to sender or delayed while the letter went bounced around to the three post offices that served Beavercreek.
Fun, eh?
> It has been oft-observed that you cannot successfully apply a technological solution to a social problem.
And yet, your car has anti-lock brakes, three-point harnesses, and airbags... Is that not a technological solution to the social problem of bad drivers?
Just because it works, doesn't mean it isn't broken.
Software also sux because they get credit that is due to the HW guys.
Software has NOT gotten faster, if anything, the opposite.
HW has gotten faster. And it doesn't crash anywhere near as often.
What is required is a software "lemon law," that would override all software licenses. All that is required is three provisions.
1) Any reported bug (failure of software to work as advertised or documented) must be fixed without cost to the user within 6 months of report or the buyer becomes eligible for a full refund of the purchase price.
2) Any exclusion of liability for consequential damages is invalid if the damage results from a bug that the company knew about for more than 6 months.
3) Any exclusion of liability for consequential damages is invalid if the damage results from a bug that the company knew about and kept secret.
I think that we'd see in short order a dramatic improvement in software reliability.
Here is the real reason software is so bad.
Consumers decide to buy the software that has the most features and not the software that has the fewest bugs.
If consumers decided to buy the software with the fewest bugs you would see software quality shoot through the roof.
The city is being overrun by a herd of Lucy Liu's.
...when you take into account the scales of what we are referring to.
A 10 line script or program. No sweat. Likely error free because of the size of the effort. One person, little time, little money.
When you are talking 100,000 or 4,000,000, I would submit that is effectively humanly impossible to write such a beast that is completely error free. There is no way one person could handle such a task, and the 'too many cooks' applies when you are talking about massive teams of developers.
Given enough time, money, and genuine interest in the success of a product, you will likely succeed in something that is at least a reasonably error-free. The computer gaming industry gives us an indicator of that (compare blizzard created to sierra created).
Until the creation of a true 5th GL (which won't exist until computers can creatively think for themselves) there is no way we will avoid errors of logic in massive programmed systems.
Hail Eris, full of mischief...
E pluribus sanguinem
Design is necessary but it's impossible to keep anything stabilized when you can't freeze development such as in an Ecommerce application or Point Of Sale.
What happens is that the application is a living thing. Constantly growing and shifting and yes, proper design can account for that but there's alway something that will go beyond the scope that was foreseen in the design phase.
Anyone got any jobs for Perl hackers in the London area? Yes, I'm serious.
Software will forever be more complicated than anything else we are trying to build. Read the "Mythical Man month", written about twenty years ago. Software cannot easily be put into blue print, software does not fit into flow diagrams...
Just think as software as a state automaton: to properly test any software, you have to test its behavior against every possible input. Useless to say that when your code base amounts to more than a dozen lines, the number of possible states of your automaton is ...simply to big to understand. I'm not talking millions of lines here.
To propely test software, you have to bridge the gap between the assembly code: where a few lines of code can more or less easily be described into some state automaton, and high-level code when adding a few lines of code will add a tremendous amount of test cases. And do not let any consultant/quality whatever convince you otherwise. The only real value of software is simple to define: if its quality can overcome it drawbacks, then go for it. Do not ask for the impossible.
If you try to put lawyers into there, you'll just put developpment to a grinding halt, because up to now, there is no reasonnable way to code safely and to test everything. Will it be bad or not: well, I don't think it's going to happen, because on the other hand, when software do works, then it's so usefull. Try to leave without using software: forget about using a bank, a phone...
I'm rather hoping for a mid-term solution, where software customer will become reasonnable and stop to ask for more, but instead for better. My favorite is the Di....t sentence: "we want a bigger, nuclear power plant, but without too much radiations...unless it gives us X-ray vision"
Maybe the fact that software will eventually become unmanageable and bloated will force the latter on us ;-)
[Pruneau
... let's ship it.
Seen somewhere in the net.
You should se how I fix business logic bugs,
3 weeks of coding, takes 2.5 months to do, and when it's done it works.
The break down normally goes,
2 weeks of analysis
2-3 weeks of defining the business logic
2 week writing test cases, and test scripts, and data patches to correct existing errors
3 weeks coding
the rest of the time running test-scripts etc..
then there's usually a month or UAT.
The extra time spent (3-4 weeks over compinies where i've previously worked) is usually made up over 3 months (taking into account all support/helpdesk staff)
That might be the REASON, but it's no excuse.
:) But we're behind, and we won't catch a moving target unless we invest at a higher level to the people we're chasing.
:)
GIMP is widely hailed as the alternative to PhotoShop - it's not (as long as you just count features). By the time it catches up (if) then Photoshop will have moved on.
FreeCiv is nowhere NEAR Civilisation 2.0 (at least the last time I looked) and there's been Civ Call To Power and Civ 3 since then.
Wine can't keep up with Windows - they might run a large percentage of apps, but it's a moving target.
Of course, you can argue (and I do) that the usefulness compared to the price is what you should compare (bang per buck)... but until you offer all the features people want, you'll be seen as being behind the curve. Whining 'but we started late' is no excuse.
If you want a given OSS app to be compared to a given prorietary app, then expect to be compared with the current version.
On the other hand...
Mozilla caught up with MS, Linux caught the commercial Unices, and there's some other OSS programs out there that match or surpass their closed source counterparts. In my experience, this is for one of a few reasons:
1. Investing (e.g. Mozilla)
If you spend money on a project, you catch up. As a previous poster said, a handful of people reviewing code in their lunch hour isn't going to cut it.
2. Simplicity (e.g. the GNU utils)
Small, useful applications with a well-defined role can easily be 'copied' - the GNU utils were designed to replace tiny programs and add new features, and they succeeded!
3. Fixed target
Linux was aimed at a Posix-compliant Unix kernel. Not 'the current version of Solaris' because they'd still be playing chase-up.
Please don't think I'm sneering at the work done by the people involved in OSS, I think Linux is great, Gimp is incredible for what it does, and the GNU utils changed my life (RMS, you can quote me
Mark
PS Imagine a running race where I get to start 10 minutes after everyone else, but my first lap is quicker than them all - I can't claim I'm winning at that point, it's whoever's in the lead that matters. Complaining 'but I got here late' cuts no ice, but maybe I'll be noticed for my incredible turn of speed
Liked this comment? Why not buy me something nice
Software Is Bad Precisely Because Experts Like Brooks Teach that There Is No Silver Bullet
Software is bad because we are doing it wrong. We are doing it wrong because our so-called experts tell us that there is no silver bullet to the problem of unreliability. So everybody has given up on finding a solution. And now they want to bring in the lawyers and even more clueless experts. It won't work.
The brains of humans and animals are the existence proof that there is a silver bullet. Complexity wise, there is nothing in the universe more robust and reliable than the brain. In fact, the more complex the brain gets (as it learns), the more reliable it becomes. By contrast, the reliability of software gets worse as it gets more complex. Why is that?
The primary reason is that software is based on algorithms (threads) whereas the brain is a parallel, signal-based system. The reliability of the brain comes from the strict enforcement of precise signal timing: neurons always fire at the right time, under the right temporal conditions. With software, it is virtually impossible to guarantee the timing of various processes, which leads to program decisions happening at the wrong time.
The secondary reason for bad software has to do with connection types. In the brain, signal pathways are not connected willy nilly. Connections are made according to their types. We should do the same with software. All message connectors should have message types, and all connectors should be either male or female to ensure robust connectivity.
The Solution
We must imitate nature. We must forever stop basing computer programming on the algorithm and we must stop using algorithmic languages. Software should be more like hardware with parallel modules and their input and output connections. One of the reasons that electronic circuits are so much more reliable than software is that timing problems are immediately nipped at the bud due to the inherent parallelism of hardware. The circuit simply will not work if timing is wrong.
We can solve the software reliability crisis. We can create tools that automate over 90% of the software development process. Damn the Experts!
It's funny you can tell who inhabits /. by seeing these comments.
;-)
100s of posts about coding, but no one mentions anything about considering what users want, how they work, and how software can best be made to suit their need. In short, CHI doesn't seem to be a consideration at all.
From seeing aging or non-100%-interested people use computers, I'd sat many more people would be using software if it were crafted for human demands, and not the ones set by the marketing department.
Sure, a graphic designer can put together a slick looking interface, but if it's conceptually considered to any greater length, it'll have the same effect as faulty code.
What I'm saying is that, while code makes software run at all, Computer Human Interaction Design makes it used. Hence, it should receive equal consideration.
(alas, when interaction designers have to take courses so they can explain people what they do, software isn't going to become more 'usable' anytime soon
.
-
There called research scientists now a days.
In the real world everything tends to slip to mediocrity and you need to plan around it. Sure, it would be great if we could only train the computer virtuosos to be programmers, but the reality is that there is quite a bit of demand for programmers. Besides, the weak point is usually in planning: overly tight budgets, unrealistic timelines and poorly thought out designs -- amazing code does little to save these projects.
I'm also dismayed by the 'but they didn't code before college' attitude as well. So what? Coding is only one of the skills that you need to do the job. It can be learned. Frankly, its your people skills that will determine your success -- if you can't communicate your ideas VERY WELL with others (especially marketing and senior management, who have very different world-views than programmers), it doesn't matter how well you code, you will be beaten by the mediocre, but well-spoken, coder every time.
... of you company's software is maybe to let developers put their names in that "about" screen.
1. Make sure you are in a market that you can actually compete in. 2. Set realistic release cycles. 3. Don't go crazy with features on your first release. 4. Test the shit out of your code, better yet have an actual tester test the shit out of your code. I rarely release code with bugs in it - really. 5. Don't be a cocky, jackass developer with an attitude. 6. Take pride in doing this correctly and professionally. 7. Don't code for 16 hours straight and expect your code to not suck. 8. Take breaks. 9. Relax 10. In a professional manner, inform your client or boss that what he/she is asking is not realistic. Offer alternatives. 11. If you can't do the above, find another gig, that that project/company die so we don't have to deal with their crap software.
or one month, do your job according to the constraints imposed by the world of building construction.
Um, what's the building inspector going to do with my code, anyway?. Besides that, we don't even have the equivalent of building codes.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
I find it irresponsible of the author to suggest litigation is the way to fix anything. It is too "after the fact". While I agree forcing companies to "feel" it is the only way to get them to change and the only way to do that is to stop buying their products. Regardless of what many analysts think there are options and alternatives. Windows, excel, word, IE, Media Player.... there are open-source alternatives that work exceptionally well to everyone one of their proprietary offerings.
Is it possible that software is so different from any manufactured good that it cannot be built properly in a corporate environment. We learned from the "Cathedral and the Bazarr" you cannot treat software like a manufactured good. If you think things like peer review are going to change it, then open-source software is one of the best routes.
Forget MS, open-source software development paradigms lead to high quality, well designed code. Lets start using it (and participating in the open-source community), and stop complaining about crashes.
Let's start off by getting through the obvious. I'm a developer, a purchaser, and a beta tester.
The first truth of software development is that customers demand software immediately. They are not willing to wait for bug free versions to come out, or more accurately, those willing to wait are not nearly as vocal as the ones who want it now.
And the beta test, well, that's just a nightmare in itself. Between the number of beta testers who break NDA agreements, the ones who give their friends a copy of the beta test, and the ones who couldn't write down how to duplicate a problem if their life depended on it, it's amazing any progress is made at all during the beta test.
And all of this hinges on those peices of closed source software that the new software has to interface with. Finding out that Windows doesn't like you code is one thing, but chasing down some driver is much worse. And the people who write drivers and Operating systems have it just as bad, testing with released closed source products and hoping they work.
Yes, there is no silver bullet, but there is a large clip of small bullets that we need to learn how to start firing. We need test cases, documentation, standard interfaces, a complete removal of "hidden features" (unofficial functions that software developers rely on), and most importantly, a customer base that can all agree on a balance between "now" and "right".
No Zen is good zen
Read my post. No one at Microsoft can help with a bug in Windows XP! The OS doesn't work. That's on a different level of importance than tabs in Mozilla. Tell the Mozilla people and they will fix the problem. I use K in Linux, but in Windows 20 or 30 tabs and 4 instances of Mozilla works fine.
here is some hope for all that think code will always be buggy. http://www.hdcc.cs.cmu.edu/
> The process of writing an open source project
> is much different from that of a proprietary
> piece of software
How so? Why is it better equipped to deal with defects?
I would have just thought it was a simple felony to provide such insecure access to people's health care records.
I Browse at +4 Flamebait
Open Source Sysadmin
Some of the worst software written comes in periods of insanely-paced competition. WordPerfect vs. Word, Netscape vs. IE (we'll ignore the question that's begged about Mozilla here). Anyone who remembers the "office suite" wars will remember that Microsoft, Corel/Novell, Borland, and YoMamaSuite were each pumping out verions left and right. And when there's that much competition, quality suffers. (Yes, on a relative scale, the best code wins because consumers have choice, blah blah blah, but on an absolute scale, software produced during heavy competition is more buggy).
This flies against most of the prevailing thought in this forum, but think about the decision from a management point of view. You're about to ship a product. Two pretty bad bugs are found at the last minute. You have to make a go-nogo decision. There are two potential worlds:
Clearly, the manager in the second case chooses to fix the bugs, since stability is a selling point (albeit arguably a small one compared to features, for the average consumer). But a manager in the first case understands that unless his bugs are far worse than the competitions', shipping doesn't hurt (and in fact may be the most viable option). It's a classic case of Prisoners' Dilemma, and ironically the consumer gets screwed.
Most mac software is well designed, and just plain works. That's because most Mac developers actually care about the user experience their product affords.
Don't complain, vote with your dollars!
The software industry is driven by the need to get customers to buy new versions every two years. This means that there has to be something new every two years, and it has to be sufficiently important and different that someone will actually buy a new version because of it. In other industries, the usual practice is to make slight refinements to the technology to improve it. The automotive industry doesn't say, "You already have a car with an internal combustion engine, so we've come up with a new kind of engine." The civil engineers don't say, "We've come up with a new bridge design, so all of the suspension bridges we put up should be replaced." The software industry is totally new every two years, so software it produces is what you'd expect of two-year-old technology.
Of course, this isn't true of all software. Oracle, for instance, basically does what it's always done, with incremental improvements. And Oracle improves with each version. Linux has gotten more stable and efficient over time, at least in those parts which aren't entirely new.
Programmers make a mistake or two for each ten lines of new code. I suspect that this is the same error rate as all engineers have. But engineers in other industries, by and large, produce very little new stuff. If you're designing a bridge, you start with an existing design, and then do all of the changes necessary for the particular site. They make a few mistakes in these changes, they do a bit of testing, they fix all of the problems, and they end up with a perfect result.
Programmers, on the other hand, generate a huge amount of output, such that there are too many errors to expect to find all of them by just looking at the code. This means that later passes have to go through trying to find bugs in an approximate process.
With a proper design, a new feature should require about 10 lines worth of new code, and the programmer should be able to find all of the bugs immediately.
There is a lot of good software out there that is highly reliable, does what it is supposed to do without more than an occasional problem.
Let me name some software companies that do things right!
Cassidy and Greene
Connectix
Aladdin Systems
The Omni Group
(and dare I say it?) Apple
There's always a market for quality. It just isn't very large. Apple's 5% marketshare proves that.
Avoid Missing Ball for High Score
So that's not really a catch at all, just further support for my hypothesis =)
(* The brains of humans and animals are the existence proof that there is a silver bullet. Complexity wise, there is nothing in the universe more robust and reliable than the brain. *)
"Animals"? See title.
Human brain reliable? Not the humans I know.
Perhaps "adaptable" is a better description than "reliable".
But, this takes AI which does not fully exist yet and the hardware won't catch up to the computing power of the human brain until roughly 2030 at its current growth rate.
Plus, the human brain is not very consistent. A person will do the same process slightly different each time, and sometimes vary different from the prior simply because of an itch or because an attractive female walks by, putting the brain in a different "mode".
Table-ized A.I.
..when their DVD player software did not perform 'as advertised.' A class action suit was brought, and anyone who had purchased iMacs during a certain period were invited to join.
The settlement allowed involved parties (ie end-users) to purchase Apple products, including an update to the Mac OS software, for reduced prices. I had updated the OS on my office Macs anyway, but I was able to purchase several Apple optical mice (ok, fine, they are still only one-button) for a decent discount.
Consumers need to read the fine print, and get organized. Companies do pay attention, even giants like M$.
-mj
If the user never turns the computer on, it won't crash...
Seriously, calling a crash a user error does not make it not the developer's problem--for instance, I shouldn't be able to do something with a defined function in Excel that causes Excel to crap out, and starts causing other software on my Win98 machine to act buggy (happened two days ago).
That said, I run Win98 on my gaming machine at home and have had periods of months where I have not had to reboot. Usually the only time I have to reboot is (a) power failure reboots for me, (b) I've played way too much Civ3--only game that seems to do it, or (c) I have been using another Microsoft product, i.e. an Office product especially. I don't know why the heck they can't seem to get those to work properly...
Denver Isuzu Suzuki
(* We should expect bad code because we expect code that rolls out quickly and at a low budget. We should expect bad code because most coders don't want to spend their time testing and documenting, and because most companies don't want to spend money on dedicated testers or on implementing rigid development processes. *)
It is investment philosophy that "a buck today is worth more than a buck tomarrow". This is related to the roughly 18-month turn-around time expected for any investment. Thus, longer-term issues are "time discounted" by today's biz philosophy.
There is theory and rigor to support time-discounting, and so far nobody has made a decent case that IT should be exempted, beyond anecdotes.
I see a lot of problems due to poorly planned software, yet I don't know how to debunk standing investment theory.
Is there a method to the madness?
Table-ized A.I.
Depends on the college, I suppose. I graduated from the University Of Illinois in 1986, Computer Engineering. Well organized, commented code was required in the CS classes. We used to complain that one could get a B or C on a program that "worked."
God is real unless declared integer
I'll repeat with what I wrote with added emphasis. Complexity wise, there is nothing in the universe more robust and reliable than the brain. I'll leave it to you to figure it out. Although I don't hold much hope, in your case.
I purchased a new fridge approx 4 years ago, so a '97 or '98 model, but pretty close to 2001.
It stopped working a few months back. I pulled it out and did a quick look... no fuses to blow, no fan jammed, no "obvious" problem within plain site. After a few days, my girlfriend made me call for someone to come repair it.
Turned out that the thermostat had failed after just 4 years. The warranty was only 1 year, so about $120 later the fridge was working again. He had spare thermostats and other parts in his van, and he had a full schedule for the rest of that day servicing other refridgerators... one little anecdote that perhaps my fridge isn't just one isolated incident.
So what's the point... well, had you chosen another example I wouldn't have replied, but you chose to compare software to refridgerators, and my brand new 1997 model Amana fridge failed and not only did I have to pay ~$120 for "tech support", but I lost all the food that it was keeping cold (sorta like losing your unsaved word processor document when the computer crashes).
I can't really speak to the exact efficiency, but I can tell you that it's loud enough that I can sometimes hear it while laying in bed at night, and if the efficiency were approaching 99.99999%, I think it'd at least be able to go 8-10 hours throughout the night (door closed properly) without the noisy compressor needing to turn on!
PJRC: Electronic Projects, 8051 Microcontroller Tools
Comment removed based on user account deletion
As much as I hate laywers I think mabey it's about time to let some law suits come out. As a programmer I am willing to live under a certian amount of scrutiny because I know my work will pass the test.
Software has lived far to long under the "We ain't responsible for nothin" license agreement.
I remember the a plane crash where the investigation afterword found that a peice of steel was in the plane was heated too hot when it was manufactured. This made it weaker and below standards. The found the forgesmith that was responsible for forging the peice and fired him.
Same kind of thing happened to a truck liscence tester who passed a truck driver that didn't know what he was doing and killed a family in a mini van.
I don't want to deal with which hunts in my work place but its about time some punishment for bad work, either for bad management or bad programming.
I bought a $40K car last year - brand new and fully loaded. It has a lot of cool stuff, but I still have change the clock's time twice a year to adjust for daylight savings! Nobody considers the car to be dumb because of that. I haven't heard anyone talk about the clock as a 'bug' in the car's quality. Why is that? I work in software and I agree that software quality needs to improve a lot, but people tend to ignore the complexity of software. Most software have complex (and yet configurable) interfaces and that plays a major role. If you look at two 1998 Honda Civics owned by two different people today, you will find that they are essentially the same (except for the hood ornaments, perhaps.) But, sell a PC with the same configuration to two different people and look at it six months later - they will have almost nothing in common! Users can do almost limitless things with their software as opposed the standard five things that you do with any other appliance or machinery. I agree that software quality today is worrisome, but please give software a break. It is not that bad.
All your favorite sites in one place!
--complete exaggeration. I learned to type on a manual, a self powered bio-drive manual. First "word processor" I used was simpletext, big surprise, it still works. Now if you mean a 'word processor" that uploads web pages automagically and dynamically codes quake 16 demo modules and shows videos underwater after bouncing off a satellite-well, maybe 30 grand.
In other words, get real. Ya'll get paid well, do your fscking jobs, that's from a consumer. If you can't do your jobs, expect some indian or chinaman to do it for you for 100$ a week, because THEY WILL. In case you haven't noticed, it's happening now. This is called "a clue", buy one at your leisure. Or, concentrate on coding and playing your video games until you wake up unemployed, which will happen, whether you like it or not. Produce saleable products, or watch your competition overseas do it, undercut you serious bad, and be forced to mow lawns or something, YOUR CHOICE. If all that is available is crap, then the cheap crap will get sold first. Look at open source right now, the inroads it is making. Now ask "Why?" Is it all that much better? Nope, it honestly isn't, it's roughly the same for most softwwares apps. It's cheaper, consumers and professional bean counters are just tired of paying really whopper bucks for stuff that just plain ain't that good, "sort of working" is not the same as "working". Official propietary stuff is marginally better, but not for the price difference. I know I vote with my wallet, all the time. If all my choices all fall under "almost works", then I'll just pay for or aquire the cheapest version. If I have a need, and there's a product that works as advertised and is reasonably priced, I buy it. It's really that simple. Magnify my totally normal consumer attitude by millions of people, the people who actually fund programmers. this is clue 2, sorry to have to repeat it.
You buy hardware, yes? How long will you keep buying hardware that doesn't work as advertised? Well? Coded product is the same, learn from general human historical business history or become unemployed, everyone has a choice, choose once, choose wisely.
Good luck, you're gonna need it with that attitude, because luck is all you have, skill is far down the list of your attributes obviously. If you as a programmer are telling me the only option I have is a 30 grand word processor, then believe or not, I can get by without one. So will millions of other people. 30$-sure, I can come up with the money. 300$ for my small business-maybe, depends on what it does and how it is better than what I already have. 3,000$? Outta your mind, not happening. 30 grand? Seek professional help.
no, i don't
...these clueless students who enroll in other engineering disciplines tend to migrate over to CS since it's not as "balls-to-the-wall" difficult as say, EE or ME.
No, they migrate because the computer industry offers more money, is more interesting, and has more sex appeal (yes, really). In this day and age, it's where the action is.
As an ME who graduated in the mid 80s, and now tackling CS, I can vouch for the fact that to be a real computer scientist is much, much harder than to be another kind of engineer. The laws of physics and chemistry don't change, but everything in CS is a moving target. It's also way, way more abstract. And I don't think studying it in college is any easier. I'm sure ME students pull far fewer all nighters debugging their homework.
However, most of these students wouldn't have been good mechianical/electrical engineers either. What a CS degree gives them is a meal ticket. Even if they never become a good computer scientist, without an inkling of what an algorithm is, they can at least emerge from college with a trade-school level of ability as a programmer. And even that makes bank- a run of the mill programmer might make more than a senior engineer at an aerospace firm.
The solution isn't tools to automate a large part of the writing of code. This will stop many errors, but won't give the kind of reliability you're talking about. The solution is to develop tools to make it easy to use genetic algorithms to evolve your software. As soon as this process is cheaper/easier than coding by hand, it will instantly become the dominant way of developing software systems, because the end result will have the kind of rock-solid reliability you're looking for. Granted, you won't have any idea how it works, but the trade-off will be worth it.
A lot of companies don't hire CS grads, because Math, Physics, and ME/EE grads have far better math, logic, and modeling skills, and are often smarter to begin with. Programming itself is a trade school level thing. What counts is what's behind the code. Get someone who understands that stuff, and you can teach him to implement it- but not vice-versa.
"Readers point out the story is a reprint from Technology Review(one of the few good magazines I get -- but this issue hasn't arrived yet :)."
One of the used-to-be-great magazines I'm getting ready to cancel since, save for this "shocking" article, its parent has more and more become the "Microsoft Institute of Technology" with so much glowing MS fluff.
Gotta wonder if all this MS "my bad" coming from the Beast's associates is all carefully by-design PR from MS's new "trustworthy computing" crap.
I could--as anyone reading ./ probably could--isolate the bug in ten minutes given the source.
The joke's on you, MIT.
Y'know, if you're going to laugh about a boo-boo committed by one of the greatest science institutions in the world here on slashdot, perhaps you should at least make sure your post doesn't have boo-boos, like getting the order of the "dot" and "slash" mixed up (dotslash?)
GMD
watch this
Doesn't count as software since it will never see the light of day.
As for your other complaint, that this will make average people think "all software systems are going to kill U.S. Marines and crash ambulances into each other" -- well, I guess I have more faith in the readers than you. I don't think a reasonable person would get this impression. But hey, maybe I'm wrong. -- Charles C. Mann
Software is complex because the number of possible pathways in most programs grows exponentially.
Consider a simple graphical user interface consisting of 16 checkboxes. That means you have 2^16 (or 65,536) different possible inputs. Can a software company afford to test all possible inputs and outputs? For every logical branch in the code thereafter, multiply by 2. See why software is complex?
We all see software that sucks, but most software actually works great.
... every time I call my wife, it goes right through ... and my car regulates its own emissions (even though I haven't changed the oil in 6000 miles). Well I could go on.
....
My microwave works flawlessly
So when Watts S. Humphrey says, "Software's simply terrible today," I just laugh. I spend all day on a computer, but 80% of the software I use I never see, and it performs flawlessly.
I am doing all I can not to slip into a ranting rage at this lame article
"PS. I don't include VB as a professional language"
I guess you're not "one of the unfourtant(sic) saps in the business world of programming"? When you need an internal app to do one specific thing on one specific (windows)platform, why would you write it in anything but VB? Getting the job done makes the boss happy. Doing it elegantly or in a way that's easy to port to ten other platforms doesn't mean diddly to your boss. Business needs are RAPID, all this 'engineering' hooey doesn't apply to one of the largest areas of programming employment, which is small to medium businesses running internal apps. These apps are not battleships, they're canoes. Don't fault them because they're not battleships. That doesn't mean they can't be WELL-CONSTRUCTED canoes, and mine certainly are, but they'll never be battleships. At my company half of the business needs from 2 years ago no longer apply, the company didn't even exist 10 years ago, but if it had all of it's needs would have changed over this time period. Investing too heavily in an internal app makes you unwilling to change your business model from that dictated by the app, which is not a good decision.
--I think a lot more people would see if it was practical to sue. The EULA is a codified get out of jail free card. It has to GO. It's a form of universal monopoly that no other product has except major league baseball. That's why it's so important to defund microsoft via the legal system-yes, some of their stuff works, but so much of it doesn't, and it's so lame, and they used illegal practices to get to the point where it's hard to sue. Once they are cracked and destroyed financially-like enron was and arthur andersen-THEN you'll see "good software" on the market. When coders and CEO's actually go to jail for ripping people off, for lying, for releasing products they know are broken from day one- then you'll see less but BETTER software on the market, and the consumers will buy it and use it. they have little choice when ALL the products on the market all are broken and suck. We don't have capitalism yet in the market, they (software companies in general) just paint a facade on it and call it capitalism, when it's more like a mafia protection racket.
Yes, I know this is overly simplified, but it's more or less true, though.
The day before Microsoft was declared by a judge to be a monopoly, MSNBC ran a story that tried to prove that Microsoft was NOT a monopoly.
Take another look at any news page on MSNBC. How many times are you branded by Microsoft trademarks throughout? Another time, they ran an article about competing OSes, and Linux got mentioned three times by name, compared to the 70 times in the stories and surrounding advertisements that Microsoft got mentioned.
I will admit I'm surprised about this particular article, but it's not like they have an anti-MS agenda.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
In reality, I stop using software that doesn't work. That means I don't buy the next release of a commercial product, or I don't download the next release of a non-commercial product.(Why should I trust them to get it right the second time around?) Procuring either kind of software represents an exchange of my resources for the vendor's resources; if the exchange is not equitable, I'll shop elsewhere.
-- Slashdot: When Public Access TV Says "No"
"It didn't help that so many of the people quoted had no idea what they were talking about, and the ones who did had their quotes taken so far out of context that they made no sense."
As the author of the piece, I'd be interested to learn a) why Nathan Myhrvold, Peter Neumann, the folks at SEI, and the other people I spoke with don't know what they're talking about; and b) how you know I quoted them out of context. Have you read the transcripts of my interviews?
"It seems a lot of people who never worked at Microsoft know how Microsoft develops software."
I think the people whom I spoke with at Microsoft -- as well as the ex-Microsoft developers -- know how the company develops software. I mean, didn't you read the article?
"It would make more sense to talk about a particular class of software and bug and then discuss why it is there. E.g. why do Microsoft systems products have buffer overflows."
Not in an overview article, which is what this is. This complain reminds me of Dawn Powell's complaint that much criticism boils down to the remark that if you were driving my car you'd go to some other destination. Well, fine, but it's my car -- I wanted to write, and was asked to write, an overview.
--Charles C. Mann
Here's the gist of it. Coding is too simple. Give any fool with half a brain a reference book and a couple months, and poof! he's a programmer. There need to be more stringent requirements for coders, more education in proper coding, and more quantifiable tests of a coder's competancy. Unless we find a solution to the problem of unprofessional coders, we are trapped in the age old truism: Garbage In, Garbage Out.
Usually, software is released too quickly without enough testing. Awhile back my boss was on my case because I kept saying my program wasn't ready yet. Eventually I said it was ready. A month later, some of the other projects were hitting snags, but my stuff kept chugging away.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
I'm not ancient, that's all. I wasn't a programmer when those languages were being used. Are you fully up to date on the W3C's DOM standard and how to write cross-browser compatible script? No? Software is too big to be the uber-geek, you specialize in one area. And I for damn sure ain't gonna specialize in dead languages that don't mean squat to a potential employer.
I get the sense that you're one of those crotchety "Back in the day of punch cards, sonny boy..." types, or are in danger of becoming one. I'm a business application developer, not a software engineer. Don't tell me i'm too sloppy, and i won't tell you you're too slow.
We have to look at the psychology of the buyers of computer software to understand the bind that software makers are in. If they create a more reliable version of their older product, most users are unwilling to pay for these "bug fixes" in Version 1.5, but they are willing to pay for the new features in Version 2.0. If you are are in the business of sales, you sell what the customers will actually buy, not what they say they want, but don't buy.
People decried vehemently Microsoft's attempt to gain a revenue stream for patches and updates with the Office XP licensing scheme, but how can one improve quality of existing products if there is only a revenue stream for selling newer more complex and buggy products. Until there is actually money in making better software, we will not get better software.
And there are but two ways to make money
- Increase sales
- Lower Costs
If one can't increase sales by selling better software, then we need to have lower costs (fewer lawsuits, fewer cancelled contracts etc.) by having more reliable software gain advantage to its maker."I think this article is an attempt to get public opinion stirred up to the point that UCITA laws - which include things like mandated warranties on software products -seem like a reasonable solution, and thus make life more difficult for MS's competition."
As the author of the article, I was astonished to read this. I can tell you that Technology Review, which asked me to write the article (and from which MSNBC reprinted the article) has no connection, financial or otherwise, with Microsoft; that Microsoft was unenthusiastic about the article (but, my hats off to them, made some of their people available for interviews); that UCITA laws explicitly do not make mandated warrantees but instead guarantee the lack of implied warrantees of merchantability now dubiously codified in software licenses; and that the claim in this comment was especially mind-boggling given that I was one of the first mainstream journalists (in a 1998 article in the Atlantic) to warn about the potential consequences of UCITA (then billed as article 2B of the UCC). --Charles C. Mann
.. the real reason why software is so crappy is that technology is improving so fast. Think about it for a second. If tomorrow Intel/AMD/whoever announced that the current processors was as fast as things were going to get, what would happen? Developers would be forced to write code more efficiently. If we're stuck with Pentium IV's forever, well we better squeeze every last ounce of goodness out of each clock cycle. And in the meantime, hunt down bugs that cause problems and/or efficiency issues. As it is right now, programmers don't care much if their code is bloaty and slow. By the time it hits the market, processors will be faster, everyone will have more RAM, and it'll run fine. And for version 2.0, they just add more features and bloat.. since processors will be even faster then. It's like a constant race for all the bells and whistles possible. If we started hitting real limits of speed, memory, storage, then coders would have to be better.
This made me laugh so hard:
Rivard was one of several to point out that MSNBC says software sucks.
MSNBC.
BWHAHAHA thanks for the laughs, jagnecks.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
Not where I went to college it isn't. Ironically, out in the real world what I'm asked isn't "Is it correct?" or "Is it safe?". I'm asked "Is it done?" It's ironic that Myhrvold is 100% right. Microsoft shovels crap at the consumer because the consumer has a ravenous appetite for it.
As for open source, I'm not impressed. I don't think I've yet seen a piece of open source code and been impressed with its maintainability. Some has been horrifically awful, including the C monstrocity which used #defines to make C look like Visual Basic. I'm not yet convinced that open source's primary value, and the one which dwarfs all the others, is that it's generally free as in beer. Documentation, which is critically important, is usually bad and often nonexistant. I'm keeping an open mind, but I'm still waiting.
You're fucking nuts man. There's only so much a programmer is really worth. If you're using your skills in X, Y, and Z, then you're not using your skills in A, B, and C. So from the point of view of the company, you're no 'better' than someone who just knows X, Y, and Z. Your skill at XML for example doesn't benefit from your knowledge of Fortran. And while you may know Fortran and I don't, we may both know the same amount about XML. And if you're asking 200 k and I'm not, why would the company pay you that much? I'm not talking project managers, technical architects, etc. which do command higher salaries and require a broad technical background, just programming jobs. 3 65k a year programmers will produce more than 1 200k a year programmer, you'd have to be walking on water while coding to justify that price tag.
I'm probably letting my co-worker Ralph affect my view of you, he's very much the crotchety type I was talking about while I've never met you. But my being from a different generation is no reason to dis my skills, programming is programming regardless of the language. You're either good or you're not, and if you've been in it 20 years, I'm sure you are too.
P.S. DOM does not date back to the 70's. That is patently a ridiculous statement. No web standard predates the web. Neither does XML, though admittedly the SGML it has its roots in is as antique as you say.
It's so they can excuse the fact that a trigger happy American military thug on the Vincennes killed 290 Iranians. Nothing to do with software.
Took a basic Ec course in college and all I can remember are these stupid marginal cost/benefit analyses. Seems like the answer to every test question was a graph with a randomly distorted pair of lines with roughly opposite slopes. Where they intersect ... something or other happens. OK. That was a bit off-topic.
Anyways, in most industries with high-priced alternatives, the less popular sellers simply put more resources into manufacturing a high quality product. Hand craftsmanship, expensive materials, expert designers, extensive customization: all of these things cost a heap. More importantly, the overall cost keeps increasing as more units are produced.
Software doesn't suffer from these limitations. An extra copy of DB2 costs IBM about ten cents (or whatever) for the CD. For this reason, one wouldn't expect niche software providers to prosper unless they're filling some obscure need. Just because you're willing to pay a little more than the next guy, don't expect to get a better word processor. In all likelihood, the market leader can suit your needs with (a version) his generic offering.
With software, the cost of building something that's as good as what already exists and then improving upon it is astronomical. When the rare company does accomplish this, it usually becomes the market leader rather than surviving as a fringe player. Doesn't seem to be much room for second place players. No marginal costs make it more appealing for the leader to adjust its prices to take the whole market. Even worse: there are a ton of benefits to having the same software as the next guy. Such a feedback loop makes it seem like monopoly is the state of equilibrium in the world of bits and bytes. Somehow that has something to do with the aforementioned graph.
I just learned today the meaning of F.U.C.K
:)
"Fornication Under Consent of King"
I'll be more careful when I use that word now ROFL or the king, whoever or whatever it is will come to kick my sorry ass.
Ok Ok..sorry, such strong usage of the F word deserved at least this off-topic submission
sorry
If you look like your passport photo, you're too ill to travel. - Will Kommen
If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code;
Or a better bet would to just find the Fountain of Youth so you can drink it's water, stay forever young, and then you'll have plenty of time to fix the bugs in the real languages.
-pyrrho
The problems associated with software production are unique in the world of engineering, and are mostly due to the compression of time we used to call "Internet Time." Consider the difference between software engineering and, say, civil engineering, i.e. bridge building.
1) The basic way bridges work have not changed in some time. Suspension bridges all work on the same basic principle. Software, on the other hand, is constantly changing from a theoretical standpoint. In the four years I've worked as a programmer, I've moved from procedural programming to client-server programming to web programming back to procedural (only this time with an object oriented tip) and the outlook is to move into a new paradigm. That's like designing a bridge for six months, then working on a tunnel, then moving up to a tressle.
2) Hardware is constantly changing -- meaning that APIs are constantly changing to add features and products that use those APIs have to change as well to keep "up to date." A bug in the hardware would cause a bug in the api which would cause a bug in products that use it and so on. In the bridge building world, there are only a few materials and it's easy to see if there's a flaw in them. If you've got a hunk of frayed steel cable, you don't try and wrap it with something to offset the error...you throw away the cable and the vendor eats the cost.
3) In the world of software engineering, the only engineering that occurs in most companies is low level, under the hood stuff. Basic usability design is often provided by non engineers -- marketers and well meaning product managers. This is a bit like relying on the guy who tells you what color to paint the bridge to make structural decisions. Marketers may know what sells, but they don't know what makes good software. And this is one of the main reasons for the dot com bust.
Now, nobody's proved that Time to Market is a factor in product success. In fact, waiting to do something right often proves much better. Apple dropped the ball on usability with the first rev of the Newton, and three years later a more mature Palm destroyed the proposed market for PDAs. Windows based PDAs are finally reaching the point of stability, speed and robustness that they will take the ball and run with it -- after nearly 4 years on the market.
Good software takes time and elegant design. Nuff said.
Hey freaks: now you're ju
There is a simple solution that we consumers can implement, and it doens't involve suing anyone.
Don't buy crappy software. I use all free software at home, not because I'm poor or a communist, but because I rarely see software that's worth paying money for, and when I do, there's also free software that does the same thing, if you're willing to live without bells and whistles. For example, I've discovered that almost everything I want to use MS Word for, I can use "vi" for instead. And VI is much more reliable.
I hate it when I make a joke and I get modded "+5 insightful". Mod the stupid comments "funny", not "insightful", pleas
As the author of the piece, I'd be interested to learn a) why Nathan Myhrvold, Peter Neumann, the folks at SEI, and the other people I spoke with don't know what they're talking about; and b) how you know I quoted them out of context. Have you read the transcripts of my interviews?
Neumann claims that programmers think as long as code compiles it works, and that Gates testimony that removing the browser would break XP "means there's no structure or architecture or rhyme or reason in the way they've built those systems". Those are both patently false. Cem Kaner claims that companies treat quality as secondary. That's wrong. I don't know if he said the part about bug deferral being a plot to generate later revenue, but that's also absurd. The Ariane 5 rocket failed due to an ARITHMETIC overflow, not a buffer overflow (still a bug that should have been caught of course!). Then this guy Downes claiming that excessive WIndows messages in Visual Studio is "cataclysmic. ... It's total chaos" -- I mean come on.
I should not have said, "out of context", I should have said, "without sufficient context." Someone from Microsoft claiming that C# is going to prevent errors is nice, but since IIS and XP aren't going to be rewritten in C#, and the Outlook problems were design issues, why does that matter? Myhrvold's quote was amusing, but you could point out that Microsoft can always say "No" to people, and if the customers weren't asking for features, Microsoft would be dreaming them up themselves -- the real problem is the "new features vs. stability" debate. An 18 megabyte patch -- OK 18 megabytes may be a big number, but saying "it may be a record" is silly (it obviously isn't, look at any NT service pack). Plus how much was bug fixes and how much updates and enhancements?
"It seems a lot of people who never worked at Microsoft know how Microsoft develops software."
I think the people whom I spoke with at Microsoft -- as well as the ex-Microsoft developers -- know how the company develops software. I mean, didn't you read the article?
I'm an ex-Microsoft developer (NT/2000/XP kernel) and I didn't see much I recognized. NT4 should have gone through 4 rounds of tests? What does that mean? Do you mean beta tests? Microsoft leading in component design is nice, but doesn't have much to do with preventing buffer overflows in XP. And comments about the attitudes of Microsoft people are just one person's opinion. "Software's developers were too rushed or too careless to fix obvious defects" -- I'm glad you know so much about me and my former co-workers.
I understand it was an overview article, but you make it sound like any solution will improve on the problems, and it's just not like that.
For the record, here is my opinion on why Microsoft code has buffer overflows in it:
1) Bigger teams -- if you move from 20 devs to 200 and your software is only as good as its weakest link, inevitably the weakest link will be weaker.
2) Lack of training -- Microsoft always assumed good people would do good things, instead of relying on more processes.
3) Too much reliance on the testers -- assumption was "if it's a bug a customer will hit, our testers will find it."
4) [sort of strange considering the previous point] Bad attitudes on the part of developers who think testers are inferior, combined with testers evaluated solely on number of bugs they find, leading to little empowerment for testers to actually find buffer overflows. More on that here.
- adam
While I do not have any numbers to support this, it would seem that most bugs and particularly exploits today are do to buffer overflows. This is a prime example of where programmers have not learned anything from the past.
THERE IS NO REASON WHY BUFFER OVERFLOWS SHOULD EXIST TODAY. WE HAVE THE TECHNOLOGY TO FIX OVER 60% OF THE BUGS. WHY ARE WE SO STUPID?I took C++ classes after learning Visual Basic and Java. After learning about pointers I realized why software is so shoddy. We have the technology to prevent buffer overflows, partially in better compilers, interpreted languages and partly in better object oriented programming languages.
One reason that I've very often seen lead to failed projects is assigning them to people who simply can't do them. Not necessarily because they don't know anything about programming, but because they don't know the tools they have to use.
Years ago I was assigned a UNIX - MS Access integration project where I had to translate EDI messages to Access tables. I had never worked with Access before. I told my boss that I can't do it in reasonable time, but there wasn't anyone else free at the moment, so I was forced to do it. The result was that after three months of coding, $100/hour from the customer, I had learned to program with MS Access - by learning how not to do it. I burned out and quit. The horrible software was probably rewritten from scratch.
I have seen many really horrible examples of similar situations with other programmers, often with people dabbling with C++, lately with people who simply don't know how to program with C. Oh, what incredible examples I could give you! The result has been indescribable garbage. The garbage often works in the planned test cases, barely, but bleeds memory like a pierced pig and crashes from a slightest variation.
Many of these catastrophies occur because the programmers do not honestly admit: "I can't do this." And even if the programmers would admit, their managers won't when dealing with the customers.
All tools require learning. Some have a soft learning curve, some steep as a mountain. It doesn't matter much how professional one is, when it comes to learning new, conceptionally very different tools. Managers don't often understand this.
Just as often, programmers are assigned to projects of which they do not have a clear vision, usually because of too superficial specifications. Without proper vision, they can't find the right attitude to write beautiful, perfectionist code. They need inspiration, and finding it often takes time.
Basic human nature: I want it now! I want it cheap!
Most people have a certain amount of dysfunction in their life, so they are used to the concept. So software that fails keeps them in their comfort zone. Most people get worried when everything goes right.
Nicolo Machiavelli advised every new prince to not make life to hard on the body politic, otherwise they revolt. Microsoft, Et al, might be close to a revolt? Maybe, maybe not.
Cy
(* As for automating 90% of the software design process, I believe that's referred to as adding layers of abstraction. *)
"Layering" can only take you so far. In complex software, abstractions tend to need to be *relative* to a given task or user or situation. The "encapsulation" or shell approach does not satisfy this very well because if you have a need or change that is smaller than the granularity of your capsule, then you often have to bust it open and fiddle with its innards.
Although the human brain has "departments", the interfaces to and from these is relatively open. Control-happy One-interface-fits-all generally does not cut it.
Layering worked fairly well at a very low level, but it is not extrapolating further up the complexity food chain we are finding out. We need to think more about sets and graphs and multi-dimensional view managements rather than keep trying to kick the overburdened shell/tree/layer-horse up the hill further.
Table-ized A.I.
I wish I'd written this...
Once you start playing with software you quickly become aware that each software package has a revision code attached to it. It is obvious that this revision code gives the sequence of changes to the product, but in reality there's substantially more information available through the rev-code than that. This article provides a guide for interpreting the meaning of the revision codes and what they actually signify.
1.0:
Also known as "one point uh-oh", or "barely out of beta". We had to release because the lab guys had reached a point of exhaustion and marketing guys were in a cold sweat of terror. We're praying that you'll find it more functional than, say, a computer virus and that its operation has some resemblance to that specified in the marketing copy.
1.1:
We fixed all the killer bugs ...
1.2:
Uh, we introduced a few new bugs fixing the killer bugs and so we to fix them, too.
2.0:
We did the product we really wanted to do to begin with. Mind you , it's really not what the customer needs yet, but we're working on it.2.1:
Well, not surprisingly, we broke some things in making major changes so we had to fix them. But we did a really good job of testing this time, so we don't think we introduced any new bugs while we were fixing these bugs.
2.2:
Uh, sorry, one slipped through. One lousy typo error and you won't believe how much trouble it caused!
2.3:
Some jerk found a deep-seated bug that's been there since 1.0 and wouldn't stop nagging until we fixed it!!
3.0:
Hey, we finally think we've got it right! Most of the customers are really happy with this.
3.1:
Of course, we did break a few little things.
4.0:
More features. It's doubled in size now, by the way, and you'll need to get more memory and a faster processor ...
4.1:
Just one or two bugs this time... Honest!
5.0:
We really need to go on to a new product, but we have an installed base out there to protect. We're cutting the staffing after this.
6.0:
We had to fix a few things we broke in 5.0. Not very many, but it's been so long since we looked at this thing we might as well call it a major upgrade. Oh, yeah, we added a few flashy cosmetic features so we could justify the major upgrade number.
6.1:
Since I'm leaving the company and I'm the last guy left in the lab who works on the product, I wanted to make sure that all the changes I've made are incorporated before I go. I added some cute demos, too, since I was getting pretty bored back here in my dark little corner. (I kept complaining about the lighting but they wouldn't do anything). They're talking about obsolescence planning but they'll try to keep selling it for as long as there's a buck or two to be made. I'm leaving the bits in as good a shape as I can in case somebody has to tweak them, but it'll be sheer luck if no one loses them.
I didn't think the house band in Hell would play this badly.
Just to point out that in C# you have to put this inside 'unsafe' code blocks.
Apart from that c# is a bit of an abortion. Gratuitous syntax changes from C++ and Java just for the sake of it. It's MSDOS file path seperators all over again. Rather than making it easy for C++ or Java programmers to migrate they put lots of little stumbling blocks in the way. Like I've now got a Console class rather than cout or System to write to the Console. Well I suppose you could call it a clean-up.
The language has lots of kludgey stuff for the Microsoft world obviously concerned with backwards compatibility.
The main problem as far as I can see with the whole .NET strategy is that you are forced to use Microsoft tools. Like the notoriously insecure IIS. This rather blows out of the water that using existing development frameworks will help you reduce the errors in your code.
Oh, don't tell me about Mono as an alternative, it will never see the light of day.
David
Well, as qa, most people do not know what they want. Only knows that they want something cool. It is also true, that Microsoft and the open source community, (let the flaming begin) know nothing of Quality Assurance. Especially the Open Souce community, if there were practices and proceedures put in place software would be lot cool.
There is a fairly direct inverse relationship between how generalized an operating system is and how hard it is to get stable. For example, engine management computers are not susceptible to remote buffer overflow exploits from the Internet. Or new applications and drivers being installed for that matter.
Look at the Xbox OS, a Microsoft product. I don't hear about it crashing. Why is that?
- adam
From the article: If anything, they say, it's getting worse. It's as if the cars Detroit produced in 2002 were less reliable than those built in 1982.
Okay, so given that cars have more s/w now than they did in 1982, why are they not less reliable? It seems like the embedded programs must be pretty robust. I know I've never had trouble with the software in my car that runs behind the scenes.
Me too.
Maybe the human brain is what Windows is modeled after. It does most things right most of the time. But sometimes it will fail to perform a task it has performed right 100 times before. It is sometimes impossible to figure out what has caused it to fail. It failed just because. "Oops, sorry."
There is one thing about a craft based manufacturing process: the true mastercraftsmen can produce a product of much higher quality than can be produced on an assembly line. The problem is that masters of the craft are few and far between, and they are never able to mass produce anything. It is true that many engines ran on a hope and a prayer. However, there were also gems that could never be matched in form or function by mass produced items.
Exactly the same thing can be seen in software development today. A small minority of programmers produce incredibly robust, elegant code. Thankfully, irregardless of how software "engineering" develops, there will always be masters at work.
One of the main problems with writing software is the fact that it's always creation, never replication. The difference between making cars and software is that designing a car is easy, and manufacturing them is hard. With software, the reverse is true. Designs can take weeks, with writing it taking even longer. When it comes to creating many copies, just hit the ol' copy button, and bam, you can have 3 million copies on your hard drive in ten seconds. Add to this the fact that you never actually see the software being copied by the computer, as you would on an assembly line, and you begin to see the problem.
Re-use is also a problem. Sure, criticizing the software industry for not employing re-use is easy, but when it comes down to it, no piece of software is the same. Even with reused libraries, the most one can ever hope to achieve with code re-use is having 40% of a program already written. After that, it all has the massive potential for bugs.
To employ the car analogy again, realize that it's easy to see that a car has no wheels, but hard to see that a piece of software lacks a certain feature.
Look at Arthur C. Clarke's response when someone said, "90% of SciFi sucks." "90% of everything sucks."
The bottom line is that most of the people are in the industry like to work with computers and fancy themselves good programmers but really are not as good as they think they are.
Take a random group of programmers and put them in a room. Then say, "All of you who are good programmers go to this side, all of the mediocre and bad ones go to that side." All would move to the "good" side. Yet if you were to say, "All of you who can juggle five balls move to this side, and all of you who cannot, move to that side.", it'd be a different response. Granted, one is a subjective measurement and the other is objective, but I think a lot of people just don't realize how poor their coding skills are.
Look at the questions in newsgroups or email lists. Granted, some people are new and on the new side of learning a particular technology. But watch them over time (or go back and review their activities from the past). Many are too lazy to make a couple of simple queries via DejaGoogle or the list's archives using some of the very words they pose in their question! And when you point out how to look up the question using a known link and specific words from their question (no aces up the sleeve), they seem offended until someone posts the specific answer for them. The response, "Well, at least someone knows what a list/group is for!"
Summary: It has nothing to do with intelligence, it's about aptitude. Most just are not cut out to be code jockeys but cannot resist the lure.
Just to clarify, the complaint is NOT that the operator requested high power levels and the machine delivered. The complaint is that the operator requested correct power levels, but in the course of editing pressed some cursor control keys in an unanticipated way, causing the machine to mysteriously fry the patients.
Every corporate project I've worked on in the last 10 years has been marketing driven. Not only that but the requirements change from day to day. Which in my estimation means that the marketing guys aren't doing their jobs. They will tell you that the market changes fast and we have to adapt, but the truth is that its their job to predict the market ahead of time. That's their job right? Granted it's not an easy task, but the point of marketing is to gauge the market and determine what we need to build now in order to meet market demands later. Again, I've never seen it work that way. Instead, marketing delivers what the market demands are today and expects solutions squeezed into a schedule that is already bursting at the seams.
But wait, it gets worse. When the crappy product goes to market then engineering gets blamed for delivering a bad design. And, on the rare occasion when engineering says "No" and that answer is accepted (rarely happens), then engineering is blamed for losing the sale. Its a lose/lose situation and at no time is marketing *ever* held accountable for *anything*.
Its all very discouraging.
The main problem as I see it is a lack of well defined requirements. If engineering knows what to build and is given the resources then they can get the job done. But, when the requirements are constantly changing then it means we really don't know what we're building and nobody should be surprised if the final product isn't solid, given that environment.
You want a good product here's what you do. Write a very good Marketing Requirments document. Make sure it covers all of the *important* details. Have engineering analyze the requirments and come up with a first order schedule. Then you start writing software/hardware/system requirements documents, followed by design documents. All of the important documents need to be peer reviewed. Then you can make another schedule estimate and start building it. CMM level 2 compliance helps keep the checks and balances in place but of course you still need good designers.
I'm working on a project now that is taking this approach and it is definitely working. The only question is whether or not the Marketroids are going to drag the requirements around all over the map when we are midstream.
Blaming bad s/w on changing requirements, lack of (test) resources and the like gets old. The best developers I know balance the demands placed on them against the resources they have available to produce a product that has the best possible mix of features and quality for their market. Sure, the situation is never ideal but that's part of the game.
To me, this balance is the crux of *commercial* s/w development, not keeping up with the latest silver-bullet technology that's suppose to fix all your problems and pad your resume.
-BxT
I would love to see a lawsuit make Open Sores illegal to use in any commercial or government body because of it's complete lack of record keeping, QA, or any other semblence of responsible coding. That would be ultimate irony for you "Litigation solves all" of you.
From the article "Software sucks because users demand it to." This is according to Nathan Myhrvold, former chief technology officer of Microsoft.
Yeah, we demand that you give us shitty software!
If this is MS's marketing strategy then it explains a lot. Fscking morons. How do people like this get to be CTO?
He also says, "If Microsoft had not kept pumping up Word with new features, the product would no longer exist."
That's also a load of crap. My expectations of a word processor have not changed substantially in 10 years. I want text formatting, spell checking and the ability to insert tables and graphics. That's about it. Automated TOC generation and real time spell checking are about the only features added in the last 10 years that I've found useful. The rest of it is useless to me and useless I expect to 99% of the market. Most of the auto-"correct" features I have to turn off because they often turn out to be auto-incorrect. Also the last couple of versions have been buggier and therefore less useful than previous versions. I expect this is due to feature bloat. Real improvements to Word could be made by organizing the UI in a better way, but MS won't do this because they love legacy. So users are stuck with the same poorly organized, poorly worded menus they had 10 years ago. Word exists today because MS squeezed all competition out of the market. I use Word because my company mandates it, and for no other reason. We have a legacy of Word format documents.
Ummm...arn't projects like GTK, QT, all the "visual" projects (not to mention GLibC), and all the other common libraries and scripting languages trying to create common toolkits for programmers?
In my mind the no returns on opened software policy by most software retailers has a bigger effect on the crappyness of software. Since on one can return a defective product, there is substantially less motivation to improve it.
Another possible reason that most open source software (OSS?) is less buggy than its comercially developed alternative is that the open source programmers probably USE their software and therefore find the bugs and are motivated to fix them.
Galium Arsenide is the material of the future, and always will be.
I run those two os's on my little PS/1 computer, and although Redhat 6.1 works, it is quite slow, compared to Windows 95. On both, I connect to the internet, and run the Opera web browser. All I can say is, thank goodness for Microsoft, and Windows 95. I know this isn't fair, but if life were fair, I would be able to run out and spend hundreds of dollars on a new computer that would be so fast and powerful that I could not tell the difference between the speeds of say, XP, and the Latest Redhat distro. Not everyone has that kind of money, and thank goodness that folks like me can just do with whatever we dig out of the junkpile, and make it do.
I love fixing up Redhat the way I want, and on slightly faster equipment, it is ok. The first thing I found out about Linux is that it needs some power behind it. You know, when linux boots up you get a speed measurement (bogomips?) This little PS/1 runs it at about 20 megs a second (slow), where an AMD K6-2 can run about 740 megs a second. Windows 95 seems to run real well on some of these older boxes, so Microsoft gets the credit there. Eventually, I suppose, Microsoft will get sued out of business so I suggest that those of us that can make Redhat dance will be in demand:-)
I think it is wrong to assume people will flock to an OS that is more secure. It's not just cost...how can it just be cost? If it were just cost, people would all run FreeBSD which is more secure *and* costs nothing. So that points out one reason, which is that most people don't buy an OS, they buy a computer and it comes with an OS.
Anyway, imagine Microsoft was suddenly forced, due to lawsuits or regulation or liability worries, to produce a much more secure OS. So what would they do. Well first of all they would severely limit the apps and drivers that would run, likely requiring their own certification. Do you think Real/AOL/Netscape would like that? Then they would say that no DOS or Win16 apps were supported. Then they would say it will ship a year later so you can't use your fancy new hardware until then. Suddently, most of those people who were supposedly demanding a more robust operating system would change their tune.
- adam
"Exasperatingly, software vendors deliver buggy, badly designed products with incomprehensible help files -- and then charge high fees for the inevitable customer service calls."
1. Write buggy software
2. Charge extravagantly for tech support
3. PROFIT!!!
Democracy is two wolves and a sheep voting on lunch.
This is exactly why methodologies like Test First have been gaining popularity, along with their supporting tools like JUnit and NUnit, exist. When you're coding strictly against you're compiler, and perhaps some defined design, the only errors you'll see are compile time, and in the case of java or (insert scripting language here), run time errors. Logic and design errors are revealed through testing your software, usually in the form of unit and/or integration tests, figuring out if your software does what it's actually supposed to do.
.NET (C#, VB, etc) code. Because of the complexities involved, I doubt a generic CUnit or C++Unit could ever be engineered for generic distribution. The best support I've found is just to get the developers to think within the guidelines of test first.
t est_first/n et
Test First methodology actually takes this process one step further, elevating logic errors to the level of obviousness that compiler errors have. This is key, because it helps break the mindset of the assuming programmer that if it compiles, it must be fine.
Unfortunately, the tools I've seen that support test first only work in the context of testing Java or
I personally think this methodology, like any other should be viewed as a possible tool to use to solve some problem, in your specific project environment and schedule and what have you. But thinking along the lines of trying to test your software before you build your software will help you to write more robust code.
-ds
References:
http://www.junit.org/news/article/
http://junit.sf.net
http://nunit.sf.
Likewise, you'll hear endless amount of bitching on the net about how X piece of software has been delayed again, yet when they finally give up and stop fixing bugs and release it, people will complain that it has bugs and needs to be patched. I wonder how many of those complainers are the same people who were complaining about the delay as well?
Like jamie said, if companies kept the projects in shop long enough to fix _everything_ they'd probably go bankrupt.
Good planning helps somewhat, but you really only have time for that at the begining of a project. And almost as soon as you finish planing and start working management starts demanding changes based on testers' responses or because of some new thing that a competitor added to their product.
This Space Intentionally Left Blank
The problem is not exactly new. This link dated February 1999, gives a conservative estimate of how much the problem costed then.
More interestingly, I'm currently writing a report as an "Expert Witness" regarding the quality of a system. In simple terms, the maker of the system is suing the customer for payment, the customer is claiming that the system doesn't work, and counter-claiming. And that's about all I'm able to say about it (and no correspondence will be entered into).
Things like the validity of disclaimers are being thrashed out in various places round the world as I write. In my case, it's under Australian jurisdiction, so YMMV as regards its application to you. Litigation is happening, just maybe not in your part of the world, or not today. But there is now a demand, even here in Australia, for IT Experts to help explain to "naive users", Judges, Magistrates, Juries, and more importantly Lawyers and their clients, what all this IT stuff means.
The Australian Federal Court has given some guidelines for Expert Witnesses that basically state An expert witness's paramount duty is to the Court and not to the person retaining the expert. Again, YMMV on this one, but IMHO such guidelines are a good ethical road-map for anyone anywhere considering work as an IT Expert Witness to follow.
Anyway, gotta get back to it, they want the preliminary report pronto.
Zoe Brain - Rocket Scientist
As a consultant with more than 20 years experiance one might say I've been around a bit.
My career as also been quite interesting in that I've worked both in engineering departments as weill as oil exporation departments. As a programmer this leaves me an exception to the rule.
My observation is that of the chief geologists that I knew or worked for, ever one without an exception was very professional and well regarded by those who worked for them or with them. Without an exception they were damn good geologists too.
Of the engineers that I worked for, again without an exception, they were very professional and without an exception they were very good engineers. I can say the same of the geophysists I know.
On the other hand, the programming mangers have in many cases been rather awful! One manager ran a department where people were afraid to talk to each other. This company at the time use to have everyone log off the mini when one of their accounting programs ran and the reason was so that the accounting program would not run out of "shared library entries". This had been going on for more than a year before I started my contract. They never fixed the problem because no-one knew how and the reason IMHO that they didn't know how was because no one talked to anyone. The patch would have taken about 15 minutes to fix. BTW - that manager ended up becoming a VP of information technology in a major oil company whos name begins with "M".
I say he was probably a rather bad manager over there too.
Another manager I know - He supervised me when I was in my 20's for about 4 months before he quit - was SO BAD that he did not know that floating point fields are not good for accounting. He did not even know the BASICS of CS. Of course - most of the programmers in that shop knew dick all about number types too and couldn't debug their way out of a paper bag. As above so below.
Another manager (VP this time) didn't know the difference between an algorithm and a logrithm.
The managment of another major oil company whos name starts with "S" and rythms with Hell tried to develop a production accounting system in "basic". The version of basic they were using supported only 16 bit integers and you could not write a callable function. It was a very primative basic. They failed. I remember that project specifically because these people came over to OUR SHOP to see what we were doing (we were doing some rather terrific things - through no fault of our management) and I told the *hell people before they started that if they tried to develop in BASIC that they would fail. They failed. My opinion is they were idiots to try. Nobody in their right mind would do this. The management should be FIRED for this because the MANAGMENT should know better!!!
Then there was another major oil company who's name began with a "G". This company was offereed a turn key application for a system completely loaded with data that they wanted. They paid 1/4 million for the data. Well, their management decided that they should hire a consulting group to build a "better" system. A year later they had spent more money on their consultants than the system we offered and they had not written one line of code.
In all cases - it was bad managment. Really bad managment and somehow the twits got away with this level of incompetance.
Interesting... I know of zero bad chief geologist or chief engineers or chief geophysists for that matter. Yet I can string out a list of bad programming managers as long as my arm. These are people who don't even know the BASICS of the profession. It is no wonder they can't hire and retain competant programmers. The good ones leave in frustration!
As a case in point - in any shop ask whether they have built and documented a library of software functions. Is there a resource person in place to help new programmers become familiar with it? If not - then the programmers who generally are already reclusive and hate to document (many hate to read) will each re-invent the wheel every time they do something. Since searching and sorting are 2 of the MAIN FUNCTIONS of any system, over time these primadonnas will develope 10's or even 100's of variants of usually really bad implementations of poorly chosen algorithms.
Any programmer who develops yet another sort routine on company time is an example of this. But if a programmer does this then why pray tell doesn't his/her manager know about this and hold him/her accountable? It still comes down to the managment.
I have heard it said that a manager doesn't need to know how to do - he needs to know how to manage people who know how to do. Well - this is bullshit. Imagine a chief engineer who doesn't know his engineering. Imagine a chief physician who doesn't know his medicine. Where did these stupid ideas come from? A programming manager has to know his programming and he needs to know his machine internals too. If he doesn't then he is not even in a position to be able to evaluate the productivity of the people hired to do the development work. Furthermore he certainly would not be in a position to know when his development people are about to undertake a real blunder.
There will always be incompetant programmers around. The real problem is when incompetant management gives them the green light and then wonders later why nothing works right.
If one applies this idea to software companies then one would have to conclude that a company run by an ex soda salesman isn't likely going to be able to develop good software. If a major software company has to shut down development for 2 months so that people can be "trained" to develop tight software then you know for a fact the management was incometant from the outset because the problem should never have developed in the first place.
One thing I did learn rather early on as a consultant is that there are good managers and good shops. I chose not to work for the bad ones. There is still a LOT of work around for good people.
What causes shotty software? Well the real question is... what makes a certain piece of software so bad from another? Lets take a look...
Internet Explorer versus Opera
Both have robust features. One has a tendency to be more buggy than the other. One has a tendency to be free with out a need for registration. (No I didn't mean activation) One supports multiple OSes one supports very few. One is an absolute industry standard, due to its OS... one is not.
It all depends on a consumers stand point. I think when someone says software sucks that they are talking about some cheap piece of shareware. I have found many apps for Windows and Linux and OS/2 that are quite good and get a specific task done and done well. I think that other pieces of software (i.e. Banzai Buddy for Windows) are the worst incarnations in code.
I think that software is fine depending on what software you use and what you need it for. Then again I think all software is rushed because management can't wait to make a buck. (I also think developers are somtimes taken for granted)
BTW... I would like to see the numbers on how MS has cost consumers 8.xx billion dollars. I would like to see the validity in that. (Not that I am an MS supporter, I just hate rants)
~Char Lander
Brothers and sisters I have none, but this mans father is my fathers son
There have been *lots* of startups - mostly started by software engineers - that wrote great code. You've just never heard of them, 'cause the other guys - the ones who valued time to market over bug count - won the race.
(OK, the guys also completely forgot to consider market demand, and wrote stuff only they would buy, but that's another story.)
construction worker aren't union, get $12 an hour overtime have more responsibility and decision making than senior software engineers, and have to pay their mexicans if they want them to come back (which they don't)
True, but I would think that GIMP developers had a head start by having benefitted by learning the lessons that Adobe learned through trial and error, in terms of what sort of features are useful and desirable, what sort of interface makes the most sense, etc.
You see? You see? Your stupid minds! Stupid! Stupid!
Someone above commented that, as soon as he finished his degree, his workplace would not *allow* him to take the time to design code properly (lack of design being the main problem). Sure I think that more rigorous CS degrees (in some cases) will encourage proper design if people are given the opportunity.
What we really need is for someone to draw up a few different coding philosophies with various different tradeoffs (ie. "we want (reliability|security), no matter how much time it takes", or "We want a reasonable amount of reliability, and want to get it out in a reasonable amount of time", or "We're in a hurry! Fast coding required"). Then companies could specify the policy they use in their job ads, and people who know how to code properly can avoid the wrong ones.
However, what company is going to admit to cheap and fast...
In summary, there are two problems:
1) Poor coders
2) Management rushing coders
You've addressed problem 1, but what about problem 2?
:)
(* This might be provably false with a not-too-difficult study.*)
You are welcome to prove it.
(* How is it easier to read a language that doesn't tell you the types of the variables up-front? *)
If the variables are named well, I *do* find them easier to read without all the declarations and conversions. Especially in the web arena where numbers constantly need ascii-tizing.
And, I *started out* with stronger-typed languages, so my preference for dynamic languages is not out of habit.
(* Which is clearer for the AVERAGE programmer *)
I don't see what your example has to do with typing issues? Besides, what is "easier to read" tends to be subjective. I have learned to try not to project my preferences onto other brains unless proven similar first.
(* Dynamic, untyped (or weakly typed) languages are bad. *)
Oh really?
I am sure some very successful LISP and Perl fans are going to have a word with you. (I personally dislike Perl, but not for its dynamic typing. That is a plus of it. Its seperation (non-overloading) of numeric comparers from string comparers is a nice feature IMO, once you get used to it.)
Table-ized A.I.
Code that has a good interface, and buggy code will still appeal more than one with poor interface and good code, just as we fondly remember good movies from older times, even if the quality of the acting and filming leaves a lot to be desired.
Programs are expected to do a lot more than appliances, and operate effectively in wildly variable conditions. When robustness is required, there are efforts made to reduce the variable conditions, and the range of expectations. Some programs run on dedicated boxes that do nothing but run that program.
User expectations and knowledge is a moving target. In part, this is the fault of the vendors, who change the interface quite often. Where in the world of DOS, enter adds data to a field, in Windows, it accepts and closes the dialog. Control-Alt-Delete is another bugbear.
Were the manufacturers of cars to lay out the controls to suit their own design, there would be pandamonium, when the left foot activates the break here, the accelerator there.
If we're going to have a common interface, we should get it designed and use it unfailingly.
Command lines are not imune. In fact the command session can be regarded as a computer inside a computer. One would be wholy upset if some program started to uninvitingly leak data into another program's space. Even command line options are becoming standard: how many of us look for help with a /? or -? option?
We need words to have singular meanings: for example, the word 'cancel' should back out of a dialog box. A dialog box that has a large amount of data entry should have some sort of 'save' option. Activating a button or control with F1 should bring up relevant help.
Software will continue to suck, as long as people have to change from one activity to another very often, and have to use different keystrokes for the same command.
It will continue to suck while it decides to do something different with your data than what you thought it was supposed to be doing. This is rather hard to get around. In essence, the program should communicate what it is going to do, and do what it said it was going to do, and *no more*. [Spyware does a few extra things :(]
You don't have to be one of the big guys to get a good product out: JPSoftware's replacement for cmd.exe and command.com is a much cherished product. JPSoftware is not a huge company, but it has a huge following of loyal customers who speak highly of its products.
Just getting the bugs out of the code is not enough. You have to work on the interface as well.
OS/2 - because choice is a terrible thing to waste.
Something that software is unique in is that the primary tool to build software is software. You don't use a 2001 car to build the 2002 model. You don't use the Empire State Building to build the World Trade Center. But you use Visual Studio to build JojoApp v3.5, and Microsoft uses Visual Studio 6.0 to build Visual Studio.NET.
So all of our software is very literally tied to it's past, because we very rarely start from scratch and build up from the ISA to an application that works. And lo and behold, when we do (like with cell phone OSes), we achieve pretty stable results that do what they do well, even when what they're doing *is* revolutionary.
- The Amazina Llama
The Capability Maturity Model (http://www.sei.cmu.edu/cmm/cmm.html) from the Carnegie Mellon Software Engineering Inst (http://www.sei.cmu.edu/sei-home.html) has been developed to aid this transition from a craft disipline (hacking) to an Software Engineering displine.
The Funny thing is that it wasn't the software, it was a stupid *American* at NASA that calculated the path in Feet instead of Meters which, if you didn't know, is the international space measurement.
And then again, why does software suck? It's made by humans!
Moderation: +4. Modded 70% Funny and 30% Overrated. 100% Saturated.
Looks like you have a problem understanding emotional comment.
Let's explain,
First take the subject,
Create a counter argument,(this can be counter to the subject, or counter to a releated subject).
Now make that argument extream.
Add in a bit of, over-the-top ness, just so people can see that you constructing an emotional comment.
The idea of an emotional comment is to prevoke though about the nature of the argument in the more intelegent, short sighted people can't look beond the extreamness which makes them easy to pick out.
Here's a translation of the post for you.
Most code that is produced is poor quality, why?
Well if you comapre it to another disiplin that has reciently had poor quality defective products (e.g. World trade centre that was build in a rushed and wasn't as structurly sound as it should have been!)
Now most buildings have crap design, but we all live in them and put up with it, (why is that window there, who put the power socket at that end of the room.... etc....)
Point out that another disiplin, many people regard as highly professional, that has rule to go by dosn't do a job, that much better than most software designers.
thank God the internet isn't a human right.
I worked out my hourly rate including that travel time the other day - it's just over six quid an hour. Thank god I'm not bitter! Of course, this kind of exploitation hardly motivates you to do your best to supply well thought out, robust code, which I guess is why I have maintain production systems written in Perl which don't `use strict' or -w warnings; not that they do anything important, mind you, just QA of anti-virus definitions which are automatically installed on tens of millions of machines every month...
You know, I'm very impressed that you're responding to peoples' critiques of your article. I wish more journalism worked this way -- write something, see how people react, then engage them in debate. I can understand your reasons for leaving out a detailed description of OSS, but it would still seem relevant enough to be worth mentioning. Wouldn't it? As for my other complaint, I was being hyperbolic to overstate my point. I guess it backfired. I'm not that pessimistic.
Here is a pointer to a good article about bad software from CIO magazine.
http://www.cio.com/archive/101501/wasting.html
-- Dan Ehrlich
In the company I work, first we tried with meetings to define requirements.
And the solutions were very specific software which fixed some trouble very well but were very hard to change, because they were not designed to change.
Not the requiments are done in a dinamic way. They must implement a working system with whatever they have, i.e. excel sheets, paper cards and so on. The results have been better. There is no better system description than a working system, even if it uses obsolete tech.
Then we can do the coding and automatize the system. I guess this is impossible to do in big companies... who can convince management of doing things manually ? (even if its for a limited time?)
We are Turing O-Machines. The Oracle is out there.
Disappointing article. I saw no mention of
D. Knuth, R. Stallman, B. Kernighan, and only
a passing reference to E. Dijkstra.
(* Compare this to a language that demands strict type definitions and static type checking, where the number of type errors that ship to your customer is zero. *)
Yes, but the complex and cluttering type management creates *other* problems. Like I said there is a tradeoff. Which side of the scale is heavier depends on the programmer and the language it appears.
(* but you have to sprinkle your code liberally with dynamic checks instead *)
Your coding style or lang must be *different* than mine, because I don't have a lot of this.
(* I feel like I come out hours ahead by using a strait-jacket language that busts me at compile time when I neglect to say what I mean and mean what I say. *)
But, you also cannot test as fast because compiling takes longer than interpreting usually.
(* What's "suspicious" if you don't tell the compiler/interpreter what to expect? *)
x = "foo"
y = x + 2
in a language where concatentation is some other character like "&" or ".".
Table-ized A.I.
IIRC, the USS Vincennes incident was more dependent upon human than computer error. That, and the fact that if you're in an enemy-controlled militarized zone, there are certain risks you take. Accidents can happen with code, but so can operator error. War casualties are a different matter. If I were on a warship, i'd rather take out a possible threat than risk it.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Being hand-crafted and written in C are related. Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and rarely upgraded.
Code of this sort should mostly be in the OS itself, although it's also in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and a poor choice for the rest.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Gawd, analogies are fun... Let's talk about bridge building.
This site at has some bridge history that I read recently. The Firth of Forth page in particular talks about a bridge that was built according to the maxim, "Everyone knows how a bridge should look." The result was an overbuilt, overcostly and ugly structure. A layman's intuition about what is necessary may be quite wrong.
The infamous Tacoma Narrows suspension bridge, of course, was built in modern times (1940) and according to conservative and well known principles, which didn't stop it from self-destructing. This was after more than fifty years of experience in designing large suspension spans. The judgement of an expert engineer with ample experience and time can also be very wrong!
Let's also consider the Charles River bridge, which looks like nothing you ever saw before. Nonetheless it is now being completed at a cost of $86M. To be sure, the design must have been reviewed, but if you saw a child's drawing of the bridge, you'd think it was a fantasy that could not be built. Again, so much for "Everyone knows how a bridge should look".
I agree with your basic point, which, as I understand it, is that the design must be visible and inspected to have a hope of correctness. But as bridge building shows us, that's not always enough!
Viewpoint: Beware the engineering metaphor
Communications of the ACM, Volume 45, Number 5 (2002)
Wei-Lung Wang
Communications of the ACM
Vol. 45, No. 5 (May 2002), Pages 27-29
metadata
Table of Contents
Lead-in
Introduction
Software Engineering Is Not Engineering
Limits of the Engineering Approach
Tangible Mathematics--The Essence of Software
Pitfalls of Engineering Software
Call to Action
Author
There are great similarities between the work of the software developer and the work of the mathematician.
As software developers, we often fail to learn from our mistakes. Many software projects appear needlessly painful because we didn't "leverage an existing code base," or "draw on proven techniques and best practices." While this is sometimes the result of a failure to instill discipline in the development process, it is also a reflection of the fundamentally malleable nature of our work. No matter how hard we try, it is often difficult to reuse past designs or to adhere to any fixed set of development rules. The result is software quality disproportionately dependent on the abilities of its developers rather than on the quality of instituted processes and building blocks. This reality has often prompted us to refine the engineering approach to building software with a focus on ensuring software quality.
While the engineering approach has its place, it is important we realize the work of building software is inherently not an engineering task. Engineering is the work of applying scientific and mathematical principles to practical ends. Software engineering, on the other hand, is the use of engineering practices to craft mathematical rigor. As software engineers, we do not engineer software, we merely adopt engineering practices when building software.
This distinction may appear subtle, but its implications are real. Unlike engineering, the essence of building software is its mathematical undertones and the role of information as its raw material. This difference is manifested in two ways: our inability to create a frame of reference--making it difficult to establish rules by which to carry out work; and our inability to reliably engineer structural quality.
Software Engineering Is Not Engineering
Fundamentally, engineering operates within the framework of the immutable laws of nature. These laws dictate the realm of engineering possibility, and engineers work by designing and constructing within the bounds of these laws. Their permanence and universality allow engineering principles, which signal the boundary of what is safely possible, to be established. For example, engineers who violate known electrical circuit design guidelines are potentially breaching the physical limits imposed by the forces of electricity. These guidelines can be established simply because their applicability is universal. Competent engineers observe well-known limits that cannot be breached, while negligent engineers who fail to observe these limits are potentially negligent.
Software engineering, on the other hand, has no fixed framework in which to operate. At its heart, software is the embodiment of a Turing program. Like the Turing machine that can compute all that is computable, software can be designed to process information in any way it needs to be processed. Because Turing instructions are put together in the context of a set of information requirements, they observe no "natural limits" other than those imposed by those requirements. Unlike the world of engineering, there are no immutable laws to violate. Likewise, software components, being collections of instructions, only function in the context of their information requirements. They can be assembled together only insofar as their information requirements are compatible. In other words, the natural limits of component interaction come solely from the information requirements unique to the project and component design. As software developers, we are in the unique position of not only having to design our systems, but are also called on to design the micro and macro information requirements, and by proxy, the framework of "natural limits" in which we operate.
Requirements, software design, and natural limits are tightly intertwined. This unique position is best illustrated by trying to answer these questions: How do we determine if professional negligence caused a software project to fail? Did the software engineers violate known guidelines? Or, was it simply a series of bad judgement calls?
This absence of a fixed framework of natural limits has two major implications. First, we have difficulty establishing across-the-board design guidelines and principles. The framework of natural limits differs for each project, meaning there are no hard and fast rules that apply across the board. The best we have are guidelines whose effectiveness depends on the developers' interpretation. It is the people and not the rules and processes that are paramount in the development process. The second implication is that we have difficulty building general reusable components. Each project has different information requirements, meaning that components must be developed specifically for it. Only in the most generic cases, such as mathematical operations and system functions where information requirements are standard, can components be reused. Everything else usually ends up being built from the ground up.
Limits of the Engineering Approach
These implications reflect the mathematical nature of software, and are symptomatic of the limits of the engineering approach. As a mechanism for information computation, a piece of bug-free software is essentially a mathematical function in some system of axioms. The information domain, range, and mapping requirements are simply the constraints this function must satisfy.
In this light, the work of building software is a mathematical exercise within two distinct phases: the determination of the set of information requirements (the parameters of the function); and the creation of a mathematically rigorous function that meets these requirements. The work of the software developer is very much the work of a mathematician. In the world of one-man programming, the programmer, like a mathematician, uses his or her creative insights to create mathematically sound programs. Team-based software engineering, on the other hand, is akin to putting many minds together to engineer a single mathematical construct. This is not an approach that has a record of success in the world of mathematics, yet we are by necessity building software in this manner.
To ensure some level of software rigor, we usually have a single chief architect oversee macro-level conceptual integrity. Unfortunately, the single-mind unity that allows for mathematical rigor is lost at the micro level, where software development is by necessity a team effort. It is rare for all team members' code to have the micro-level rigor needed to work together seamlessly. While this can theoretically be addressed by having the chief architect issue rigid black-box specifications to code to, the reality is software requirements change so often that such specifications would be unwieldy. The many changes that occur on a daily basis, both major and minor, means developers play a crucial role in crafting overall rigor. They need to understand the scope of their work as part of the bigger picture in order to build components that weave into the program's ever-changing information tapestry.
This collaborative engineering approach toward crafting mathematical rigor is perhaps unique to our industry. Because mathematical rigor is difficult to engineer as a team effort, we find it difficult to reliably engineer software quality. Software testing is simply the attempt to reconcile the imperfect results of the engineering approach with the mathematical rigor required for robust software.
Tangible Mathematics--The Essence of Software
If software engineering is an exercise in mathematics, then why does mathematics appear so unimportant to the practitioner? And why has the engineering approach worked as well as it has? The key reason is software is a tangible form of mathematics that lends itself to being engineered. At its core, a program is an abstract sequence of instructions that performs some computation. But when the program is realized on a computer, it becomes an information tool with its own use-feedback cycle. It changes from an ethereal entity to a tangible tool whose actions can be observed. Instead of mathematically proving the results of a program, we can simply run it on some set of inputs and observe its behavior. This tangibility is both software's strength and Achilles heel.
To our benefit, the tangible use-feedback cycle allows the nonmathematically inclined to build software. Software developers, unlike mathematicians, do not need to manipulate abstract concepts to construct functional code. They leverage the use-feedback cycle by running their code and correcting any bugs. The code is gradually brought up to the required specification over repeated compile-execute cycles. This allows us to adopt a build-and-test approach common in the engineering disciplines, and makes it possible for us to engineer complex software systems within practical resource limits.
Building software is a complex and exciting task and it is important we resist the tendency to view it in a single dimension.
Unfortunately, this tangibility is a double-edged sword. While it makes software construction accessible, it also provides a shortcut to the more difficult task of proving the mathematical rigor necessary for bug-free code. By allowing us to engineer software, it deceptively obscures the mathematical nature of software. While it is unlikely we can abandon the engineering approach in favor of mathematical formality, we should always keep in mind that mathematical rigor is the basis for sound software.
Pitfalls of Engineering Software
The bottom line is software engineering is not engineering, and the engineering approach to building software has its limits. This does not mean we should revert to the days of the hacker mentality "programmer-artist," for the scale and complexity of software today requires the disciplined engineering approach. But it is important our familiarity with the engineering metaphor be tempered with the knowledge that building software is inherently not engineering work. We need to avoid the temptation to overengineer the software development process. Rigid development processes and guidelines will strangle the fluid creativity needed to craft mathematical rigor. Likewise, time can be wasted on excessive efforts at componentization and building libraries of reusable code.
The engineering terminology we communicate to customers can also lead to unrealistic expectations. Terms like "components" and "foundation platforms" often create expectations that align themselves more with mechanical and electrical engineering work. This results in such refrains such as: "Since the foundation is already coded, why can't we just bolt on this extra feature?" and "This new workflow is only a variation of the old workflow. Why can't we just reuse the components you wrote earlier?"
Call to Action
As a profession, we need to evaluate the limits of the engineering metaphor and adjust our approach to building software accordingly. We would do well to communicate this to our stakeholders and customers, so our work is not misunderstood. Building software is a complex and exciting task that is a unique confluence of engineering, mathematics, and artistic insight, and it is important we resist the tendency to view it in a single dimension. Only then will we best be able to move our discipline forward.
Author
Wei-Lung Wang (weilung@alumni.nus.edu.sg) is a consultant at Adroit Innovations in Singapore.
©2002 ACM 0002-0782/02/0500 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.
Nice idea ... the problem is that (at least in the
US), we're in a tech recession, so there are much
fewer job openings than there were, the pay is
lower, and (most of all), the working conditions
are generally poorer, from a standpoint of really
being able to plan and provision for a quality
piece of code. So even great programmers get
stuck working in sweat shops where they wind up
spending most of their time fixing other people's
problems, instead of being able to take time out
to plan how products could be developed more
smoothly (and cheaply!).