The Software complexity crisis and why successful Open Source software systems are less affected by it.
Summary:
Why modern software has so many bugs and why successful Open Source Software has a higher level of quality.
Chapter 1
When a software package reaches a certain level of complexity, it becomes unprofitable and even dangerous to make further changes, (even to fix defects in the package). This is the Software Crisis.
Critical Issue: the Software Crisis means huge amounts of money will be lost. Of the $250 Billion spent annually on IT projects approximately 31%, ($77.5 Billion), will be squandered on projects which will fail and be canceled. Going beyond IT spending to software product liability costs, financial, medical and other software have already accounted for large settlements being reached for various financial as well as physical injuries including at least one actual fatality. Clearly not a trivial issue.
The Software Complexity Crisis
Despite the best intentions of the architects, programmers and managers, many software products produced today consume grotesquely large amounts of disk and memory. As the software grows larger, the number of defects also increases. But the number of defects rises faster than the increase in the size of the software. Each object (variable, function or operation) in the source code of the software has the potential to interact, (beneficially or harmfully), with every other object in the software. The table below shows how much more rapidly the opportunity for harmful interactions rises than the actual size of the code.
Insert Table of showing size of software system plotted against number of potential defects per line of code.
The curve of this relationship (see above left) rises exponentially as the opportunity for unforeseen interactions increases with the square of the number of objects present in the software. As a result, software is becoming more complex and fragile at a time when it needs to be most robust as more and more of our daily life, both business and personal, are entrusted to software.
No single human or group of humans can administrate this ever-increasing complexity. As the software grows, a point is reached where it is impossible to make any more changes to the software. It has become so large and complex that it is too dangerous to make any changes to it, even when the change is required to fix an existing problem.
The Software Crisis can't be resolved using Engineering Management Techniques, Good software engineering practices, (object-oriented programming, data hiding, use of components, standardized naming rules, structured logic, modular design, source code control systems, release and configuration management systems, self documenting code, code reviews and code browsers), are not enough to prevent or fix this problem. It exists even when all these practices are used.
Additionally, and more importantly, these engineering practices take time which vendors competing in the software market do not have, They must be one of the first to release their product if they wish to maintain a leading share of the market. The attempt to build quality into a software package is often the first casualty of ship date deadline pressure.
Next Chapter:
The design differences between successful Open Source software and proprietary software:
Why modern software has so many bugs and why successful Open Source Software has a higher level of quality.
Chapter 1
When a software package reaches a certain level of complexity, it becomes unprofitable and even dangerous to make further changes, (even to fix defects in the package). This is the Software Crisis.
Critical Issue: the Software Crisis means huge amounts of money will be lost. Of the $250 Billion spent annually on IT projects approximately 31%, ($77.5 Billion), will be squandered on projects which will fail and be canceled. Going beyond IT spending to software product liability costs, financial, medical and other software have already accounted for large settlements being reached for various financial as well as physical injuries including at least one actual fatality. Clearly not a trivial issue.
The Software Complexity Crisis
Despite the best intentions of the architects, programmers and managers, many software products produced today consume grotesquely large amounts of disk and memory. As the software grows larger, the number of defects also increases. But the number of defects rises faster than the increase in the size of the software. Each object (variable, function or operation) in the source code of the software has the potential to interact, (beneficially or harmfully), with every other object in the software. The table below shows how much more rapidly the opportunity for harmful interactions rises than the actual size of the code.
Insert Table of showing size of software system plotted against number of potential defects per line of code.
The curve of this relationship (see above left) rises exponentially as the opportunity for unforeseen interactions increases with the square of the number of objects present in the software. As a result, software is becoming more complex and fragile at a time when it needs to be most robust as more and more of our daily life, both business and personal, are entrusted to software.
No single human or group of humans can administrate this ever-increasing complexity. As the software grows, a point is reached where it is impossible to make any more changes to the software. It has become so large and complex that it is too dangerous to make any changes to it, even when the change is required to fix an existing problem.
The Software Crisis can't be resolved using Engineering Management Techniques, Good software engineering practices, (object-oriented programming, data hiding, use of components, standardized naming rules, structured logic, modular design, source code control systems, release and configuration management systems, self documenting code, code reviews and code browsers), are not enough to prevent or fix this problem. It exists even when all these practices are used.
Additionally, and more importantly, these engineering practices take time which vendors competing in the software market do not have, They must be one of the first to release their product if they wish to maintain a leading share of the market. The attempt to build quality into a software package is often the first casualty of ship date deadline pressure.
Next Chapter:
The design differences between successful Open Source software and proprietary software:
0 Comments:
Post a Comment
<< Home