Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[Bjorn Reese <breese@mail1.stofanet.dk>]

Shayne Wissler wrote:

> I think what it indicates is that the development methods used are
> brittle--which leads to the brittle code. If you see the secondary bug to
> primary bug ratio consistently rising, the first thing to do is ask
> questions about who is managing the project, not about the software itself.
> Even the best software will have bad ratios if the people working on it are
> sloppy.
[...]
> A lot of software does deserve to be completely rewritten. But that should 
> be apparent by how slow you have to go when adding features, not by 
> ever-cascading bugs. On the contrary, if you see bugs spiraling out of 
> control, that's evidence that you don't want that particular team and/or 
> its management to undertake rewriting the system.

While sloppiness, or similar human traits, may be a contributing factor,
I think that it is too simplistic to attribute cascading defects to this
single factor. Nor do I believe that the situation will improve in general
by replacing the people.

The major factor, in my experience, to cascading defects is increasing
cognitive complexity of the system, usually combined with insufficient
staffing. The problem is that no matter how clever your staff is, they
will eventually reach a break-even point where the cognitive complexity
of the system exceeds their mental capabilies. Blaming or replacing the
staff will not decrease cognitive complexity.

If you replace the staff, you also risk that the new people will simply
make the same mistakes that the old staff did. Assuming that at least
some from the old staff is capable of learning from their errors, they
may be in a better position to rewrite the system. They also have a
broader understanding of the required domain knowledge.