Scoring and Evaluating Software Methods, Practices, and Results

[article]

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

TechWell Contributor's picture TechWell Contributor

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.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09