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."
Micro$ofts problem is that they forget the "and fix it later" part.
Never underestimate the power of human stupidity.
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.
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 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.
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.
...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
Hmmm.. Ain't MSNBC owned by Microsoft? Talk about the left hand not knowing what the right is doing...
(Anyhow, I'm sure Windows has cost consumers a lot more than $8.75 million...)
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
Insightful, huh?
How about some basic economics:
Value = Benefit - Cost.
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.
In any product liability lawsuit that does not result in human death or injury, one would have to account for all aspects of the economic equation.
If humans are mostly water, and beer is mostly water, then humans must be mostly beer.
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.
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.
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.
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.
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.
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.
Your analogy doesn't work for two reasons.
... or books for that matter, infringe upon copywrite. They care if the book is good or if the software is installed on their computer already so they don't have to think to install it. I suppose if some default software (such as word) ever got bad enough that users might switch but for now it does mostly what it claims to do without too much headache so it gets used.
1. You don't open a book and immediatly see what went into creating it (the first draft, the printing, the distrubution etc.) You see the finished products, where as with software when you see the code you see the unfinished things as well and at least some of the steps it takes to go from that code to word processor on the screen.
2. Users don't care whether software
I understand the closed-source camp's desire to keep the hood closed, they feel its easier to duplicate the process or use their own knowledge against them. The problem of closed source will go away when we stop seeing "intellectual property" as property to be bought and sold when it should just be shared.
The Anti-Blog
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.
....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)
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.
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>)
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
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
"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 ? :-)
<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?
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
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!
Maybe the two issues should be more closely coupled. Historically, patents and copyrights granted the inventors and authors monopoly over some of their works in exchange for disclosing the works to the public. The public can then use the works and learn from them (possibly for a fee).
Providing copyright protection on binary-only software does not fit into this original model. The public can use the work, but there is very little that can be learned from it. The copyright in this case does not serve to advance knowledge, which negates one of the main reasons copyright was created in the first place.
Perhaps copyright protection should be reduced or eliminated on binary-only software.
Remember, copyright concerns publication of works; it is not supposed to be a vehicle that helps you keep your trade secrets secret. Keeping trade secrets would be more appropriately done by negotiating (and actually signing with ink) contracts with your customers before giving them possession of your secret binaries.
The problem is that American culture raises people to worship the false idols .. the successful capitalists, which, according to some, made good products, but more often 'played the game right' (not even a reference to the quality of product their company created!) or 'exploited consumers'.
.. not that they were ever top notch to begin with, but they've been able to afford to pull wool over peoples' eyes for years, and since they are #1, people are all too happy to assume that its for a good cause.
But just watch. American culture encourages worshipping the successful, and assuming all those in have-not situations (or 2nd best, for that matter) suck! There's not much that can be done about this - America itself must do many questionable things to remain #1, and so it would be contradictive for its people and voters to believe anything but #1 was the best way. Thats why MS could go around lighting people on fire, and they'd still be held up as 'the best way to do things' and 'the most likely saviour' when it comes time for us to eat our deserts. They have the most money, and for reasons of safety and security, people will side with them and assume that the downsides of their software are either unavoidable or, even more laughably, that their upsides outweigh their downsides.
I don't see this changing anytime soon, unfortunately. Apple is subject to a huge stigma for being 'elitist', Joe America's most hated trait, and Linux is still too complicated for the Average User.
The best part is there might be a fictional 4th, 5th, 6th option that may have existed had people not been so quick to defend MS's full and zealotous use of the advantages capitalism gives to those who've already achieved power and leverage. Success seems to breed laziness, and MS is a good example of that
"Old man yells at systemd"
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...
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
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."
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.
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...
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 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."
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
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!
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
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!
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
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.
#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!
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.
"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.
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
Here they are.
5. ?
6. Profit
Nope, no sig
Comment removed based on user account deletion
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
The disheartening trend for CS to be an "easy major" is not common at all universities.
It depends on whether you are comparing CS to the handful of traditionally tough majors (engineering, pre-med, pre-law), or to all the relatively easy majors (from English to Education). My first year in the EE program at Oklahoma State, I was doing 60-80 hours of homework a week. The classes shrank by two-thirds in that year. That was by plan - you get some important basics in that first year, but the main thing is to ensure that you are never going to neglect checking all the details just because it's getting late, before they teach you the real stuff...
If there's a CS program anywhere that does things like that, I'd like to know about it. And hire their graduates. The CS classes I've taken (a couple of decades ago) were downright relaxing compared to anything in the engineering school.
------ 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.
Well, MSNBC is a news source. They're supposed to be kind of objective.
Sure... But I am always surprised at how much positive press Linux gets from MSNBC (more than CNN, for example), so I wonder how much they are trying to compensate so they can appear objective.
LedgerSMB: Open source Accounting/ERP
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.
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.
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.
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.
Indeed, it should be the market that decides, and not the courts : The market is the reason that North American automakers were forced to dramatically improve their quality (because the Japanese automakers were far ahead of them, and the market started voting for quality with their pocketbooks), and the markets are the reason why people pay a huge premium for IBM laptops. These capitalistic forces are amazingly powerful in getting what people really want, and the only time they fail to work is when someone with a pet issue tries to circumvent market-forces to get their own personal beliefs imposed on everyone through the legal system. It isn't surprizing to see the "sue em!" claims from many of those who already have forsook Microsoft software: These are the type of authoritarian people who believe that because it's not right for them, therefore it shouldn't be right for anyone else.
The irony is that most people, the average Joe and Jane out there, have shown that quality of software is very low on their list of purchasing criteria (which is how software like "ICQ" has never been non-beta...why bother ever calling it production code when millions of people will download it anyways). Given the choice, the market has stated time and time again that features will always trump quality, and that time to market often beats quality.
Sidenote: My own philosophy is that I spend about 90% of QA time code auditing and refactoring, and about 10% of the time doing runtime testing. I find that this is exactly the opposite of many organizations which push runtime testing as the method of evaluating code. To me runtime testing is no different than doing a compiler syntax check: It's an incredibly weak, time intensive, limited case way to assure the quality of your code, and should at most be used to evaluate tha the compiler and dependant third party code is of a good quality.
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)
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?
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.
That's why my department hires EE as our coders.
In theory, companies could have switched anytime to another product, in which case the "Value = Benefit - Cost" equation applies, but due to the market lockdowns MS has in place, it was realistically a case of use Windows or you can't use computers, which will make you uncompetitive.
I'm no lawyer, but I'd have thought that companies would have been quite within their rights to claim that Microsofts monopoly has indirectly cost them billions through lost time while Windows reboots, loses work and so on.
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.
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"
Segfaults? Sounds to me like you were trying to destroy objects that didn't exist. That's not the compiler's fault, that's yours. How can a compiler expect that your destroy command might destroy something that doesn't exist? C is a loose language. It's designed to give maximum power through minimal limitations. As a result you can have lots of programs. If you're writing something small, use PHP, VB, Perl, Python, whatever, but C/C++ is probably overkill. Something large? Perl, Python, VG, they may not be powerful enough to do what you need. It's a case of finding which tool is better for the job.
But I understand what you're saying. Right now I'm working mostly in Delphi and I've come across lots of bugs in the libraries and there's nothing you can do except bite the bullet.
It's a compound thing. Bugs in OS, bugs in drivers, bugs in compiler, bugs in the development environment, and then bugs from the app programmer.
I think this is a result of capitalism. Don't get me wrong, I like capitalism, but it doesn't work on the best product surviving, it works on which comes out first and has the best marketing. As a result products are pushed to be released before they're ready instead of when they're complete.
Plus, PCs are too general purpose. If you have one tool for a specific job you have less problems. Look at Unix, generally the tools are small and specific. If it has a bug or doesn't work, your replace it, or it gets fixed and it usually doesn't affect anything else. Once everything is interdependant and complex it's more prone to bugs, and bugs become amplified by compounding them (drivers, os, etc).
I don't think there's an easy solution for this one...
--- I used to moderate, then I read the -1 articles and decided having to filter through them was not worth it.
Well, yes and no. I've been using MS products for years and sometimes what they lose in stability they make up for in ease of use. I've had hours of fun trying to do simple tasks in Unix (Solaris 2.6) and wondered why finding such simple settings as where an IP address is set has to be so tough, when in NT all I have to do is right click on "My Computer" and find the network settings there.
.exe file, click on a few "Ok"'s and reboot and all is well with the world.
I've also just started using Linux and am baffled as to why things like updating video drivers has to be such a pain, when with Win98 all I do is double click on an
MS have made computers easy to use for the average Joe. Unix and Linux haven't. All that lovely stability means nothing when an average user can't carry out a simple task.
Sure, I agree that the stability and security of MS products suck. The stability issue could have been fixed in XP, but wasn't (far too much XP rests on top of all those old bugs in NT). The security problems could be fixed with better coding, but we all know that there are also plenty of bug in other OS's, and protocols (SMTP anyone?).
Don't get me wrong, I love Unix for the control and stability I get from it (and where I work, all the serious back-end stuff runs Unix), but for users who need decent apps with consistent front ends, it's got to be MS. And I say that with sadness in my voice, because this stuff could be done so much better, but isn't.
As an aside, let's also not forget that many problems we see on MS OS's is partly due to dodgy programming of third party apps. Of course, these problems shouldn't result in a BSOD, but blame where blame's due...
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.
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.
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.
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.
(* 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
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.
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
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.
You're basically saying that because the software sold to the US Navy couldn't handle properly a trivial exception (division by zero) generated after data input by an operator, a US Navy warship was a sitting duck for 3 hours, and that this could have cost the lives of hundred of your peers if the vessel had been at war at the time.
Who's the moron now .....
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.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.
No matter how much damn review, extreme programming, or any other crap software engineering types come up with, once you need more than X lines of C/C++ to solve your problem, you are fucked. You will NOT catch every last memory leak, buffer overflow, type error, no matter how many fallible human beings you add to your project, no matter how much certification they all wasted their time getting.
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.
(* 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.
(* Every project I've been on had these unreasonable deadlines. Don't managers get it? Rushing around only produces crap. *)
Perhaps somebody already repeated it around here somewhere, but:
"If you want it badly, that is exactly what you will get."
Table-ized A.I.
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
> 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.
I would agree with your middle sentence, though I would generalize it to "humans are the weakest link in software production".
So all I'm suggesting with the language bit is to use languages that make the computer do some low-level tedious checking that computers are so good at and humans are so prone to errors at, especially when done in large quantities.
And as far as I'm concerned, poor language choice is just an instance of your "attitude and approach problem". There are good reasons to use one language over another, but those are hardly ever the reasons you hear people use to justify their choices.
In other branches of this thread the discussion has focused on static type checking. I wish programmers would learn that rigorous type definitions aren't an unrewarding chore but rather an opportunity. Think of them as constraints embedded in your code. Sure, I'd rather have a general constraint that told the compiler "no bugs, please", but since that appears to be impossible I'm happy to have whatever lesser constraints that are possible.
In my experience the time spent in type definitions pays off many-fold over the long haul, and better yet they mean I can spend more time thinking about what my program is doing rather than getting bogged down in the details of how it does it. I offload the most tedious details by doing the declarations up front, and then concentrate almost exclusively on the abstract logic of the program. And my bugs are almost always errors in my algorithmic logic; I don't waste a minute tracking down the truly stupid stuff.
> 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".
Heh. I see you freudianly substituted "me" for "him". Let's leave it as an empirical question whether you would be the smartest, best programmer in the room.
> 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.
This conforms to our ideals -- most particularly to our anti-elitist democratic ideals -- but is it true in practice? If we were talking about highly qualified rocket scientists designing a rocket I would agree that your claim was (usually) right.
But in the realities of the IT industry, I would guess that for a team of five or more developers the best one is probably an order of magnitude better than the group average, and for larger groups that might extend to 2-3 orders of magnitude. (The SEI only finds about a single order of magnitude between the best and the worst that they test, but remember that they are testing people in SE classes approximately equivalent to graduate level study, hardly a random selection of IT employees. I've worked on projects with people who couldn't be relied on for such trivia as changing the backup tape every day or logging out of their terminal when they went home, and yet they were expected to participate as peers in the development of complex software.)
At any rate, I seriously doubt that your claim holds in practice in the IT industry. It's a fortunate project that has a team where all, or even half, of the members can contribute to the design instead of distracting the more qualified individuals with idiotic suggestions and writing crap code that ultimately has to be debugged by the gurus because the people who wrote it don't even understand it.
Also, your claim is a really odd response to my post. I don't think anyone, anywhere, has ever suggested that compilers should (or even could) replace the human creativity that goes into a program. What some of us are suggesting instead is that the compiler should have to do all the 5417-shoveling, freeing humans up to focus on the creative aspects almost exclusively. (Would you rather use a 417-shoveling language, or shovel it yourself?)
Sheesh, evil *and* a jerk. -- Jade
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.
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
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
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.
uhh. . . are you sure that all of those words that make up the acronym go back into history as far as the word fuck does?
I am pretty sure the word fuck predates Middle English, which makes it older than a lot of now common words such as "fun" and "shower." (Fun just didn't exist until Shakespeare created it, shower derives from the Middle English word "shore.")
I disagree entirely. Ralph Nader's book brought about a revolution in the public's eyes, and any legislation was politicians trying to choose the colour to paint the shed : They followed the trend rather than led it. ABS, electronic stability control, side impact beams, traction control systems, side airbags, have nothing to do with legislation, and everything to do with consumer's saying "yeah, safety matters". Volvo exists primarily based upon their safety standard. The law almost always lags rather than leads.
The "little incentive to offer new features" is ridiculous. There are dozens of extremely large auto companies, all dying to eat into each other's business.
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!
(* 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.
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.
Which in my estimation means that the marketing guys aren't doing their jobs.
I'd say that they are doing their job. The people who aren't are the product managers. At one company I was at, there was a product management department between marketing and development. The product manager's role was to take marketing's wants and development's input on the cost of those wants and figure out a plan to get a product. It worked really well at that company while I was there (don't really know now. It's been 5 years), but if the product managers don't have executive backing, then it could turn into the marketing controlled scenario you describe.
-no broken link
It isn't surprizing to see the "sue em!" claims from many of those who already have forsook Microsoft software: These are the type of authoritarian people who believe that because it's not right for them, therefore it shouldn't be right for anyone else.
That is only partially true. The problem is externalities. For example, Joe admin and his friends decide that security is not a high priority for them. Now, when code red and the many DDOS slave programs end up running on thgeir box, Jane admin who chose quality is still bombarded with Code red attempts, or DOSed off the net.
In other words, as long as it's not on the public net where it can become my problem, I don't care what other people want to run. However, If I am going to have to deal with the consequences (DDOS, gobs of code red attempts, dozens of emails from various outlook viruses flooding mailing lists, etc), I expect some minimum standard to be met.
Think of it like FCC regulations. Radio emissions aren't regulated for the sake of the device's owner, but for everyone who lives near the owner who didn't get any input into the choice of brands.
I did get extra for working over 40h/wk, although mostly it meant getting days off later - only when it did get out of hand did I request money instead. However, that must have been profitable to my employer, as over 80% of my hours could be billed from the customers. And no, travel between home and office isn't included in working hours, which isn't a problem for me, as I live just some 40 minutes from the office.
Now I'm working with 'compensation for overtime included in salary' contract, though, and don't have problems with the issue. The compensation is decent, and I'm not expected to work myself to death.
(* 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.
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."