My current focus is to develop an estimation tool. Not just for software, but for a wide range of industries. Software estimation is, of course, closest to my heart, given that my line of work is software.
This is where Practical Software Project Estimation (3rd Ed), edited by Richard Hill, comes into frame (publisher’s web store). Essentially my estimation library is a bit thin and I decided to add this item (ahead of some other books currently on their way from Amazon).
The key thing about the book is this: it’s essentially built around a database collected and curated by the ISBSG. And, in turn, the ISBSG’s database is built around the use of function points.
One thing that’s weird about my industry is how short our memories are. So, for example, I would say that a very large fraction of all currently-active software professionals don’t know what “function points” are.
Some history is in order. It starts with a deceptive question:
“How big is this piece of software?”
The problem is that there’s no real, universal measurement for that. The most common is counting lines of code; but this immediately runs into the rather large confounding problem that lines of code for one language are not comparable with lines of code in a different language. There are other problems, but let’s skip them for now.
In 1979, IBM research Allan Albrecht realised that instead of taking some physically countable feature of software (lines of code, bytes of disk space occupied etc), he could count logical features of the software (different kinds of data tracked, inputs and outputs) and use that as an abstract measure of software size. Thus were function points born.
The practical upshot is that function points is a way of giving a measurement of the size of a piece of software; that in turn can be used as a basis for estimating effort, then the effort can be used to estimate cost and calendar time. It’s not perfect, but it’s not awful, and function points can often be derived from a study of requirements documents.
So that’s the potted history.
The downside is that the book relies almost entirely on function points as its basis for estimation. There is some attention paid to other estimation methods, but it is fleeting. The real character for the book is as a handbook for estimating with ISBSG data. That’s fine as far as it goes, but it’s not what I was looking for.
Consequently, the book suffers from having a poor audience focus. If it’s directed to folk familiar with the ISBSG’s work and function points, then the (very short) chapters on function point counting methods aren’t necessary. Yet if it’s directed to the general software engineering profession — they’re too short and perfunctory.
I own two other estimation books. One is Mike Cohn’s Agile Estimating and Planning (unreviewed), which while a passable read is IMO heavily padded out. The second is Steve McConnell’s Software Estimation: Demystifying the Black Art (unreviewed). As usual, McConnell’s summary of a subfield within the wider span of software engineering is basically the best there is. His knack for synthesising and simplifying entire bodies of literature into readable, practical, chatty books is remarkable.
Regretfully, Practical Software Project Estimation doesn’t measure up in such company. I suppose that for folk who are working with the ISBSG repository, this book forms a useful guide or manual. But for general software professionals, I can’t recommend it.