Archive for March, 2008

Five Points To Improve Your Estimation

Software Estimation is tricky business.  You are often confronted with complicated technical (or even non-technical) work and asked “how long will it take?” on the spot.  You are given fuzzy requirements (or no requirements) with ambiguous definitions and have to work with a code base that is best described as “chaos”.  How can you give an accurate estimate with such a difficult environment? 

I recently read an excellent book called “Software Estimation: Demystifying The Black Art"

Here are some amazing points that you can use.
1)       We should not be pressured to reduce our estimates.  Stick to your estimates – whatever they are.  If management wants to reduce them, that’s fine, but stick to whatever you put in the first place.  Managers trying to reduce estimates is a very silly thing to do, because by looking at the track record of our software industry, you will find that we consistently underestimate, not overestimate!  So if you are pressuring your developers to reduce the estimate, you are asking for trouble.  Better thing to do would be to see if the estimate is well founded, based on task level estimates, or is the estimate based on unjustifiable assumptions, etc. 

2)       Underestimating is MORE expensive than overestimating.  So if you cannot estimate accurately, lean towards overestimating.  Underestimating has an exponential additional cost, whereas overestimating has a potential of a linear extra cost due to Parkinson’s law.  This is because underestimating results in lots of other problems such as having extra meetings to justify why you are behind schedule, having extra meetings to decide which features to cut, added stress on developers trying to meet tight deadlines, code having less quality in order to ‘just finish it’ so that developers can go home, having customers get angry at not-ready releases, having other teams who are waiting for the code to slip their schedules too, etc..  If you overestimate, then Parkinson’s law can kick in and developers will ‘fill in the empty time’, or as they say ‘work expands to fill the available time’

3)       Task level estimates are best done by the developer who will be doing the work.  A task level estimate is defined as a low level estimate for a particular item of work.  For example, for building a workflow engine, a task level estimate is “2 hours to add the save button that will commit the changes to the database”.

4)       With small teams (say under 5 people), estimates are most accurate when done bottom-up (i.e. from the developers).  What this means is your complicated formulas for estimation are not so helpful in such environments. 

5)       There are many other ways to estimate such as ‘estimation by analogy’ (i.e. by looking at a similar project that was built), and so on, but I won’t explain those right now.  The trick in general is to try to quantify as much as possible and leave subjectivity out of the picture.  So if you can find out how similar your project is in terms of number of lines of codes, number of features, etc, you will have a better estimate.  As well, don’t be fooled into thinking that more “estimation knobs” will give you a better result than less “estimation knobs”.  I define an estimation knob as some sort of criteria you are using to estimate, such as “size of team”, “team programmer skills as a percentile of the industry”, “how many burgers they had for lunch”, etc..  It looks like it would give you a better result but in reality the estimate becomes more and more subjective as you add more “knobs”
As well, developers are more likely to try to meet their estimates if they are the ones who gave it, rather than if its dictated to them from above.

Lastly, estimation is a skill we can learn and improve over time.  You will find that over the months, your developers will get better at estimating based on past experience.
In summary, stick to giving your developers clear requirements, lock them down, and then get them to break down the requirements into task items, and then estimate for those task items. 

My experiences with pair programming

My initial thoughts on pair programming (definition).

Normally at our shop, we don’t do pair programming.  Each developer is assigned his or her own tasks and they are responsible for completing them.  If they require assistance of explanation from another developer who is more familiar with that system they need to go and request that assistance on their own.  I believe the vast majority of offices work in this manner.

However, yesterday we decided to try pair programming.  We have a complicated CRM application where it takes months to learn the application, and the situation is that another fellow who works on the reporting side of things and I worked together to solve a few bugs in the system.

As we worked together (with a slightly decreased speed than the two of us seperately working) we managed to eliminate two instances of duplicate SQL code in our application and instead used a view that already existed which I was not aware of.  As well, I am very confident you that this resulted in a much higher quality of the application, even if it took longer.  You are far less likely to end up with bugs when you use pair programming.

I am still skeptical if it really was slower or not, because when you work on your own, you can get stuck on a particular problem and waste half a day, whereas when the other person knows it, you can immediately solve the problem and move on.  As well, you are less likely to waste time checking the news, weather, etc, because the other person is sitting and working with you.  Also, keep in mind that "task switching is expensive".  When you are working on a piece of code and you are "in the zone" and then you have to stop to assist someone else, this lowers your productivity, whereas when both of you are concentrating on one issue, you don’t have this issue.

Pair programming can also be used to train or "rough in" new employees, and as well it results in increased code awareness (i.e. both of you are trained on the same piece of code, incase one of you quits or is sick, the other person also has a good idea of the code).

While the jury might still be out on this principle, and maybe its still too "extreme" for most managers to allow it, give it a shot when you have a chance and see how it goes.


Optimization WordPress Plugins & Solutions by W3 EDGE