This is the tenth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the tenth chapter.

Estimation is one of the simplest, yet most frightening activities that software developers face. So many business values depend on it. It's the primary wedge that has been driven between business people and developers. It's the source of nearly all the distrust that rules that relationship.

What is an estimate?

Business likes to view it as commitments. Developers like to view as guesses. The difference is profound.

A commitment

A commitment is something you must achieve. If you commit to getting something done by a certain date, then you simply have to get it done by that date.

Professionals don't make commitments unless they know they can achieve them. It's really as simple as that.

https://dev.to/yurishenrique/11-pressure-tips-from-the-clean-coder-40i1
Commitment is about certainty. Other people are going to accept your commitments and make plans based upon them. The cost of missing those commitments, to them, and your reputation, is enormous. Missing them is an act of dishonesty only slightly less onerous than an overt lie.

An estimate

An estimate is a guess. No commitment is implied. Missing an estimate is not in any way dishonorable. The reason we make estimates is because we don't know how long something will take.

Unfortunately, most software developers are terrible estimators, mainly because we don't understand the true nature of an estimate.

An estimate is not a number, but a distribution - a probability distribution.

Implied commitments

Professionals draw a clear distinction between estimates and commitments. They do not commit unless they know for certain they will succeed. They are careful no to make any implied commitments. They communicate the probability distribution of their estimates as clearly as possible so that managers can make appropriate plans.

PERT

in 1957, the Program Evaluation and Review Technique (PERT) was created to support the U.S. Navy Polaris submarine project. One of the elements of PERT is a scheme that provides a very simple and effective way to convert estimates into probability distributions suitable for managers.

When you estimate a task, you provide three numbers. This is called trivariate analysis.

• O: Optimistic Estimate. This number is wildly optimistic. You could only get the task done this quickly if everything went right. In order for the math to work, this number should have much less than a 1% chance of occurrence.

• N: Nominal Estimate: This is the estimate with the greatest chance of success.

• P: Pessimistic Estimate. This is wildly pessimistic. You should include everything except hurricanes, nuclear war, and other catastrophes. It also has much less than a 1% chance of success.

Given these 3 numbers, we can describe the probability solution as follows:

μ is the expected duration of the task.

δ is the standard variation of the probability distribution for the task. It's a measure of how uncertain the task is. When this number is large, the uncertainty is large too.

Imagine that you have these 3 tasks to do. It looks like the "beta" task has something that could possibly go wrong that would derail you significantly. But how long should you and your manager plan to complete all the 3 tasks?

You can combine all of them and come up with a probability distribution for the entire set of tasks.

The expected duration of that sequence is the sum of all expected durations. You will likely be done in about 14 days:
4.2 + 2.5 + 6.5.

The standard deviation of the sequence is the square root of the sum of the squares of the standard deviation of the tasks.

This tells your manager that your tasks will likely take 14 days, but could very well take 17 days (1δ) and could possibly even take 20 days (2δ). It could even take longer, but that's pretty unlikely.

The simple PERT scheme just shown is one reasonable way to help prevent setting optimistic expectations. Professionals are very careful to set reasonable expectations despite the pressure to try and to go fast.

Estimating tasks

The most important estimation resource you have is the people around you. They can see things that you don't. They can help you estimate your tasks more accurately than you can on your own.

Wideband Delphi

In the '70s, Barry Boehm introduced us to this technique. There have been many variations over the year, but they all have one thing in common: consensus.

A team of people assemble, discuss a task, estimate the task, and iterate the discussion and estimation until they reach an agreement.

The original approach involved several meetings and documents. I prefer simple low-overhead approaches such as the following.

Flying Fingers

Everybody sits around a table and starts a discussion about each task and what it involves, what might confound or complicate it, and how it might be implemented. Then the participants put their hands below the table and raise 0 to 5 fingers based on how long they estimate the task.

If everyone agrees, then they go on to the next task. Otherwise, they continue the discussion to determine why they disagree and repeat the process until they agree.

The scale of the estimated is decided on at the beginning of the meeting. It might be the number of days for a task or some more interesting scale such as "fingers times 3" ou "fingers squared".

Planning Poker

For each member, deal a hand of card with different numbers on them (0 through 5 work fine, Fibonacci series can also be used).

Pick a task and discuss it. At some point, the moderator asks everyone to pick a card. The members pull out a card that matches their estimate and hold it up with the back facing outward so that no one else can see. Then the moderator tells everyone to show their cards.

The rest is just like flying fingers.

Affinity Estimation

All the tasks are written onto cards, without any estimates showing. The team spread out the cards randomly on the table. They don't talk, they simply start sorting the cards relative to one another. Smaller tasks move to the left and the ones which take longer to the right.

Any team member can move any card at any time. Any card moved more than η times is set aside for discussion. Eventually, the silent peters out, and discussion can begin. Disagreements about the wondering are explored.

The next step is to draw lines between the cards that represent bucket sizes. These buckets might be days, weeks, or points. The Fibonacci sequence is traditional.

The Law of Large Numbers

Estimates are fraught with error. That's why they are called estimates. One way of managing errors is to take advantage of the Law of Large Numbers.

An implication of this law is that if you break up a large task into many smaller ones and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task.

Conclusion

Professionals know how to provide the business with practical estimates that the business can use for planning purposes. They don't make promises and commitments they cannot accomplish. They provide probabilistic estimates that describe the expected completion time and the likely variance.

They also work together with the other team members to achieve a consensus on the estimates.

Next article: #11 Pressure

Previous article: #9 Time Management (part 2)