Before I jump into this post, let me describe what I mean by Engineering Activity. An activity where knowledge of relevant science is applied to achieve the required result is an Engineering activity.
I was reading this paper titled “Large Limits to Software Estimates” (PDF link) by J. P. Lewis (published in ACM Software Engineering Notes,Vol 26, No. 4, July 2001). I am not much of a mathematical theorems person, so I skipped the initial few sections and came to the conclusions part. In the conclusion part, the author raises the question – “Should Software Estimation be called as Engineering?“. He argues that if we were to consider Software Estimation to be an engineering process, then litigation/conflicts should be a reasonable or acceptable outcome for incorrect estimations. If not, the author raises the questions associated with ethics in the software community – considering that so many estimates are ill-founded or bloated. The author also points to another article titled – “Are We Developers just liars or fools?” by Robert N. Charette. (If you are not ready to pay to ACM for this, here is a link to a similar article written by the same author.)
Before I jump into writing my thoughts on this one, I wanted to point out to a quote from Hannah Arendt, a self-claimed German-Jewish political theorist, which I had read sometime back.
Promises are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.
To come to think about it, software estimation is also about trying to make the future predictable and reliable. However, except probably the psychics, I am not sure how many of us would make a claim on predicting the future to the reliable extent. This brings to my next point.
Anyone who has been in this business, doing software estimation is one of the toughest job. If given a choice, most of us would probably prefer the “will call you when it is done” approach for communicating the estimates. While I agree with J. P. Lewis that estimation should be based on sound engineering principles; however in reality that is rarely humanly possible in software business.
Most of the estimates today are based on past relative experience and gut feel of the individuals even if the functionality is broken down to the nearest function points. I am not saying this in any negative way. Almost all who have had some good relative experience in this business would realize the fact that software development is a process of gradual refinement. This is especially true in today’s world of internet-enabled mass-consumer products as compared to a decade back. We have to keep in mind that both the consumers and the producers of the software products are in the end human beings. IMO, it is hard to find human beings who know what exactly they want consistently. Because of this the software estimation process is going to remain fuzzy in the initial stages and typically gets better refined with the time. So Robert Charette’s argument that software industry should stop reporting incorrect estimates in order for it to be held up for respect and emulation is slightly naive in my humble opinion.
Software estimation should be treated for it really actually means. Dictionary meaning of estimation is “approximate calculation“. And the dictionary meaning of approximate is “nearly exact; not perfectly accurate or correct“. Estimates like in any other context should be treated as a guideline. All the trouble starts when it starts getting treated as a quote or as an actual quantitative number. I am personally of the opinion that estimates can never be challenged; only thing we can do is to help improve it.
So if I were to plagiarize Hannah Arendt’s quote mentioned above and apply it to software estimates, this is how it would read -
Promises Software Estimates are the uniquely human way of ordering the future, trying to make it predictable and reliable to the extent that this is humanly possible.
I would love to hear your thoughts or comments.