been proven to cause harm in a significant number of applications that used them. This is not to say that they always fail. Sometimes, albeit rarely, they may even be useful. But in a majority of situations, they do more harm than good in repeated trials.
What is a distressing aspect of the software industry is that bad practices seldom occur in isolation. From looking at the depositions and court documents of lawsuits for projects that were cancelled or never operated effectively, it usually happens that multiple worst practices are used concurrently.
From data and observations on the usage patterns of software methods and practices, it is distressing to note that practices in the harmful or worst set are actually found on about 65 percent of U.S. software projects as noted when doing assessments. Conversely, best practices that score 9 or higher have only been noted on about 14 percent of U.S. software projects. It is no wonder that failures far outnumber successes for large software applications!
From working as an expert witness in a number of breach-of-contract lawsuits, I have observed that many harmful practices tend to occur repeatedly. These collectively are viewed by the author as candidates for being deemed “professional malpractice.” The definition of professional malpractice is something that causes harm that a trained practitioner should know is harmful and, therefore, shoukd avoid using it.
Following are thirty issues that have caused trouble so often that the author views them as professional malpractice, primarily if they occur for applications in the 10,000 function point size range. That is the range where failures outnumber successes and where litigation is distressingly common. Only one of fifteen lawsuits where the author worked as an expert witness was smaller than 10,000 function points.
Table 4: Candidates for Classification as “Professional Malpractice”
|
1 |
Defect removal efficiency < 85% |
|
2 |
Defect potentials > 6.00 per function point |
|
3 |
Reusability (uncertified with high defect volumes) |
|
4 |
Inadequate cost tracking with “leakage” > 40% of actual costs |
|
5 |
Excessive schedule pressure by clients and executives |
|
6 |
Inadequate or deceptive progress tracking that conceals problems |
|
7 |
Inadequate security controls |
|
8 |
Inadequate inspections of requirements, design, and code |
|
9 |
Inadequate defect tracking methods that starts late |
|
10 |
Failure to estimate requirements changes |
|
11 |
Error-prone modules in applications |
|
12 |
Inadequate problem reports |
|
13 |
Inadequate measurement of quality |
|
14 |
Rejection of estimates for business reasons by clients or executives |
|
15 |
Inadequate testing with low coverage |
|
16 |
Inadequate risk analysis prior to funding |
|
17 |
Inadequate cost estimating methods |
|
18 |
Inadequate value analysis |
|
19 |
Inadequate change control |
|
20 |
Inadequate sizing prior to funding |
|
21 |
Partial productivity measures that concentrates on coding |
|
22 |
Lines of code metrics (LOC) for economic analysis |
|
23 |
Inadequate governance by corporate executives |
|
24 |
Inadequate requirements gathering |
|
25 |
Cost per defect metrics |
|
26 |
Inadequate customer support |
|
27 |
Inadequate measurement of productivity |
|
28 |
Generalists instead of specialists for large systems |
|
29 |
Manual cost estimating methods for large systems |
|
30 |
Inadequate test library control |
It is unfortunate that several of these harmful practices, such as “cost per defect” and “lines of code” are still used for hundreds of projects without the users even knowing that “cost per defect” penalizes quality and “lines of code” penalizes high-level languages.
Collectively, many or most of these thirty harmful practices are noted in more than 75 percent of software applications =>10,000 function points in size. Below 1,000 function points, the significance of many of these decline and they would drop out of the malpractice range.
Summary and Conclusions
The phrase “software engineering” is actually a misnomer. Software development is not a recognized engineering field.
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
