Monday, May 5, 2008

to estimate features you have to measure features

i just read an article from 6th sense analytics. i've been talking a little bit about putting metrics at the task level in another email thread. i thought i share this posting with the entire group (so you can also start reading 6th sense's blogs). anyway, here is what the article said:

We all know that developers can't estimate time, don't we? But why not? Developers are very smart. We deal with abstract concepts every day. You'd think we'd be able to learn this skill over time. But somehow we never get better at work estimation. Some people attribute it to a developer's innate optimism, and that's part of it. But there's a more important factor here.

There's an old saying... "Those who ignore history are doomed to repeat it". And as Einstein put it "Insanity is doing the same thing over and over and expecting a different result".

Here are you steps to improving your estimation attempts.
1) Estimate smaller (more granular) features
2) Always look back at estimates vs. actuals
3) Get your feedback as fast as possible

and i would agree. the article is focusing on time estimates, but i think one could utilize this technique for other metrics. one of the useful skills that i have been learning as i gain more experience is being able to think about and analyze the impacts of a new task, feature, improvement, or bug. i am learning to be able to evaluate the situation first before just diving into code. i do this by learning the necessary APIs, grounding the problem, and tackling small pieces at time. one thing that i feel is lacking in my quest to improve in this area is software metrics. i can use historical (previous task) data to help guide my planning; even if the planning is a few minutes.

to be honest, i'm not sure it would be super useful. but it sure sounds useful. it seems that it just increases the fidelity that you have to make decisions and learn. i really think that putting metrics next to tasking will be useful to my development process. tasking is very important in the commercial world; it drives the development process. we don't have the luxury of saying, "oh, coverage is low lets do some testing". testing needs to be in-process during our task work.

there are all sorts of things that we can do with tasking. for example, "hm.... i wonder if someone in the company (on another project) has seen this sort of bug before." anyway, thats a different issue; and something we haven't talked about in a while.

anyway, we have to start measuring features before we can estimate features.

UPDATE: this posting is what i kinda meant in driving your project with hackystat.

No comments: