This is a pretty common point of view of novice developers.
They have no idea how to do accurate estimations other than guessing, or giving in to a management target date and not understanding the difference between targets, estimates and commitments.
The next step is nearly always, rather than learn to be a good estimator, to declare that if they don't understand how to do something, then no one does.
The idea that if you haven't bothered to learn how to do something, no one has, is an amazing act of hubris and is characteristic of a certain sort of person who often causes more damage on a project than contributions.
The solution is to either stop giving bad estimates based on nothing, or to learn to do it properly. Giving bad estimates because you don't know how to estimate is a form of engineering malpractice. Declaring that because you are an incompetent estimator and have not bothered to learn how to do it that therefore no one else can estimate either is pure immaturity. It is similar to the principle of object permanence where in Piaget's theory of cognitive development he notes that where infants from birth to around age two don't believe a ball exists once it leaves their field of vision.
It's not just a point of view, it's backed up by studies. Did you actually read the article? Plenty of grizzled veterans back this up anecdotally also.
I agree that studies show that ad hoc, "straight from the hip", and "wild assed guessing" methods don't work to produce accurate estimates.
Not just "plenty of grizzled veterans" report that they don't know how to estimate, but the vast majority of the industry is incompetent and ignorant on estimation, a sign of the deep seated unprofessionalism of the industry.
Neither of these things change the fact that lots of us are able to do accurate estimation and the methods for doing so are well known and have been for decades.
You've twice now stated that you're able to do accurate estimation and that "methods for doing so are well known".
Yet failed to cite any sources to back up this claim. My experience among novice, intermediate and experienced developers has been that while order-of-magnitude estimation is often acheivable. Truly accurate estimation is not. Software is far too 'soft' to fit our expectations every time we try and build something.
Well, just from skimming some of the pages on Amazon, it seems to back up a lot of the original article's points.
eg. on p25 McConnell lists project outcomes by project size:
1000 LOC -> 81% on time, 4% late, 2% cancelled
10,000,000 LOC -> 14% on time, 21% late, 65% cancelled
Smaller project, better estimates.
Also notice that McConnell uses terms like "Approved Product Definition" and "Requirements Complete". It's a rare project, particularly in the consulting world, that can nail down requirements to the degree that you get really accurate estimates. For packaged software products it's doable, for other things, not so much.
Yes, I can and do estimate accurately, as can many others. Estimation is a basic engineering skill.
McConnell's book, linked to by the other contributor, is a sensible introduction to doing reasonably accurate estimates for projects that aren't incredibly huge (10MLOC+). Very accurate estimates (within 5-10%) and estimates of incredibly huge projects are also possible but require specialist estimators with extensive training and practice.
They have no idea how to do accurate estimations other than guessing, or giving in to a management target date and not understanding the difference between targets, estimates and commitments.
The next step is nearly always, rather than learn to be a good estimator, to declare that if they don't understand how to do something, then no one does.
The idea that if you haven't bothered to learn how to do something, no one has, is an amazing act of hubris and is characteristic of a certain sort of person who often causes more damage on a project than contributions.
The solution is to either stop giving bad estimates based on nothing, or to learn to do it properly. Giving bad estimates because you don't know how to estimate is a form of engineering malpractice. Declaring that because you are an incompetent estimator and have not bothered to learn how to do it that therefore no one else can estimate either is pure immaturity. It is similar to the principle of object permanence where in Piaget's theory of cognitive development he notes that where infants from birth to around age two don't believe a ball exists once it leaves their field of vision.