We can only estimate what we understand

When going on a road trip, we don’t estimate how long we will be on the road until we know to where we are going. It may seem obvious on the physical world, but software engineering is abstract and has many moving parts; it is not always that easy to realise that we are making assumptions that won’t hold true.

When estimating, we are likely to get better results if we don’t skip steps and actually spend enough time to understand exactly what needs to be built and how we intend to do so.

Any time spent on something that is actually not what we want or need to build is misused time, as we are going in the wrong direction. We cannot get to the how before the what. We must have a clear picture of the expected outcome. We must be able to explain both in simple and in complex terms what the end result will be.

Once we know where we stand and where we want to go, we can begin defining the better route; we can define the how. On a road trip, there are usually many ways to from Point A to Point B. In software engineering, where, differently from the physical world, we can abstract things however we like, there are always many ways to achieve the same result. That is both a challenge and an opportunity: we can devise multiple solutions, each with their pros and cons, and pick the one that better suits our needs and available resources.