Posted on 08/23/2003 1:21:51 PM PDT by yhwhsman
Parasoft CEO Blames SoBig On Arrogant Software Industry Leadership
August 22, 2003 (3:29 p.m. EST)
By Keith Ferrell , TechWeb News
Sharply criticizing complacency, arrogance and immaturity in software industry leadership, and blaming those qualities for the SoBig virus's successful march through the world's computers, Parasoft CEO Adam Kolawa delivered a rant Friday that included an offer to show the industry how to cure its errors.
The head of the privately held software development solutions company said that the industry's policy of tackling program bugs at the latter stages of development cycles is self-defeating. By that point in the development process, Kolawa said, the bugs have been replicated too many times and become too widespread, making it too difficult to detect all flaws, and leading developers to ship vulnerable products.
Those vulnerabilities, in turn, attract hackers' worms and viruses, costing business and consumers tens of billions of dollars in lost production time each year.
What most needs to be fixed, he said, is the industry's approach to testing and error correction during the development cycle. Kolawa said the software sector should apply industrial and production-line methodologies to writing code.
"I have the solution -- which will even help Microsoft," Kolawa said unabashedly.
That solution includes incorporation of Automatic Error Prevention (AEP) methodology for improving software quality and reducing time-to-market, the Monrovia, Calif.-based company said.
According to Kolawa, AEP methodology, drawn from the insights of industrial analyst W. Edwards Demming in the mid-1900s is just as applicable to software code as to any assembly line product.
"At the end of a television set production line," he said by way of example, "the TV is tested. If there's a problem, it's the flaw in the production line that's repaired, not each individual TV set."
From Kolawa's perspective, the software industry pursues exactly the opposite course, sending out hundreds of thousands or millions of flawed copies, then finding and fixing one bug at a time before dispatching repairs to be applied individually.
The problem as he sees it stems from the software industry's mis-perception of itself as different from traditional industries, and in some ways better -- a mistake even traditional industries have made, to their detriment.
Kolawa believes that the software industry needs to take a page -- or more -- from mature industries such as automotive and appliance manufacturing or risk losing its preeminence to offshore developers.
"The software industry suffers the same sort of arrogance at the top level that nearly killed the U.S. car industry in the Seventies," he said. "The 'nobody can do this better than we can' mentality that led to the surge in Japanese car sales."
The situation is not likely to change, he said, until software makers begin instituting rigorous and ongoing testing throughout the code-writing cycle, and at the same time impose stricter management controls over the developer community, forcing them to implement and adhere to constant testing procedures throughout the process.
"But the software industry's so damned arrogant, they won't do it," he said. "But if they don't we're going to lose more and more development jobs to companies in India and China, whose developers don't have that arrogance and whose code may be of higher quality. If we're not careful, this will be worse than the rust belt."
Yhwhsman
Yhwhsman
The process of writing software is not a manufacturing process; it's a design process, and often the design of something very complex that should meet unexpressibly complex and ever changing, frequently conflicting, demands.
For those of us who delight in new design challenges, this has been a source of much fun, and a fair bit of money, the last few decades.
There is a manufacturing element of software production, but it is trivial, and provides no feedback on the quality of the software. It's making copies of CD's.
Normal manufactured physical objects, like toasters, TVs, and cars, require quite a bit of custom manufacturing setup, which will help weed out bad designs. And items that have typically high quality, such as cars, have gone through years, decades, even a century of design refinement, gradually improving the quality.
In software, I can and have sent stuff directly from my initial design and coding, done in a single night, with no feedback other than perhaps a compiler telling me my coding was syntactically correct, directly to the end user.
Software suffers from a curse and a blessing. The blessing is that it is vastly more flexible, maleable, capable of complex logic than anything formed of steel, wood or plastic. The curse is ... same thing.
Even if someone got a piece of software "perfect" or nearly so, it wouldn't take a minute for someone to want it to do more, or behave differently, or adapt to other circumstances.
Just as politicians fall prey to the fallacy of "but we have to do something about ...", so do purveyors of software quality improvement tools and products rely on software producers and consumers falling prey to the "but we have to do something to improve software quality.
As with other more complex human disciplines, the best measure of success is not the tool nor the process, but rather the competence and integrity of the producer.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.