Software Laws And Their Relevance Today
Software Laws Article In Crosstalk 2017
I always enjoy the writings of Capers Jones and was pleasantly surprised to see an article in Crosstalk Magazine (which I was also surprised was still published... I recommend it) listing the laws of software engineering. Many of my heros have laws listed in this fascinating article. Of the set of software productivity laws I published Capers chose one "projects that get behind stay behind" to include in the article.
"Galorath’s Seventh Law: Projects that get behind stay behind.
Dan Galorath has a number of other laws, but this one has poignant truth that makes it among the most universal of all software laws. While there are some consultants who are turnaround specialists, by and large, projects that fall behind are extremely difficult to recover. Deferring features is the most common solution. Many attempts to recover lost time, such as skipping inspections or truncating testing, backfire and cause even more delays. This law is somewhat congruent with Brooks’
Law, cited earlier. See also Gack’s Law."
Also I quote a few other of my favorite software laws from Caper's paper. I recommend reading the whole paper.
"Weinberg’s First Law: If a program does not have to be correct, it can meet any other requirement.
This law is intriguing. Most programs are not correct, yet they are deployed and used daily. Only when serious bugs occur does the lack of correctness have a major impact. The essence of the idea is that correctness is difficult, but other factors are not as difficult."
"Pareto Principle (Applied to Software Quality by Capers Jones): More than 80 percent of software bugs will be found in less than 20 percent of software modules.
The discovery of error-prone modules (EPM), which receive far more bug reports than normal, was first made in IBM in
the 1970s and confirmed by other companies including ITT, AT&T and many others. In general, bugs are not randomly
distributed but clump in a small number of modules, often with high cyclomatic complexity. This phenomenon is common on
large applications above 1,000 function points in size. For the IBM IMS database project, about 57 percent of customerreported
bugs were found in 32 modules out of a total of 425 modules in the application. More than 300 IMS modules
had zero-defect bug reports from customers. Inspections and surgical removal of error-prone modules raised IMS reliability
and customer satisfaction at the same time that maintenance costs were reduced by more than 45 percent and development
cycles were reduced by 15 percent. Such findings confirm Crosby’s Law that software quality is indeed free. It often happens
that less than five percent of software modules contain more than 95 percent of software bugs. The Pareto Principle
has been explored by many software researchers, including Gerald Weinberg and Walker Royce, and it seems relevant to a
wide range of software phenomena."
"Gack’s Law: When executives or clients demand unrealistic and unobtainable project schedules, the probability of substantial cost overruns and schedule delays will double; the actual project’s schedule will probably be twice the optimistic schedule demanded by the stakeholder.
This law has been known for many years by software quality and process consultants. However, in spite of hundreds of projects that end up in trouble, impossible schedules without the benefit of either accurate parametric estimates or accurate benchmarks from similar projects continue to be the most common way of developing medium to large applications between 1,000 and 10,000 function points in size. This size range is characterized by amateurish manual estimates and failure to bring in external benchmarks from similar projects. (Really large projects in the 100,000-function point size range tend to use professional estimating personnel, parametric estimating tools, and historical benchmark data, although many of these massive projects also get into trouble."
"Jones’ Law of Software Failures: The probability of a software project failing and not being completed is proportional to the cube root of the size of the software application using IFPUG function points with the results expressed as a percentage. For 1,000 function points, the odds are about 8 percent; for 10,000 function points the odds are about 16 percent; for 100,000 function points the odds are about 32 percent. This law is supported by empirical data from approximately 26,000 projects. However, government projects and information systems fail more frequently than systems software and embedded applications."
Full Set of Galorath Software Productivity Laws
LAW 1 – Smaller teams are more efficient: The smaller the team the higher the productivity of each individual person.
LAW 2 – SOME schedule compression can be bought: Adding people to a project, to a point, decreases the time and increases the cost.
LAW 3 – Every project has a minimum time: There is an incremental person that consumes more energy than he/she produces. Team size beyond this point decreases productivity and increases time. (aka Brooks’ Law--”Adding staff to a late software project makes it later.”) Agile projects also have a minimum time to viable functionality.
LAW 4 – Productivity is scalable: Projects of larger software size can use larger teams without violating LAW 3.
LAW 5 – Complexity limits staffing: As complexity increases, the number of people that can effectively work on the project and the rate at which they can be added decreases.
LAW 6 – Staffing can be optimized For traditional projects: There exists an optimal staffing function (shape) Flat (level load) staffing is rarely optimal.
LAW 7 – Projects that get behind, stay behind: It is extremely difficult to bring a project that is behind schedule back on plan.
LAW 8 – Work expands to fill the available volume: It is possible to allow too much time to complete a project (aka Parkinson’s Law).
LAW 9 – Better technology yields higher productivity: More capable teams, better tools, and advanced, stable processes yield higher productivity.
LAW 10 – No “silver bullets”: There is no methodology, tool, or process improvement strategy out there that yields revolutionary improvements in project efficiency.
Estimation Is Increasingly Important Today
Both traditional and Agile programs need estimates contrary to the #NoEstimates statements. Many Agile developers assume estimates are really for them. But estimates are for management and stakeholders that must decide and commit to programs. Agile programs need estimates. Story Points and other root level Agile techniques are excellent. But they can't replace a project estimate.