Software Engineering: An Idea Whose Time Has Come and Gone?

Dear Editor,

I would take issue for Capers Jones' reliance on Quality control in his last statement. My firm belief is that quality has to be built in the product - ie. engineered into. Over emphasis (reliance) on quality control as a means to completing the design after the build has caused any number of problems.

I have come across practices where in one instance rewards were increased (or penalties reduced) depending on number of defects found at the quality control stage against benchmarks. In another instance, the development shop were asked to find 10 defects for every defects found by the quality team.

While we may or may not agree on these specific methods, they do have the effect of putting responsibility where it belongs - in design and engineering, and not the support processes. After a few iterations of this, the development shop "got smart".

Improving the quality of design (often a victim to intellectual laziness) is arguably a better approach than to have to find a net fine enough to catch all bugs and spend an eternity fixing them. A good design anticipates eventualities and makes it easier to prove what works.

Likewise, if we cannot take good change control (meaning have a good process for) for granted, we shouldnt be in this business anyway. These are bread and butter issues if I may use the term, and pre-requisites to embarking on any enterprise in software development.

Apropos Bob McCann's note, if it is any consolation, the lack of what I like to call "shared goals" occurs in in house projects as well, though not perhaps, as much as when a large number of independent contractors are involved. Organisations that have a high "political index", to coin a phrase, seem to suffer from this more than others. It takes a significant amount of time and effort to convince each stakeholder how he/she benefits from the goal. Even then, there are no guarantees.

Having said that, organisations that rewards well, and spreads them relatively more equitably seem to do better. The Silicon Valley example probably underscores this the best.

Regards
Kannan Vijayaraghavan
Athreya Associates
Singapore
kvijayaraghavan@gmail.com

Posted on 8/3/09 10:44 PM.

As so much other writing about software engineering, DeMarco's viewpoint is overly pessimistic - kind of a fin de siècle atmosphere. However, software engineering as currently practiced is not only about control (or if you like, failing control) but also about design, with underlying design sciences as studied by Herbert Simon (The Sciences of the Artificial) and others. Next to well-publicized disasters, there is a lot of good design out there in present software engineering practice. The really interesting phenomenon is the continuing gap between the writing about software engineering and the practice of software engineering.

Posted on 9/9/09 12:48 AM.