Tom DeMarco has an opinion piece in IEEE Software titled, Software Engineering: An Idea Whose Time Has Come and Gone? He conjectures that 40 years after the NATO Conference on Software Engineering where software engineering was first proposed, DeMarco wonders if the metrics proposed during that period are still relevant? His answer is No.
But like many over generalized opinions these days, there is no context or domain for this conjecture. He states that his book Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall 1982) makes the suggestion that metrics are good and therefore more metrics would be better. But of course that sounds silly today, as it possibly did in 1982. If metrics are good, more metrics may not be better. This is a fundamental principle of performance management.
Have the right metrics, not just more metrics
And don't over generalize anything about metrics or their use. Yes we all know software development is not the same as physics and metrics are less precise. But the measures in physics ALWAYS and I mean ALWAYS have error bars attached. Why on God's Green Earth, can't the software metrics people get through their heads that:
Any Point Estimate (or measure) without an attached variance is meaningless.
Another way to say this is - all point estimates are wrong.
DeMarco then goes on the retract his statement in 1982 that control is needed for software. He cites GoogleEarth and Wikipedia. Absent again is a context and domain where control IS applicable. Real time Control, ERP, Enterprise systems, telecommunications systems (billing, call routing, diagnostics) and a myriad of other domains and contexts that are not "web centric." The very photographs GoogleEarth uses images from Digital Globe (7 miles from our home) are captured and processed with a high-ceremony development process to assure all users of their imagery that the software works as specified, arrives at the time promised, and costs what the customer was told it would cost.
Simply a Bad Analogy
DeMarco then goes on to use a bad analogy in a attempt to make his point. He uses child rearing. With two children in college I have some experience in child rearing. "You can't control what you can't measure" is his anti-thesis. Using the example of trying to control Honor, Dignity, Discipline, Personality, Grace, etc...
Steering the child is his suggestion. And a good one.
But as parents of a 19 year old and a 20 year old, we most certainty can "measure" their discipline and behavior.
- Any expulsions from college for cheating on tests?
- Maybe phone calls from campus police for drunken and disorderly behavior?
- Unpaid traffic tickets?
- Over draft notices for debt cards for food plans?
We get lots of feedback measurements everyday on their "performance" in college.
Managing Projects In The Absence of Metrics
DeMarco conjectures you manage projects by "managing the people and controlling the time and money."
"You say to your team leads, I have a finish date in mind, and I'm not even going to share it with you. When I come in one day and tell you the project will end in a week, you have to be ready to package up and deliver what you've got as a the final product."
I's say In the absence of a context and domain this suggestion doesn't make sense.
Really and how would we manage 16 subcontractors on the avionics systems (software intensive, flight, launch control and ground systems) for a manned spaceflight program through ONLY controlling the time and money? The answer - you can't. We need Measure of Performance, Measures of Effectiveness, Earned Value measures, Technical Performance Measures, Reliability, Survivability and every other "illity" you can think of.
There may well be projects that are capable of this type of behavior. I personally don't know any. What it says - in my opinion - is these types of projects a manifestly unimportant. They can be terminated at any time and the customer will take what ever you got at that point + one week's work.
"Your job is to go about the project incrementally"
And what if we have long lead items? Hardware, firmware, procurement and installation of infrastructure? Adding pieces to the whole in order of relative value? What is 100% of the pieces are need to get the first tiny bit of value.
- Part of the pre-launch sequencing controls?
- 50% of the "Everything over IP" secure routing system?
- Part of the order procurement process? Not the part that delivers the order, just the part that takes the order and debts the bank account.
- Maybe only part of the Hell Fire missile control system. The part that IDs the target, but not the part the launches the missile.
Software Engineering Definition
DeMarco finishes with the statement:
Consistency and predictability are still desirable, but they haven't ever been the most important things. ... We've tortured ourselves over our inability to finish a software project on time and on budget.
Aw, the olde on-time, on-budget metric. The Standish metric. Remember what I said about any point metric without a variance is meaningless.
- On time - within the planned completion date that includes the schedule margin?
- On budget - with the Budget At Completion including the Management Reserve?
In the absence of a context and domain the last paragraph of the opinion article has no beneficial outcome.
Not all projects have transformational goals. They may have the goal of simply moving bits across the net with secure reliability. Or processing insurance transactions for $0.02 less per transaction.
Read the article. But remember it's missing the context and domain. In today's world over generalization leads to under performance on the benefits side.
