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
Wednesday, April 18, 2007
Sunday, April 15, 2007
Improving Software Estimates Part 2
In the first post I described two scenarios where the estimate was incorrect. In the first description the delivery estimate was incorrect because of external dependencies.
Software is often developed by teams of engineers. Also it is common that several teams work simultaneously. Estimation is important when coordinating several teams.
I have addressed the issue of team coordination with a process known as Design By Use (DBU). DBU is not intended to be the single solution to coordination issues but is intended as a tool.
In the scenario previously described the developer was unable to meet his estimated delivery schedule because of an external dependency. This is often a "down stream" dependency. You can not continue until the other team has delivered so that you can link to their system. DBU addresses this issue by defining the integration interface early and integrating immediately.
When designing code the "caller" has certain data available at specific levels of the system. The "callee" does not know what data is available to the caller and therefore it is risky for the callee to define the interface based on assumptions. Assumptions of data availability may break domain models and layers of separation. Therefore DBU teaches us that the caller should write a usage example and give it to the callee. Do you see how this addresses the coupling concerns had by the caller?
Also the callee is benefitted by DBU. The principal of "you aint going to need it" (YAGNI) is addressed by DBU. I have written many internal utility libraries over the years. Without knowing exactly how your library is to be used by other teams at your company it is easy to add features and overloaded methods in the attempt to "be everything for everybody". This ultimately leads to lots of code that is never called and which become maintenance baggage from "then on out".
By addressing YAGNI you gain the benefits of improved efficiency in that you are not writing anything extra. You only write what someone is going to use and you know that they are going to use it because they (the caller) specified the interface.
How is software estimation improved?
The caller controls their domain and abstraction layers and protects the coupling of the system. Loosely coupled systems are easier to work with and I propose that systems that are loosely coupled assists in the estimation process. If the caller discovers that additional systems must be coupled it is known sooner rather than later. This addresses integration issues which have proven to be one of the most costly activities of software development if ignored until the end.
The callee is also helped with the estimation task by not having to design a system that will "be everything to everybody". They can focus on the specified interactions exclusively. The first thing they can do is provide a stubbed version of the system to the caller so that they can immediately link to their system. Then the caller can continue to work while the callee implements the solution. Pretty slick I do have to say.
Here is a link to a specific application of DBU. It describes how DBU can be used to organize multiple teams.
http://home.comcast.net/~gslinker/maverick/DBU.html
If you address integration issues early and only write what is needed software estimates can be made simpler and it is my belief that reduced complexity is directly related to improved software estimation.
Software is often developed by teams of engineers. Also it is common that several teams work simultaneously. Estimation is important when coordinating several teams.
I have addressed the issue of team coordination with a process known as Design By Use (DBU). DBU is not intended to be the single solution to coordination issues but is intended as a tool.
In the scenario previously described the developer was unable to meet his estimated delivery schedule because of an external dependency. This is often a "down stream" dependency. You can not continue until the other team has delivered so that you can link to their system. DBU addresses this issue by defining the integration interface early and integrating immediately.
When designing code the "caller" has certain data available at specific levels of the system. The "callee" does not know what data is available to the caller and therefore it is risky for the callee to define the interface based on assumptions. Assumptions of data availability may break domain models and layers of separation. Therefore DBU teaches us that the caller should write a usage example and give it to the callee. Do you see how this addresses the coupling concerns had by the caller?
Also the callee is benefitted by DBU. The principal of "you aint going to need it" (YAGNI) is addressed by DBU. I have written many internal utility libraries over the years. Without knowing exactly how your library is to be used by other teams at your company it is easy to add features and overloaded methods in the attempt to "be everything for everybody". This ultimately leads to lots of code that is never called and which become maintenance baggage from "then on out".
By addressing YAGNI you gain the benefits of improved efficiency in that you are not writing anything extra. You only write what someone is going to use and you know that they are going to use it because they (the caller) specified the interface.
How is software estimation improved?
The caller controls their domain and abstraction layers and protects the coupling of the system. Loosely coupled systems are easier to work with and I propose that systems that are loosely coupled assists in the estimation process. If the caller discovers that additional systems must be coupled it is known sooner rather than later. This addresses integration issues which have proven to be one of the most costly activities of software development if ignored until the end.
The callee is also helped with the estimation task by not having to design a system that will "be everything to everybody". They can focus on the specified interactions exclusively. The first thing they can do is provide a stubbed version of the system to the caller so that they can immediately link to their system. Then the caller can continue to work while the callee implements the solution. Pretty slick I do have to say.
Here is a link to a specific application of DBU. It describes how DBU can be used to organize multiple teams.
http://home.comcast.net/~gslinker/maverick/DBU.html
If you address integration issues early and only write what is needed software estimates can be made simpler and it is my belief that reduced complexity is directly related to improved software estimation.
Saturday, April 14, 2007
Improving Software Estimates
As I work on my book, Experience Driven Development, I am compelled to share thoughts.
An important aspect of software development is the estimation of when software features will be complete. I have heard it said that the more you estimate the better you get at it. Is it true?
The estimate for "work" may be different than the estimate for "delivery".
Someone new at estimation may say "I will have the task done in 80 hours". While working on the task he soon finds out that a dependency is not ready and thus he has to wait. Suppose the delay is 40 hours so in the end it took 120 hours to complete the task. It is possible that if you only consider the person's time spent on the task it was 80 hours so their estimate of work was accurate. However the estimate of delivery was inaccurate because he spent 40 hours waiting on a dependency.
I believe that the experience will help the person make a better estimate next time. A better estimate in that it is more complete in considering dependencies.
Now I will describe another scenario. Suppose someone estimates that their feature will be done in 80 hours. There are no external dependencies. In reality suppose it took 100 hours to finish the feature. In this scenario the reason it took longer than estimated was because it was a new task and the person had never done anything quite like it before. In my opinion this kind of estimate will not improve. I do not think you can get better at predicting the unknown. What has happened is that the person has gained new experience and if that person encounters a similar situation in the future then he can estimate how long it will take to develop the familiar "parts" and add some amount of a guess to the estimate for the unfamiliar parts.
Experience improves estimates.
An important aspect of software development is the estimation of when software features will be complete. I have heard it said that the more you estimate the better you get at it. Is it true?
The estimate for "work" may be different than the estimate for "delivery".
Someone new at estimation may say "I will have the task done in 80 hours". While working on the task he soon finds out that a dependency is not ready and thus he has to wait. Suppose the delay is 40 hours so in the end it took 120 hours to complete the task. It is possible that if you only consider the person's time spent on the task it was 80 hours so their estimate of work was accurate. However the estimate of delivery was inaccurate because he spent 40 hours waiting on a dependency.
I believe that the experience will help the person make a better estimate next time. A better estimate in that it is more complete in considering dependencies.
Now I will describe another scenario. Suppose someone estimates that their feature will be done in 80 hours. There are no external dependencies. In reality suppose it took 100 hours to finish the feature. In this scenario the reason it took longer than estimated was because it was a new task and the person had never done anything quite like it before. In my opinion this kind of estimate will not improve. I do not think you can get better at predicting the unknown. What has happened is that the person has gained new experience and if that person encounters a similar situation in the future then he can estimate how long it will take to develop the familiar "parts" and add some amount of a guess to the estimate for the unfamiliar parts.
Experience improves estimates.
Subscribe to:
Posts (Atom)