Improving Software Estimates Part 3

In the first post entitled "Improving Software Estimates" I described two scenarios where the estimates were incorrect.

First let me digress and say an estimate is neither right or wrong. It is an estimate. When I say an estimate was incorrect I mean the estimate and the actual results varied. In the world I live in an estimate for when software will be finished is a prediction. Predictions for software delivery dates are used to schedule dependent tasks. So, when I use the term estimate I am using the common vernacular of the industry. I prefer prediction.

Back to the point of this post. The second failure scenario is that the developer was developing something new and had no prior experience that could be directly applied. When faced with the unknown then I rely on "method" to help me through.

The "method" I use for tackling the unknown is called "Software Scouting and Reconnaissance".

“Scouting” is the metaphor. During the exploration of the American frontier, scouts were sent out ahead of the company to determine the safest path through unknown and hostile territory. Through software “scouting missions” one can save time and money, and reduce the risks to the company.

When one is in unknown territory scout ahead for information and then come back and apply the knowledge gained. Have enough discipline not to get distracted by the sights along the way. Stay focused, travel light, and get back to camp as quickly as possible.

This pattern of short scouting trips would continually repeat, making the technique both iterative and incremental.

Before starting the journey into the unknown you must do as much study as possible. Gain as much knowledge as you can so that you can apply it as you go.

After the study is complete then define your domains and sub-domains. Create your dictionary of terms and metaphors that you will use to describe the potential solution. In other words I recommend coming up with a high level design. This design can be in your head, on paper with diagrams or text, what ever works for you.

This design is used to break the whole into smaller tasks. These smaller tasks are your weigh stations along the journey.

All of this is preparatory work so that you can take your first heading. Every journey starts in some direction.

At this point I start writing code. Starting with the end in mind is one of the best ways I know to get you going. One can analyze and study the problem for way too long especially if you are nervous about the first step. I use Design By Use (DBU) to do this. I write the code as if the methods already exist. It is very much like Test First Programming described in Extreme Programming. In Part 2 of this series I described DBU as a method to synchronize two teams. DBU can be applied even if you are going to write all of the code and you have no external dependencies.

"Code your way" towards the completion of the first small task. You will be learning as you go and now you can apply this knowledge and experience and revise your estimate of completion. You continue in this iterative and incremental fashion until the remaining task is so small that you feel you can't miss your estimate too badly or until you have enough experience that there is nothing unknown left and you can estimate the remaining work just like you would on a task where you have experience.

To recap when I am faced with developing software where I do not have any experience I rely on processes and methods to carry me forward. Specifically I use Software Scouting and Reconn and Design By Use to move forward in an incremental and iterative fashion until I have finished.

Geoff