Why is there so much buggy software? We're all getting so used to the continuing cycle of bad news about the consequences of poor-quality software that we take it for granted. But with the security stakes for flawed software rising, it's interesting to note what readers who are software development professionals have said in recent Gripe Line discussions about why software in general is so bad.
"I recently started to work for a company that produces specific software that is quite expensive -- 10K$ -- and I've been amazed to see how low is the quality of the code in there," wrote one reader." And I've investigated to see why is that and I saw that there are three main reasons: 1. Time-to-market is short forcing coders to write code that works, not code that works good. 2. Nobody reviews the code if it works. 3. There is a rule: don't change working code! Consequence: Is this working code? Barely!"
Another reader suggested that software quality problems are the result of "shaky requirements and the desire to use 'do anything at any time' GUI design adding a large number of complicating factors over command line text programs. Add to that, the fact that many projects are now beyond the scope of a single individual to comprehend - meaning that 'minor' changes in one are can't possibly be correlated to effects in some other area because no one person understands the relationships. An additional factor is that there a lot more people using software -- meaning that the odds of finding 'a better idiot' is a lot higher -- thus the odds of finding more and more obscure bugs."
Some software companies may even feel they have an incentive not to produce really good software. "Easier-to-use software requires less training and thus brings in fewer training dollars," wrote one reader. "So, a company that creates less buggy code that is easier to use spends more money on development and makes less money on training and maintenance contracts. Plus, customers will be less likely to upgrade if the software is stable -- if it ain't broke don't fix it -- and satisfies their fundamental needs. Combine this with the increased pressure to make a quick profit at all costs and it's easy for that attitude to take over the software development process."
It's not that good software development practices can't be found, but they are rare. "We develop PC applications, and we get called to help other software development companies develop new features for existing products," wrote another reader. "Almost all of the code that I see is very poorly structured. It is hard to read, runs on and on and on, the function names don't truly reflect what the function is doing, when it has comments they are out of sync with the code, and we even have the joy of seeing the same logic repeated in several places in the code. Why do managers and programmers put up with disgusting code like this? The code is never reviewed for quality. Never. The basics of good coding practices have been known since Ed Yourdon wrote about functional decomposition in the 70s. Give me a break! The cost and time benefits of refactoring have been known for a long time. Yet, we have managers who hustle the programmers on to the next item when the programmer just barely meets the spec -- and the code is often a mess after the programmer has had to figure out how to get done what he was supposed to get done. The messy code is left to rot. And rot it does. The more junk that piles up, the worse it gets. Why are we surprised by any of this?"
Read and post comments about this story here.
10:38:53 AM 
|
