Thursday, April 28, 2011

Software Estimation - Understanding


As I work in software testing using automation, giving a figure of how long it will take to finish something is hard. Sometimes the figures are correct, some times not. When I started reading about that, there some rules of thumb given. Get the time from developers, double it add a little bit is one of them. Other reason  is software developers work to create new knowledge. I have problem with these kind of maxims.

If you think about this conclusion, software estimation is hard because it is work to create new knowledge, you would obviously need to ask what about other sectors, engineering disciplines are doing in this area.

Is producing new cars is hard because they work to create new knowledge?

Is inventing new drugs/medicines is hard because they work to create new knowledge?

However, one can argue that, they are just one or two exceptions, others sectors are same.

How about designing a new home? 

How about exploring for oil?

The point is, all kind of estimations are actually predictions. Even if it called as forecasting, it is still prediction about future. The problem is no one can predict what they don’t know. If they know, there is no need to predict it.

Here is quote from my favorite author Nassim Nicholas Taleb in Black Swan,

Consider the wheel again. If you are a Stone Age historical thinker called on to predict the future in a comprehensive report for your chief tribal planner, you must project the invention of the wheel or you will miss pretty much all of the action. Now, if you can prophesy the invention of the wheel, you already know what a wheel looks like, and thus you already know how to build a wheel, so you are already on your way. The Black Swan needs to be predicted!

Read Black Swan about the highly improbable.

Let us take another simple work. Delivering mails (not emails), packages, parcels to customers. There is no thinking involved in it, right? If it is so, why we have a tracking feature to know where is the package now.

Coming back to where we started, if estimation is hard how do we know when the project/development will complete?

The short answer is there is no fail proof method to know.

The long answer is, we use what we know to know when approximately it will complete, keeping in mind that something may go for toss at any time. Use number of options such tracking the progress, following standards etc may solve the some of the issues.

If you consider, software test estimation, the picture is gloomy. In developing software, the work is cut. You have basic understanding of what the end product will look. However, that is not possible in test estimation. I am not going for clichés here.

Yes, there are lot of strategies one can use to find bugs in the software. However, even if testing for lot of possibilities may still leave bring disaster because the tester haven’t tested for one possible input.

Understanding that we can’t predict what we don’t know will be a first step to solve these issues.


raja's shared items

My "Testing" Bundle