Home » Lean Six Sigma Articles » Software Quality

Software Quality

I was reading through the Oct 2007 issue of SoftwareTech from the DOD and, having grown up in software over the last four decades, I agreed with their analysis of the current state of software quality (kind of pathetic).

In 2003, the Standish Group's "Chaos Report" said:

in 2003, only 34% of software projects are deemed "successful"
1994 rate: 16%

Augustine's Law: Software complexity grows by an order of magnitude every 10 years:

1960s: F-4 aircraft had 1000 lines of code (LOC) and software accounted for less than 10% of total specifications.
1990s: F-22 has 1.7 million LOC and software was 80% of the specification.
2000: The F-35 has over 8 million LOC.
Software and testing delays pushed the cost of the B-2 over congressional ceiling.
There were multi-year delays in the software for the F-22.

In other words: software is more complex than ever. Testing software is more impossible than ever. The old, reactionary, "software cowboy" code and test methods are yielding to a proactive approach.

Software Engineering
The term "software engineering" was introduced in 1968, but author Dr. Kenneth Nidiffer points out that "software is intangible in that it has no mass, no volume, no color, no oder -- no physical properties." I'd like to argue that you can't engineer an intangible with no physical properties. It needs a different metaphor.

Requirements
In the old days, software systems often stood alone, rarely interconnected to anything else. It was possible to use Royce's "Waterfall" methodology to specify requirements and "build" a system.

Now, however, Barry Boehm of the Software Engineering Institute (SEI) argues that users are more likely to use the IKIWISI (I'll know it when I see it) method of specifying requirements. He says: "Increasingly, though, the nature of both the system's requirements and preferred solution elements are becoming much less feasible to specify in advance."

In other words, you can't "build" today's software, you have to "grow" it and evolve it to converge on the user's requirements.

Software Evolution
In 1990, I introduced a term that didn't catch on called Software Evolution. This is the idea that software doesn't build or engineer, it grows and evolves.

Boehm mentions in his article that the SEI's report on Ultra Large Scale Systems (a.k.a. software intensive systems of systems [SISOS]) are "best considered as ecosystems, which contain internal ecologies among their component systems, and which participate in external ecologies."

What's an ecosystem? Wikipedia defines an ecosystem as a natural unit consisting of all plants, animals and micro-organisms in an area functioning together with all the non-living physical factors of the environment. In other words, a software ecosystem may not be alive, but it's like a living system.

Maybe the future of software isn't engineering, but cultural, botanical, organic or medicinal. Maybe we'll "transplant" functionality from one application to another. Maybe each module will be a "cell". We often hear these metaphors in object-oriented programming: inheritance, parent-child, and so on.

Sometimes improvements in quality depend on changing the larger "frame" of mind in which it is set. In this case going from engineering to evolution, albeit a directed evolution, not a random one.

QI Macros SPC Software for Excel
QI Macros software has gone through many of these evolutionary cycles. It started small as a set of independent modules to do pareto charts, histograms and control charts. Then, it became multicellular (all modules in one program). Modules were added and adapted as required.

Revolutionary new functionality appeared like the Control Chart Wizard that automatically chooses the right control chart based on your data.

Then, we had an extinction event. Excel 2007 wouldn't execute all of the old macro language. So I had to rewrite the software in visual basic so that it would continue to be viable in the new environment.

Here's My Point
Sometimes cause-and-effect analysis has to "chunk up" to higher levels and examine the metaphoric underpinnings of poor quality.

What metaphors do you use in your business?

War means that you have generals and jeep drivers. You have to outflank the competition.
Fire fighting means that you have arsonists and heros.
Are you rigid and inflexible, or do you follow Bruce Lee's advice to be like water: fluid and ever changing?

Do you use economies of scale (i.e., mass production) or economies of speed (i.e., Lean production)?

Do you employ Black Belts (i.e., dojo and martial arts) or money belts (financial analysts)?

Metaphors trap us into one way of thinking and a limited set of solutions. When you change your metaphor, you open up new and improved methods of resolving issues. Isn't it time to evaluate the big picture root causes?

"Challenges Dominate Our Future," Ellen Walker, SoftwareTech, Vol. 10, No. 3, pp. 3-5.

"Future Challenges and Rewards for Software Engineers," Barry Boehm, SoftwareTech, Vol. 10, No. 3, pp.5-12.

"Addresssing the Software Engineering Challenges over the Years and into the Future," Dr. Kenneth E. Nidiffer, SoftwareTech, Vol. 10, No. 3, pp. 14-21.