All to often I hear this phrase during an estimation meeting:

I think it’s about 20 hours, but let’s say 24 to fudge it a little…

Estimating this way brings a false sense of security that you have allotted more time than needed. Probably more correct, that small amount of extra hours placed on the estimation only shortened the gap between an optimistic timeline and reality. So why is this a poor estimation?

Single Point Estimations Stink

I have said this many times, and I will say it again – single point estimations stink. Sure you can tell the difference between a 1 hour task and a 2 hour task, but can you really tell the difference between a 20 hour task and a 24 hour task. Probably not.

Solution: Learn to break down your estimations in smaller pieces. For larger tasks, ensure you are estimating in ranges or with a process that implicitly includes a fudge factor such as Planning Poker (Point Estimation).

Fudge Factor Is Not Based On Fact

In the example above, where did the extra 4 hours come from? The majority of the time it is a gut feeling, but why can’t it be fact?

Solution: Keep track of your estimations and actual development time – you can’t fix what you can’t measure. Next, measure and understand your estimation variances. This will give you 2 action plans:

1. You can correctly pad your estimates with actual mathematical variance to improve estimation confidence.
2. You can now understand and measure estimation improvement (for example, 20% variance improved to 17% variance).

Presents 100% Confidence

Even with all your body language, chair shifting, ummming, and pre-warnings; most managers will take exactly what you say for gospel. That is because when you estimate in this fashion, you are presenting the posture to your manager, “I’m the expert and I know it will be right around 20 hours”.

Solution: Learn how to present your non-confidence in a manner that does not put the project responsibility on your shoulders. Learn to speak in estimation confidence levels that allows you to ask your manager, “I am 90% confident I can get it done in 200 hours, but if I say 100 hours I am only 30% confident. How much risk are YOU willing to take on?”

Learning to sandbag your estimates is not about tossing a couple of extra hours on a task. It is about truly understanding the things you can know, and articulating risk and concern about the things you can’t know. This way you and your manager can pad those estimations together and on the same page.

I am not a wise man. At times, I even lack basic intelligence. However as of late, I have become aware one basic principle I practice has always lead me to great success – the wisdom of pessimistic thinking.

Some view pessimists as concentrating on the negatives of life. I view pessimism as the ability for positive improvement.

Pessimism reminds us that because the glass is half empty, in turn, it removes our ego. Lack of ego instills humility. Humility leads to humbleness. Humbleness gives us the mental and spiritual freedom to explore improvement.

With the help of pessimism, becoming a more successful developer, person, and life long learner is much easier.

Technical debt always has the same 3 questions:

1. How much is the technical debt really costing us?
2. How much will it cost to pay down this debt?
3. How will I know it is time to pay down this debt?

If developers can not provide the evidence of business value for paying off technical debt (by answering all of these questions), the majority of the time project stakeholders will defer paying off technical debt.

So how does one answer all of these questions in a way that can be understood by a project stakeholder?

1. Keep track of time spent working around the debt

First off, is it really debt? Sure it might suck working with it…sure it might not be the new cool thing…but is it really debt? Is it really causing you slow down and pain? It is not debt if the pain is not measurable, and you can’t insinuate potential improvement if you neglected to measure it.

Measuring can be as simple as keeping a log of time spent fixing bugs in a particular area, or logging perceived extra time spent working around a crappy 3rd party library. In short, find a way to measure your pain in a quantifiable manner that can be perceived by anyone as money and time wasted.

Answers the question: “How much is the technical debt really costing us?”

2. Estimate how much it will take to pay off the debt

Estimating how much time and effort it will take to pay off the debt is perhaps the easiest of the questions to answer. Simply put together your battle plan for the refactor and estimate it out. Feathers in Working Effectively with Legacy Code might even suggest actually doing the refactor 70% through and then throw it away just to truly understand the size and steps to support the change for real.

Answers the question: “How much will it cost to pay down this debt?”

3. Determine a tipping point of when it makes sense to refinance (pay it off)

Now that we have measured both the cost of the debt (debt interest) and the cost of the refactor (debt refinance costs), we can frame in the answer to if it makes sense to eliminate the debt by using a house mortgage analogy.

When refinancing your house mortgage there is only one question, “Am I going to stay in the house long enough to see a positive return on the reduction of my interest over the cost of refinancing?”.

Simply put, if it costs $3,000 to refinance and it saves you $500 a month, will you be staying in that house for at least another 6 months in order to see a return on investment?

The exact same goes for software: if the data access layer is causing us 60 hours a month in lost time, and it will cost 300 hours to refactor, does it make sense to pay this off right now knowing we will see a return in productivity in 5 months?

Answers the question: “How will I know it is time to pay down this debt?”

To summarize, presenting the short and long term project costs of technical debt is as easy as putting it in a simple house mortgage analogy. However, remember that ultimately it is the stakeholder’s decision of how they wish to carry their technical debt. Perhaps it makes more business sense to spend more money now than save money later or they emotionally are just not ready to refinance. Make your case, show the business value, and the majority of the time you will get that signature for the refactor.