Slashdot Mirror
Why (Most) Software is so Bad
Rivard was one of several to point out that
MSNBC
says software sucks.
My opinion is that in software fields where the monetary gap between market-leader and second-place is large, we should expect bad software. Good design, good execution, good debugging all take time, but users can't see under the hood -- and wherever information is scarce or not readily traded among consumers, the free market bogs down. (Note what the article says about McAfee VirusScan.) So companies that don't plan on releasing a crummy 1.0 and fixing it later go under. That's just the way some markets work; if you're a coder or engineer who doesn't like that, find yourself a job in a niche without that monetary gap. Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has
sued.
Update: 06/18 14:10 GMT by J : Readers point out the story is a reprint
from Technology Review
(one of the few good magazines I get -- but this issue hasn't arrived yet :).
Rivard continued his writeup with an interesting point of view, saying that while we all know software sucks, we just accept it:
"Even though 'plenty of reviewers, pundits, hackers and other outsiders' will point out problems, often intentionally left in the product, no one has brought a liability suit against the makers of the known-to-be-vitiated product -- because the software gestapo (the End User License Agreement) has been 'able to avoid product liability litigation partly because software licenses force customers into arbitration' of poorly designed pith."There is a light at the end of the tunnel, believe it or not, and it's Bill Gates. Microsoft suspended coding for two months to seminar on bugs and how to fix them. Gates told his employees he wanted to make 'reliable and secure' software Microsoft's 'highest priority.' If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."
MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued
Alright, let's sue 'em then...
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.
No, if you ever hit the Windows Update page, you see they fix a lot of stuff. Now, the fact that they HAVe to fix stuff is the problem. I develop software for a living, and we beat the living hell out of it before it goes to production. We have all kinds of tests, regression scripts... I realize we're not doing OS, but the principle's the same. Test it before you toss it out the door.
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.
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)
"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.
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.
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.
How does one test against every possible configuration of every possible computer that could conceivably run one's OS?
Microsoft keeps finding bugs - that is true. Some of them are extraordinarily serious - that is also true. But it is impossible to find every bug the first time, or even the hundredth time out.
Remember, they are up against people who are actively searching for exploits. This is not your average user we're talking about finding a hole in the system.
On the whole, Microsoft does a somewhat overpriced, but erratically decent job of doing the tasks I use it for.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
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."
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.
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
Actually, Ada does a good job on enforcing good code, but many people ridicule it. It is those features of the language that support good coding pracitces (strong typing, etc.) that are the source of most of people's "issues" with the language. As the saying goes: "You can write FORTRAN in any language." It just takes more effort in some languages than others.
The dogcow says "Moof!"
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.
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.
In other engineering disciplines, there is little room for error and your mistakes are readily apparent -- you screw up, and you'll probably wreck a few million dollars worth of equipment during testing or kill someone when the product ships. Software engineering, on the other hand, allows the mediocre on the team to hide behind truly talented individuals.
Code doesn't work? No big deal, just fiddle around and recompile. Still doesn't work? The other guy will probably fix it. Product's shipping and the problem still isn't fixed? Eh, who cares? It's not going to kill anyone, and nobody will notice.
It is precisely because no one can "see" the shoddy workmanship of programs that such behavior exists (and I'm not saying open source programs are immune to this -- patching a crappy open source program is akin to patching up a crappy car engine with duct tape and staples). All those slackers who couldn't code a binary tree to save their life and were generally mediocre college students are writing the software you'll be using. Their mediocrity is hidden by the anonymity and zero-accountability inherent in large software projects. Essentially, they're doing the same thing in the real world as they did in college -- slack off and hope nobody notices.
This, folks, is why colleges need to implement tougher CS curriculums. This is why you need to be able to write code on paper. This is why colleges insist that you don't collaborate on projects in lower-level CS classes. This is why there shouldn't be curves that allow mediocre students to graduate with a CS degree when they should have been weeded out during their freshmen or sophomore year.
I'm almost finished with my CS degree, and it's depressing, even at this level, how few students there are who really have an understanding of and interest in computer science. Most of the students enrolled in CS at my school have never coded before college. The most popular reason for choosing CS? "I used to make webpages, and I figured it would be easy." No joke. Of course, this sort of behavior isn't strictly limited to CS -- I've met more than a few EE students (freshmen, admittedly) who couldn't identify basic electrical components, didn't know Ohm's Law, and chose EE because "I used to take apart telephones and put them back together, so I think electronics is fun." Inevitably though, these clueless students who enroll in other engineering disciplines tend to migrate over to CS since it's not as "balls-to-the-wall" difficult as say, EE or ME.
In short, software "sucks" because our colleges are allowing mediocre students to slip through the cracks into the professional world. Personally, I feel that the CS curriculums should tighten up a bit and put more emphasis on solo projects (and moderately challenging ones, at that) and writing code on paper at the lower levels. A message has to be sent to those students who want to be engineers but don't really have what it takes that CS is NOT an "easy major". Perhaps then it might not be the haven for slackers that it has become.
Well, that IS how they teach people to do it in college...
Any school that does that should lose their accredidation. Reality is that no school does that nor would any teacher advocate that. The key idea is teaching the student the difference between a compiler error (ie, missing semicolons) vs. a run-time error (adding 1 instead of subtracting 1).
I'm in college now (will be a Senior in September), the freshman are taught C++, and one of the first few lab sessions involves being given some short code (written by the prof) that compiles correctly, yet contains a logic bug of some sort. Likewise, the textbook contains a discussion along similar lines, including that famous quote from MIT that says something to the effect of "We were amazed by how often we had to go back and fix errors in code that we wrote"
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
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.
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..
Perhaps, because with linux you have a system designed by people not concerned with cost-effectiveness?
No, I'm not trolling. There is a considerable difference between people who write code because they enjoy it, and people who code because they are attempting to market a profitable product. (Abusive monopoly-ness notwithstanding.)
It takes an infinite amount of time (i.e. money) to make a product perfect. Therefore, any for-profit business must operate in a mode that allows them to release a product that is good enough to sell, but not so good it is perpetually in development.
As an old boss of mine used to say, "The enemy of the good is the better."
How is it possible that I have PC servers with better uptime statistics than production AS/400 boxes? How is it possible that RedHat raises a Signal 11 when I try to install it on the same workstation that has never blue-screened XP? Anecdotes are useless.
meh.
But the industry has dooped people so well that they believe there is really nothing wrong when software fails. They believe that it is just the way it is, that they should hit the reset button and get on with life.
Product testing costs money. The customer will buy it even if it is defective because 1. They don't know they have a choice, and 2. They don't really care that there's a problem. If a customer will buy it anyway why spend more money on testing? It reduces the bottom line and you can always fix the problems people actually complain about later.
Many companies today care little about integrity or the satisfaction of their customers as long as it doesn't have an effect on profits. In the software industry the cost of producing a product with fewer defects is greater than that of having a possibly unhappy customer.
To Do: 1. Take over world 2. Pick up Milk and Bread on the way home
Look,
All he's saying is that changing languages ain't going to fix the problem.
Ya wanna know why?
Because the problem isn't one of compilers, or ironically of technology.
Its an attitude and approach problem. Its the lack of peer review of architecture and design that is the problem.
Let me put it in a form that even you could understand:
Take the smartest, best programmer in a room. Let me come up with a solution to a non-trivial set of requirements using whatever language you think "helps".
I guaran-g*ddamn-tee it that the program will suck. It may suck obviously, it may suck subtley, but it will suck.
That's because one person isn't smart enough. Albert Einstein didn't figure it all out. Its through peer review of design and architecture that you get results.
And the magic number is 3. Three smart architects or designers will change the world. One smart guy will just hurt himself and do something that has a high suck quotient.
In the case of IIS exploits, for instance, it has nothing to do with it whatsoever.
free the mallocs!
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.
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...
How about Outlook's great features of executing unkonwn code on its own? How about the great security built into the entire Windows "operating system"?
Hm..
And why did not Red Code attack, say Macintosh or *nix-users? Dunno. It can't have anything to do with software design, could it?
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.
How is it possible that the stability of the Linux kernel is related to this discussion whatsoever? That amount of uptime is not impossible with Win2000/XP..
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...
How does one test against every possible configuration of every possible computer that could conceivably run one's OS?
You design around it. 3rd party drivers are a constraint for MS. Drivers do not have to run in ring-0. Microsoft chose for drivers to run in ring-0 and we pay for it with crashes.
Joe
Joe Batt Solid Design
We were taught a ton of quality control, testing, and design in school. In fact, design and testing were taught at the major portion of software development. We spent most of our time designing and testing our code than we did writing it. We also did studies on the effects of poor programming and the responsibilities a programmer has in relation to his/her code. I can't speak for every CS program, but I know that these were the core aspects of mine.
You are right though, once I got a job in the real world I found that these virtues were lost in most companies, and the importiance of the training we received in CS classes were dismissed as academic jargon and a waste of time. I saw a lot of people developing software without even an engineering degree of any kind! And the notion that as long as your code isn't in a position to harm a person's life, so what if it has bugs, is rampent...
So I think the problem is not in the teaching, but that a lot (surely not all) of the employers dismiss the talents that their employees learned in school simply because they think the "real world" works differently and that their experience is more importiant that formal teaching.
But I thought they were asking us where we wanted to go today.
Nope, no sig
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
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.
> To me, these comments seem utterly out of touch
> with reality.
Well, no. OSS vs. closed source is an implementation choice/philosophical decision. It's not a design difference.
And that's what the original author is talking about: a fundamental change in the design process. We're kidding ourselves if we think the hacking and slashing that we call "the design process" at many companies is any kind of engineering process. Software quality will not increase until that's addressed.
> For example, Microsoft's Internet Explorer has
> 18 unpatched security bugs
Yeah, and I when I run Mozilla on Linux after I open three tabs I can't time in the damn URL field...and I can't close tabs...and I always go back to IE.
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
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
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.
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
Claiming that its stability problems come solely from the "multitude of hardware configurations" is baltently false. In my anecdotal experience, however, properly configured, properly administered WinNT/Win2k/WinXP (WinPlayStation is just DOS with a pretty menu and a 32 bit API) machines - servers and workstations alike - enjoy the same uptime and stability as any other platform we run at this company. Likewise, complaining because one OS is more stable than another on a particular hardware configuration is a little silly if you haven't bothered to reference the Hardware Compatability List to see if you're even supported.
meh.