March 8th, 2004

classic beard

Reduce to previously unsolved problem.

In 2001, ACM Software Engineering notes published what amounts to a root-cause analysis and proof that software estimation is impossible. The paper is titled "Large Limits to Software Estimation", and binds software estimation to algorithmic complexity estimation, then shows that finding either algorithmically is infeasible. Not a highly convincing paper, but one could take from it the seeds of some useful ideas:

* Software can be split into two parts - the part that you can estimate because it is close to exactly something you've done before, and the part that you can't estimate at all, which is what (in practice) blows your estimate out of the water. (This is pretty much directly stated in the equations.)

* A key to estimating successfully anyway is *knowing* which bucket the pieces of your estimates are in. Then you can perform experiments, or more detailed design, or otherwise focus extra energy on the landmines in the second bucket (my extrapolation, anyway, and I have some experiments in progress on this theory, as well as re-evaluating some old successes in this light.)

* Higher level languages and tools should let you increase the precision of items in the first bucket, and possibly place more things there, simply because you can reduce "figure out how to implement this piece of design" to "glue these components together" for a broader range of design pieces. (This is fricken' obvious, it is the whole point of abstraction, except that it is different way of looking at the impact of such tools - completely removing it from the (quite possibly spurious) realm of "productivity".

Just some thoughts, as I distract myself from QA automation and QA hiring :-)
  • Current Mood
    amused amused