Evil Software Development

Thursday, July 29, 2010

Dr. Steve Belovich

800ca77bf7ad76b2a830356569e524b7
The "PC hardware revolution" in the 1980s made CPUs, RAM, disks and monitors very cheap.  While that was happening, software was undergoing a revolution as well. The demand for applications grew far faster than the ability of the market to deliver them.

This high demand put unbelievable time pressure on software suppliers and systems integrators to get the job done on schedule – regardless of the number of bugs. Time-to-market was (and remains) more important than getting it right.

Software, which was formerly done by engineers who really knew and understood what the hardware could do, was now done by programmers who had little understanding of what the compiler, linker, run-time system and underlying hardware actually did with the source code that they wrote.

During the past 20 years with more capable, heavily pipelined CPUs and the widespread use of scripting languages, this dichotomy has gotten far worse.

There are no universal software quality, reliability and safety standards. This is in sharp contrast to consumer products where safety standards and testing laboratories are in abundance. Software development and purchasing remains very much “caveat emptor”.

Complicating this issue is the fact that the science of software is in its infancy. We still do not know how to produce large pieces of software that are consistently bug-free. Software is largely handcrafted and trial-and-error is the rule (what are Beta sites for?).

The plethora of platforms and development tools prohibit universal standardization. And with good reason - whatever platform and operating system are chosen today as “the standards” will certainly be obsolete within a few years.

Many organizations have made the mistake of early and excessive standardization and a large number still keep making it. There is much yet to invent in the computer hardware and software world. Insistence on one system as the standard at this point would be quite premature.

What does this mean? Well, a lot of bad software got into the market and stayed there because there were no economic consequences for producing a poor product. People bought it anyway.

Users were (and still are) largely clueless about software quality. They have little idea of what to look for, what questions to ask and how to separate fact from fiction. The best marketed programs and software systems get the most air time and become de facto “standards” even though there is little unbiased, trustworthy evidence on which to make an informed buying decision.

Another problem that occurred was “disposable code”. Under-estimates of system longevity led to a “just get it working & ship it” approach to software development. Why plan more than a few years ahead when there’s no budget to do that?

Project managers get paid and promoted based upon short-term metrics. None of them get much credit for designing systems that work too far into the future. In fact, there are financial incentives not to do that. An “upgrade” or ”fix” can always be sold at a later date – long after the customer has securely chained themselves to the current software version and cannot easily change horses.

Buying software places obligations and constraints on future buying decisions. Many companies, having standardized on a certain IT system merely because the site license was cheap, found that the cost to convert all their data to a new IT system far exceeded the original purchase price of the old IT system.

Choosing software merely on the basis of acquisition cost and ignoring future operational dependency and flexibility is arguably one of the biggest mistakes that can be made.
Possibly Related Articles:
4285
Vulnerabilities
Software Vulnerabilities
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.