Disclaimer. This article is a joke. Only me and God know how to estimate software projects. And I am not sure about God.
The Great Unknown
Let’s imagine you are a Tech Lead, and recently you were asked to estimate a software project. You were given a list of features and asked to estimate how long it would take to implement each feature and the entire project. You were given a couple of days for it…
A couple of days! Really? Estimate the entire project. It cannot be enough. Even for the best of us. Even if you have done it before many times. But how much time do you need? A week? A month? It always will not be precise anyway. So, maybe a couple of days is a good option, at least you will not waste a lot of time on it.
And be sure, your managers will tell you, “Don’t worry, no need to dive deep into details, we just need a rough estimate and nothing more, you will manage to do it, come on buddy”.
And of course, they lie. They will use your estimation to plan the project, to plan the budget, to plan the team, to plan the deadlines, to plan the marketing, to plan the sales, and to plan the future of the company. And they will use it to blame you later when you will not be able to deliver the project on time.
The Burden of Responsibility
The customer needs to know how much it will cost to implement the project. It is a good reason, right? They need to prepare money for their amazing start-up, or maybe find investors, who will pay for it. And the amount of money they will ask depends on you. So, it is a big responsibility, including the fact that only you know how you came up with the numbers.
Usually, customers ask for estimates from several companies, and then they will choose someone. It is not always the cheapest one, there are a lot of factors that influence the decision, but the price is one of the most important factors. And here is the catch:
On your side, if you will give a price that is too high, for the customer, you will usually lose because the project is not on you. If you give a price that is too low, you will usually win the battlefield, but you will lose this war later, when you are working on the project every night.
On the customer side, if you provide them with a budget that is too low, they will not be able to implement the project, and they will lose. If you provide them with a budget that is too high, they will lose, because they will not be able to find investors.
The Illusion of Technique
So, how to estimate the project? There are a lot of techniques and maybe you know some of them. There are countless methods: expert judgment, story points, bottom-up estimate, three-point estimating – you name it. They all promise to unveil the magic number. But guess what? None of them have the Midas touch.
You might meticulously break down the project into user stories, assign story points, and create impressive Gantt charts. You might consult with your team and reach a consensus. You might even throw in some past project data for good measure. Yet, when the deadline day arrives, you’re either ahead of schedule with nothing left to do or drowning in an ocean of bugs and scope changes.
Conclusion
In the wild world of software project estimation, one thing is clear: it’s an art, not a science. It’s a complex dance of uncertainty, expectations, and a dash of wishful thinking. So, next time you’re asked to estimate a software project, remember to take it all with a grain of humor and a pinch of humility. After all, in the ever-evolving realm of software development, the only constant is the unpredictability of estimation..
