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..
Top comments (10)
I disagree fully with the statement at the top of this article.
This is DEFINITELY....NOT A JOKE.
lol....seriously though, no one estimates projects properly...ever.
I usually pick a number, then add 20-30% just because i know things will happen we cannot control, and even then it comes down to scope creep, client arguing about the miniscule things that don't matter, or devs messing up on basic things, or a 3rd party service failing when you need it, or missing content, or some random device has issues that the client insists must be fixed even though it accounts for 0.0000% of their traffic.
Yea...not a joke at all, but still hilarious.
I even have a science-based approach for you. It will blow your mind how it is simple. Look at this:
D - it is your estimation, it is straightforward diameter. But **real estimation **is the half circle, because it always not straightforward.
I'd rephrase this as follows:
Yet, when the deadline day arrives, you're either ahead or behind the schedule.
and I mean, sure! It's an estimation.
On the other hand, if you're drowning on an ocean of bugs you probably did not account for testing in your schedule so it's probably a bad decision (mainly on the technical team/leadership) and if there have been scope changes probably it's due to a bad management (business side) that needs to be re-estimated and therefore the project deadline re-scheduled.
It doesn't matter which technique you follow to estimate as long as it works for you in your context.
What I want you to keep as key take aways are the following sentences:
1- [Business and techies] An estimation is not an exact amount of time units in any way shape or form, it needs to be re-adjusted (usually every 2 to 3 weeks it doesn't matter if you're working in sprints or not).
2- [Business] Changes can happen, it's up to you to prioritise them and to assess that what's planned makes sense for a given version (PoC, MVP, V1, V2...), don't try to fit in all features from a brainstorming in version 1, let's schedule properly and change the direction of the project as little as possible!
3- [Techies] Do not avoid testing, docs, configuring the pipelines to enforce a minimum of quality and so on. Document and keep ADRs! Remember that 50% of the job is to make it work, the other 50% is leaving the code tested and maintainable.
And finally the most important one: Underpromise + Overdeliver is always superior to overpromise + underdeliver.
Cheers! 😁
Hello 0ro,
I think there is a method to estimate, and this method can be used (and is used) for many teams, but, to get to this point, you will need: a team with more than 3 months working together, have ways to deliver to production even the feature is not finished (eg. only the API and the front goes after), the product manager stops to thin that only user stories "delivery value", and so on (this list can reach the sky, depends on your team and culture).
Actually, we have some methods such as Monte Carlo and Upper and Lower limits.
For both methods, they need historical data from a consistent team.
Oh, it is interesting, thank you for sharing
Estimating software development time is indeed a challenge, and your insights resonate with the common struggles in the industry. It's an intricate dance between optimism and uncertainty. Sharing experiences and learning from one another's approaches, like the ones you've outlined, can hopefully bring us closer to mastering the elusive art of estimating software development time.
let's discuss how it usually happens in your life. The real life examples are always the best
Don't estimate. Total waste of time
Would you then do something like Kanban? So you still have a board with tasks but without the time indication.
And on that note, when you have a customer most of them want to get some time indication.
I keep saying: "When you can estimate accurately you're not automating enough."