The subtext of the article seems basically to be that the author does not want to estimate tasks. Which is nice when someone else pays. It is less nice when you have to pay however.
Despite what they have told you, that's never a real issue. If the project is divided into small tasks, if progress is not being made on these tasks, the management always has the right to steer the direction of the project or to reassign the staff tasked to it. This is how management can continue to control the expenses. As for estimates, even an AI can give those, probably better than what a human can, and without any stress.
So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
How often carpenter needs to study while constructing what is the correct method to build to wall, and while doing that, try to find out whether the client wanted the wall or a floor, or even both of them?
Try to give any proper estimations before actually starting that kind of project, when the scope is not known and there is no buy-in to spend half of the time just to plan all little details.
It is not just "give an estimation", but a whole procedure to complete.
If you don't know what you are going to do, of course you can't estimate. Then you timebox a research phase and let that outcome be the basis for the estimate.
That's not a fair comparison at all. A bathroom or kitchen is something they have worked on a hundred or more times before, with little variation. In contrast, software is almost always original. If you ask me to implement the same software a hundred times with minor variations, of course I can give you good estimates without stress.
THIS exactly is what Software “professionals” have amazingly successfully been able to convince everyone. That somehow what we do is “special” and we just cannot possible tell you how long XYZ is going to take…
Software “is almost always original” is the same argument as if an incompetent carpetner would say “sorry, no two kitchens are alike and while I use same sh*t to build them I have never built yours exactly and hence I’ll send you the bill when I am done.”
Some changes to software are simple, but even simple changes can at times have unintended consequences, triggering the need for substantial refactoring or abstraction or performance tuning. It is all case by case, and it's not fully possible to fully predict what's needed ahead of time.
> So if you would hire someone to redo your bathroom or kitchen, you would hire them without an estimate and quote as long as they divide the project into small tasks?
I love these general contractor analogies because it tells me that these people don't understand software engineering.
Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation.
It is up to management and business to decide if they are skilled and willing to accept the nature of software engineering.
"Here's an answer for you: the vast majority of software engineering is less like repetitive contracting and more like unpredictable lab experimentation."
I kind of doubt this, but have no numbers to back me up. Do you have any numbers or actual facts to support that statement?
> I kind of doubt this, but have no numbers to back me up. Do you have any numbers or actual facts to support that statement?
I don't have a measure of it but Google and Facebook did - and they found that estimation is BS and never achieved. They never institute scrum/kanban/agile nonsense as a result.
Without data, the constant and persistent failure to estimate projects - over 40 years - should be good enough data.
Scrum only gives an estimate for the next sprint and maybe the sprint after. In many cases you're talking about 4 weeks horizon at most. I would not be happy if a contractor told me they can only estimate the work on the kitchen, but not the bathroom.
I'm a big fan of estimating beyond two sprints, because the business' horizon is often a quarter or beyond that. Obviously initial estimates are very rough and uncertain, which you can show by using bandwidths. Then just keep updating the estimate depending on the work done, the requirements getting clearer and the technical challenges becoming known. It's a great tool to steer the scope conversation.
It also allows the engineering effort to be without day-to-day estimations. Just pick up the work that is most important and trust that people will put in their best effort.
If I'm hiring them without telling them in detail what I'd like them to do, yes. Try calling a contractor and asking "how much to redo my kitchen?"
In the real world I can demand an estimate because I'm giving them an architect's plan showing every dimension and material and the location of every counter, fitting, and electrical outlet.
