What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates.
Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
> What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates.
Obviously, planning is critical. Planning means resource allocation. How is this not a critical aspect of any project?
The mistake you're making is presuming that if estimates are not crisp then they have no value.
> Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required, which translates to not even knowing how many people should be working on a simple task.
The problem you're failing to address is limited information, and specifically limited context from developers and emerging requirements. Projects have been adjusting to this for decades. Agile developed concepts such as sprints and spikes for this very reason. It's not only about changes in requirements. It's mainly about gathering info and updating projects based on that.
Considering it very often fails even for successful projects, obviously, it is not.
> This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required
Your line of reasoning is detached from reality. The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
Development is what makes a project successful; planning is what makes a project late.
> Considering it very often fails even for successful projects, obviously, it is not.
This is not a relevant strawman (if it fails for some, it works for none?). Working without a plan isn't how humans work. You want to argue about scale, that's fine, but far from absolute.
> > This belief is detached from reality. Failing to provide estimates means a failure to scope how much work is required
> Your line of reasoning is detached from reality.
You provided nothing to indicate that the reasoning is detached from reality.
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
Any estimation I make for myself is not subject to it. My cofounders are not subject to some project leader who is trying to sabotage us. Simply put, this is another strawman to abdicate explaining the pros and cons (due to a lack opinion or thought?). It is not compelling.
> This is not a relevant strawman (if it fails for some, it works for none?). Working without a plan isn't how humans work. You want to argue about scale, that's fine, but far from absolute.
OP clearly fails to understand that the role of a project manager is to navigate ambiguity and uncertainty to deliver results in spite of them, and project managers are fully aware there is no such thing as crisp estimates and absolute certainties. Therefore OP puts strawmen regarding absurd notions of rigour that no one in the world adheres to.
I mean, hasn't OP noticed Project Manager's don't carry around stopwatches?
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required, still they never get the right answer until the project is completed.
They don't know the true answer until the project is complete.
If my boss asks me how much time I need to integrate with some client system and I say I estimate one week, then if it's ready after four weeks that might be just fine for my boss.
My boss knows that there are factors that can affect the delivery of a project. What he almost always wants to know is are we talking days, weeks, months or years?
> Development is what makes a project successful; planning is what makes a project late.
So when you travel to new places, you just head in the compass direction? No looking at maps or similar?
> Considering it very often fails even for successful projects, obviously, it is not.
You are using a very personal and peculiar definition of failure, which is not shared by anyone else.
Back in the real world, companies hire project managers and put them in charge of projects without any concern or regret regarding the methodology. Do you think the whole world is wrong and you're the only one getting it right?
> Your line of reasoning is detached from reality.
Please explain exactly why you think scoping efforts have no relation with estimates.
> The real world is full of project leader who do everything in their power to know as soon as possible how much work and time are required,
Yes, it's their job. What exactly do you struggle to understand?
> still they never get the right answer until the project is completed.
Yes, what about it? Exactly what do you have trouble understanding?
Experienced people develop different things than inexperienced people. Planning could simply involving experienced people to ensure the right thing is being built.
I think the fundamental misunderstanding is that we aren’t building a product. We are doing research and development. We are figuring out how to build something novel, otherwise the customer could just go out and buy it already. Once we’re done with discovery, the computer builds it. So, the customer is like any other who is paying for research and development. It’s not a blank check, but they should go into it without the expectation that something new will be discovered on some accurate schedule.
> We are figuring out how to build something novel
Is it possible to estimate the duration of a process that has never before occurred (e.g. the construction of something novel) with any expectation of accuracy?
This is hubris of the field of software engineering. The no-code market and the existence of tools as old as MS Access prove that there are software projects for which a better analogy is not R&D, but construction.
I do note that construction projects are also not good at estimating, but it's folly to suggest that at some level we are not _manufacturing_ rather than _developing_ a widget.
Construction is a bespoke non-factory manufacturing process. If you extend the metaphor:
Estimating large projects is a big construction projects. Those tend to be large buildings and relatively on schedule. Estimating small projects with small teams is bespoke. And more likely to go off schedule when the plumbers can't time well with the electrical services, i.e, you have a dependency on another teams API or something, similarly to how software struggles in small team open ended scope projects with unknowns. But a tightly scoped single-trade software project won't struggle just like construction.
In end, I agree with you that construction is a decent metaphor. But construction is very far from manufacturing a widget, as it's a bespoke manufacturing process with ample site specific constraints
If we're going to talk about construction as the metaphor, then it's done by the computer (e.g. compilation), and it's so cheap or trivial on many projects that developers will ask the computer to build the software hundreds or thousands a times a day (e.g. via test-driven development). In this metaphor, I think the developer would be more akin to a designer or architect, but where the building in question is at least partially novel. If it's not novel in product, people, process, etc., then the client could just go out and buy or use one that has already been produced. The developer wouldn't be necessary.
All the successful projects I've participated in could have been managed with this simple sentence:
"After some indulging in alcoholic beverages, we have signed a contract for <vaguely specified features> to be shipped on <date out of someone's hat>: please, do your best!"
And the outcome would have been even better if we hadn't waisted so much time in preparing detailed estimations and later inventing a justification about why those estimations were not precisely met.
You estimate as a forcing function to know what you are trying to accomplish. The nuances of scope, how to do it and tradeoffs get discussed.
I think estimates are a problem where you have say 10 estimates, you add then up to 47 days, divide by 3 people, call it 16 days… ah about 3 weeks that’ll be done. That is dumb!
Planning and estimating are orthogonal. I don't think inaccurate estimates should prevent you from anticipating the future.
> have to learn to work without estimations.
A closely related, but different time management tool is a budget. Consider the same website but made in: 3 hours, 3 weeks, or 3 years. The methodology and tradeoffs the engineer approaches each of those projects is very different and needs to be known up front.
Part of the goal of estimation should be to create a budget for various key areas of the project, not guess how long it will take to fix 5 critical system bugs.
That's all well and good in a world that's pure software (and that does happen in those environments). It's not realistic in a world with lead times on physical items that are at least 1 year. For example, if you want to set up a high volume manufacturing line for a new product that takes a lot of planning in advance. You need to spend 10s to 100s of millions of dollars on a contract and schedule with the manufacturer and you need to be able to have SOME indication of where in that process firmware might be released (or more realistically - given the timescale, what scope of software is possible).
I have been told that "as long as the firmware update on the device works, the rest of the firmware doesn't have to completely work until devices start getting shipped and installed." Yes, people are playing very dangerous games out there. :(
Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.