Estimations

The only way to get estimations right is to not do them. Estimations in software can not be accurate. Unless you keep a buffer of +-100% there is little chance to get it right. While scoping and planning a year or a quarter, estimations are OK at a big level. Do not do any other low-level estimations. It is a waste of time. Do not play planning poker. You will not get them right. Either you will cut corners and ship poor quality or you will crunch to prove that your estimations were correct. Managers should stop asking for them. Estimating software is nearly impossible because of the number of variables involved. You can do it if you have made the exact same thing before. A carpenter can tell you when the table would get finished because he has made the same thing, with similar tools and products over and over again for decades. In software, you can’t because if you were to make the same thing unlike physical things you would just use the existing software. Again, remnants of the industrial era. Software is not produced on assembly lines.

I dream of a world where people don’t ask for estimations and deadlines. Deadlines can’t be real in software. Most deadlines aren’t deadlines because a lot of them are breached and no one dies. We use the word too frequently and too leniently. I am not sure why the woke folk hasn’t already started a movement against it. Deadline is a line around a prison which if crossed by a prisoner required the guard to shoot them. Does that make software engineers prisoners? That is true to some extent for modern-day work but yeah, have some respect. Anyways, that was a rant but most deadlines are not urgent.

When everything is urgent then nothing is.

If you decide to make a feature and someone estimated it would take 10 days and the deadline was set 15 days from then. Nothing would happen if it wasn’t shipped. There are certain forms of deadlines that are actually true and should be respected. That could be like an annual audit that has to happen on a certain date and you need to ship something to clear it. Most of those can be very easily planned. Don't put yourself or your team in a tight position lest they deliver shabby software. This is more for managers than engineers but realizing this is important to be free from prison someday.

Story pointing is a second-order effect of engineering managers trying to solve time-based estimations. Equally futile. Most people, in their heads if not openly, will anyways map story points to time in some sense and add some factor of uncertainty. Those who fix 1 story point to a simple bug fix in the app would still measure that it took them 2 hours to fix this bug so 1 story point is 2 hours of work. Subconsciously, the estimations part still lurks around in one form or another. Skip story pointing. Skip scrum.

When you press engineers on estimations, they are likely to cut corners and deliver poor quality. Instead, scope down things. Ship in iterations. Iterations that are so small that you wouldn’t bother asking for estimation and if it goes wrong, the least amount of time is wasted. Remember, we need to avoid heroic efforts. Many managers know estimations are hardly on point. Many managers just want estimations to hold people accountable instead of doing the real work. Real work is to scope down things. To fire people who cheat. To enable people. To come up with a good plan for a complex idea. To have the flexibility to adapt when things go south. To save a project from risk. To inject risk sometimes.

Nonetheless, your manager might want you to do estimations if you are not lucky enough to be in a company that doesn’t. You can find unlimited and near-useless literature on estimating software online. Here are a few futile tips from me.

1. Try to make an accurate estimation then 2x the time.
2. Giving estimates to line managers and the CEO is different. CEOs are interested in when it will be live.
3. Under commit, over deliver.
4. Revisit your estimations after delivery and see how accurate you were. Where you went wrong and what can be improved.
5. If you need time to tell how much time it would take, buy that time. Tell ‘em you will be back with estimates.
6. If requirements change, escalate that if it will take more time.
7. If you work 8 hours a day, consider a day’s work to be 6 hours. If something will take 16 hours that means you will open it for review in three days, not two.
8. When development is done a PR is reviewed, QAed, and possibly rejected. Once it's approved it will be merged and released with the next release. Getting 10 minutes of work to production can take 1 to 15 days depending on the size of the company.
9. If there are unknowns, a lot of communications, external teams, and third-party integrations involved, keep a buffer.
10. Breaking the task down helps. Imagine all the flows that you are going to program.

However, it will still take a decade of hit and trial before you could estimate with reasonable accuracy.