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."
This is not an MSNBC written article. If you look closely, you will see Charles C. Mann of Technology Review credited. In fact, I have the article sitting on my desk. The article is on the front cover of the July/August 2002 issue.
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.
Patches like this come out because the company does QA after signing off on the master copy sent for duplication.
Its like this. You sit down a few months before release and determine what bugs MUST be fixed before you can go into duplication. Then you also determine what bugs you will fix in the first patch, which will be available within the first week or two of release. These are less critical fixes. Then you also determine what to work on after that.
Its a matter of priority - if they delay the release to fix all the bugs, users get unhappy, and eventually go to competing products.
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!
I have a Win2k box that's been up for about 60 days now. It's a home-brew PVR.
:P
I've watched an NT server box running IIS stay up for a good 90 days. The only reason it's not longer is that we had to shut it down to move it.
I think it really depends on how ya build it. The biggest instability is caused by hardware. If your hardware has fatal drivers, don't expect it to run for very long.
My main entertainment computer (also Win2k...) has an uptime of over a week. But I play the shit out of games like Quake. When I don't play those games, my uptime's seriously longer.
Everybody knows that Windows has a lot more games than Linux.
"Derp de derp."
When I say can't crash I mean that it is impossible for the processes memory to become corrupted. This actually improves security. If the security problem is purely logical, it wouldn't crash anyway, so your argument does not hold. Now if you mean that a problem should exit when it detects an error condition, fine. But that is not the same as a program "crashing".
.
In any event, this for example means that any code written in type safe language will never be susceptable to buffer overflow attacks.
I didn't name a specific langauge because there are many languages that have these properties. C, C++ , C#, Perl, etc. are not among them. Some languages that do have these properties are SML, OCaml, Ada, Modula, Haskell, and Mercury to name a few
Most of the C130J Mission Computer Software (which is cited in the article) is written in SPARK - a
highly secure, annotated subset of Ada.
- Rod Chapman, PxCS
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.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.
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.
A good link to the benefits of using Ada and SPARK on the C-130J and other projects is at Crosstalk, the Journal of Defence Software Engineering.
This is the umpteenth time I've quoted this link, or one like it. Maybe one day people will read the goddam literature and not keep on making the same mistakes in the same old way. The Facts - not religious opinions, unsubstantiated assertions or even unverifiable anecdotes - are out there.
Sorry, got carried away there. We need more light, less heat. But people - not some ubergeeks with Supernatural powers, just your standard geeks - have been making software that works first time, every time for years now. Every time you fly on a modern airliner, you bet your life on it. And it's a good bet. We know how to do it. We've proved it, repeatedly. It's just that no-one seems to listen when we tell them that they can do it too, just by doing things in a different way. One that (at least in manufacture) costs less too. Testing's another matter.
Zoe Brain - Rocket Scientist
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.