Unfortunately it’s often true. People keep saying: "but didn’t you initially say X?"
"Sure I did, but I have new knowledge" won't always work.
A nasty side-effect is that people who are aware of this shy away from giving you numbers.
So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good.
Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes.
Also, just made meetings a lot more fun.
Due to small side projects like the painting of the Sistine Chapel ceiling it took around 40.
Failure to meet the deadline informed by the estimate meant that the scale of the project was massively reduced because: Pope Julius II had died prior to completion, there were changes requested by the customer (both Julius and his heirs), supply chain issues, contract renegotiations, labor disputes, shortages of qualified workers, and money running out due to the long duration of the project.
So, since 1505 at least?
The funny thing is that the pope isn't even interred there.
With constant feedback, the whole team is participating in the emergent complexity, instead of being passive and just annoying you with "is it done yet"?
I've found that most management just want to be involved in the process and have definite times set for updates and can handle timeline changes as long as information is coming at regular intervals.
So: 2 hours -> 4 days, 1 week -> 2 months, etc.
(I'm not sure where this turned up, but it's a long time ago, going on three decades.)
The other option is to carefully track tasks, relevant dimensions, estimates, and actual performance, and see if there's any prediction modelling which can be derived from that. Problem is that this a classic instance of modelling in which the model itself affects the domain (as with economics and sociology, contrasted with astronomy and meterology where this isn't the case), such that estimates incorporating past performance data will incorporate the fact that the prediction model is being used.
I've certainly seen some environments — plural — where a task that should take 1 hour actually takes 2 days, and one that should take 2 days takes 4 weeks.
You should not provide an estimate for "feature X implemented", but rather for "feature X engine". If you discover additional work to be done, then you need to add "existing code refactor", "feature X+Y integration", etc. as discovered milestones.
Unfortunately, you need that nomenclature and understanding to go up the chain for this to work. If someone turns your "feature X engine" milestone into "feature X complete" with the same estimate, you are screwed.
------
There is a related problem that I've seen in my career: leadership thinks that deadlines are "motivating".
These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster".
I was once in a leadership meeting, where the other participants forgot that I, lowly engineer, was invited to this meeting. Someone asked if we should accept that deadline X was very unlikely to be met, and substitute a more realistic deadline. To which the senior PM responded that "we never move deadlines! Engineering will just take any time given to them!"
Engineering, in that case, gave the time back when I left that team.
Conversely, if you're trying to launch a space probe and the planets are no longer in the right positions for the required gravity assist, your spacecraft will not get where it needs to go. Or if you're a little $100M/yr toolmaker, and Ford asks you for a die for the 2026 F150 production line, to be delivered by March, and the contract states you owe a $20,000 per MINUTE penalty if you're late...you don't wait until February to say something surprising happened and it's not going to be ready. You don't sign on that dotted line unless you know for certain that you can do it.
Ford or NASA won't bat an eye when you tell them that a quote is going to cost $XX,XXX. They won't be surprised when they give you an ECO and you say that it's going to take 3 weeks and $8,000 to deliver a part that everyone knows you can probably make by hand in 30 minutes, they know that you're hedging against those deadlines, and pricing in the acceptance phase and inspection phase and contingency plans and everything else that makes their deadline-heavy industry function.
But if you tell someone at OP's modernization group that due to incomplete information you think that the 30-minute task to change the text of that button will take "no more than 3 weeks and $8,000" they'll laugh you out the door. Optimistic estimates get rewarded, pessimistic estimates get discouraged, accurate estimates are irrelevant, and in the end you're constantly behind schedule and no one's really surprised.
I can’t MVP my way to a simulation physics engine, when each feature or partial feature requires weeks of planning, testing, iterating and tweaking- privately, before anything can be delivered to be used.
Feedback, implies a working widget.
That happens all the time with insurance. I'm surprised at the confident tone in "reality does not operate like this". Not just car/home insurance either...health insurance also. They do often negotiate to a reasonable place, but not always.
I kept that as a practice when I did freelancing work, always giving my estimates as a range rather than a single number. It would be nice if agile(ish) practices incorporated this in the estimation process.
⸻
1. Technically, my second job since I had a short temp job doing some cataloging work at a local used bookstore between leaving school and starting at that company.
Well yeah, because there's not an inherent power imbalance like there is in employment.
Part of this imbalance results in the ability for managers to employ Taylorization upon their directs. The majority of the time Taylorization hinders workers but management loves it because they can have more control in outcomes. What ends up happening though, is that an shadow work plan ends up getting established that management has less control over unless they want to drive out top talent by employing technocratic solutions to social problems.
In the latter (also called "preferred rates" for auto insurance) there's a blanket agreement that all work of a certain type is to be billed at a fixed, negotiated rate.
That is VERY different from a binding estimate, which typically means a one-off estimate for a specific job where the estimator takes the risk and promises to complete the work at the rate, even if it's much more complicated than they bargained for.
I eventually learned, when asked for a "quick" estimate, I would give something drastically longer than I knew would be accepted. I said "But I can give you a better estimate if you give me a few days to do a better plan." This always got me the extra time to provide an estimate.
# You need to align the rest of your team on things: maybe you have marketing tied to real world events, you're hiring and training to a sales cycle. If you do it wrong you waste money
# You need to fight scope creep which happens with unbounded timelines
# You need to fight a minimal product that's not viable because it isn't done enough for your market
and more. The ideal is for the decision maker to constantly have full information on progress and make instantaneous minute adjustments to keep things going at full steam. But there's no way to have full information and there's no way to make instantaneous minute adjustments if you're not a one-man shop. So everything else comes from the organizational effort of trying to work with that.
I'm skeptical that most of the clients I work with would go for something like this. Generally my projects are in the $7k-20k USD range (though with some clients the total spend is much greater with additional phases of work...)
Also, what do you mean "you just don't guarantee timeline"? Why not?
estimates = contract amount = project budget ...
it is hard for a project team to negotiate later
often the estimates need to be competitive or bottom most for you to win the contract
no one acknowledges the unknown and risks at the beginning of the project
writing down more than 4-5 risks along with the bid amount is taken as a sign of a team that will not be easy to work with and fight over every bullet point whether something is in scope or a change request
and often the one who estimates and wins the project may not be on the actual project team with delivery accountability
- Realistic e.g. tech managers and people who favors agile/lean/XP/etc.
- Optimistic e.g. sales managers and people who want to promote.
- Pessimistic e.g. risk managers and people who need firm deadlines.
- Equilabristic e.g. project managers and people doing critical chain
The abbreviation is ROPE, and it turns out to work really well in practice to cover all four bases. My notes are below. Constructive criticism welcome.
Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who do, they will see right through this.
For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.
I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end team, and the backend team, and the QA team, all padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines".
Then the Project managers added those all ups and added 150 - 200%. Then the account managers and sales teams added 150 - 200% to the estimated costs before adding margins and setting prices.
Which ended up in literally around 1 million dollars a month to maintain a website which could _easily_ have been handled by a full time team of 8 or 10 decent web and full stack devs. Hell, apart from the 24x7 support requirement, I reckon I know a few great Rails or Django devs who could have done all the work on their own, perhaps with a part time of contracted graphic designer.
That all lasted a handful of years, until the client worked out what was going on, and my company management flew the whole thing into the mountain, with ~100 people losing their jobs and their owed entitlements (I was out about $26K that day.)
The solution is simple: get better at estimating.
Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable.
It's a skill issue.
I think a manager who doesn't know the difference between and estimate and a deadline is one who "[doesn't] know what the fuck is going on," and that's the kind of manager the GP uses this strategy with.
Anchoring effect is something related but subltley different: https://en.m.wikipedia.org/wiki/Anchoring_effect
In this case don't estimate the time to build a poorly defined $something - invert the problem to estimate the value of $somethig.
It's amazing how many of those managers asking for estimates push back when they have to put one out. With all the same reasoning that engineers have when estimating.
A good manager should start with the Value first and allocate time-budget that makes that Value payoff.
Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or unrecognized systemic factor
I've seen projects run in parallel like this for 10+ years.
"What's your estimate?" "I'm not sure." "Just ballpark it."
"Well, when would you want it by?"
This is the trap that new managers will fall into every time. If they give you an answer? Bingo. You give them "The Wince":
You suck air between your teeth, and with a frown say, "Oh, that's completely unrealistic. Where in the world did you get that number from??" Then you provide a number that's many multiples higher, or offer a reduced amount of work: "Oh, gosh. We'd only be able to get X feature done in that amount of time, and only if we got lucky and cut feature Y from the other project."
Regardless, whatever you do, don't be the first to provide a number. It takes a little bit to get the feel for it, like poker or buying a car.
Time is money, even in a big corporation. Treat it as such: It's a zero sum game.
That sounded insane to me… nearly two decades later, with plenty of remote freelance and full time onsite team experience under my belt… and I fully agree. It’s always going to take significantly longer, and if you pretend it’s not, it’s going to come down on your head, like it or not. Always better to underpromise and overdeliver than the other way around.
One can give very accurate estimates of how long it takes to build a brick wall because building brick walls takes time and labor. You can make highly accurate estimates of how long it takes based on how long it has taken to do the exact same task in the past.
But suppose I laid one brick and then could copy-paste it, then copy-paste that into four bricks, then eight, until I have a wall. Then I can copy-paste the entire wall. Once I have a building I can copy-paste the entire building in five seconds.
The ability to copy and paste an entire building is very valuable but how long does it take to create that copyable template? No one knows because it has never been done before.
Giving an "if I had nothing else going on" estimate can be a big trap to fall into - they will only see the number and judge your performance based on that. This dovetails into the problem that untracked but still important work being thankless in low trust environments - not all work can ever be tracked, or else the time to track that work would take as long as doing the work. Examples: literally any emotional labor, time to monitor, time to train, time to document when its not explicitly required, time to solve little problems.
In the environment where none of this counts because its not quantifiable, everyone with knowledge makes themselves into a silo in order to protect perceptions of their performance, and everyone else suffers. I'll go even a little further to say that companies that attempt to have no untracked work are by nature far more sociopathic - thus far there's basically no consequences for sociopathic organizations but I hope one day there will be.
What makes software hard to estimate is not so much the work, but how much requirements, priorities and resourcing change on the fly. I've worked in places that did quite strict scrum: once the sprint was planned and agreed to, we pushed back hard on our business area if they wanted to change anything. For practical reasons we didn't outright ban it, but for example, if they wanted something new done "right now" they had to choose something of roughly the same scope to be removed. If they couldn't do that, we'd cancel and re-plan the sprint. They hated having to make that choice, so most things just ended up at the top of the backlog for the next sprint.
The other part was our own management wanting to take people out of the team mid-sprint to work on something else. We never said no, but did say "this means we have to cancel and re-plan the sprint (and tell our business area)".
Basically, we made the people making the changes take responsibility for the impact on deadlines. Our estimates in that scenario were quite good (within the bounds of the sprint, at least).
Of course, the longer the estimation window the less well this works. The only way to estimate accurately is to constrain scope and resources, which is not actually what management/business want.
The manager need to know how to make the estimate to know is bullshit.
If the manager knows how to make the estimate and what it represents, there is no need to inflate it for them.
Any passing glance at the healthcare system immediately reveals that doctors don't give patients cost estimates, inflate costs for insurers, and then settle at negotiated rates. Often they tack on procedures that aren't necessarily part of the initial plan due to unforeseen circumstances while the patient is unconscious and unable to consent, and you can go into a hospital that is ostensibly covered only to find out that a particular provider isn't. It's like if your treads were discovered to be bare, they decided to replace them and then the guy who does wheels sends you his own bill a month later.
In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistically significant margin. but you say anything like that here on HN and it is heresy.
My general opinion is that developers LOVE making everyone believe that software development is somehow "special" from many other "industries" for the lack of a better word and that we simply cannot give you accurate estimates that you can use to make "deadlines" (or better said project plans). and yet most developers (including ones raising hell here and downvoting any comment contrary to "popular belief") are basically doing sht that's been done million times before, CRUD here, form there, notification there, event there etc... It is not like we are all going "oh sht, I wonder how long it'll take to create a sign-up form."
I think we have (so far) been successful at running this "scam" whereby "we just can't accurately estimate it" because of course it is super advantageous to us. and WFH has made this even worse in my opinion - given that we can't provide "accurate estimates" now we can simply pad them (who dare to question this, it is just an estimate, right? can't hold me to the estimate...) and then chill with our wifes and dogs when sh*t is done 6 weeks earlier :)
And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence.
The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams.
Of course that had its own negative side effects, but on the whole it made the company a lot more honest with itself. And consequently got better work out of everyone.
Tell me a story I want to believe, even if it isn't true. Then you can make it the teams' fault because they said they would and didn't.
It feels like as a community, it would be useful to get more articles seeing things from the other side and exploring functional approaches beyond provide-a-worst-case-scenario-estimate.
There's a reason this dynamic is so pervasive. In order for everyone in an organization to do their job well, people do often need a realistic set of estimates. Can sales promise the prospect this integration? Can marketing plan a launch for the new feature? Can the CPO make a reasonable bet on a new line of work?
In my experience, the nuance here is more about handling the mis-estimates. How do we discuss the risks up front? How much work should we put into contingency planning? How do we handle the weeks / months before a deadline when it is clear that we need to limit scope?
https://news.ycombinator.com/item?id=37965582
My estimate math:
R = t × [1.1^ln(n+p) + 1.3^X]
R - time it really takes.
t - shortest possible time it would take without need to communicate.
n - number of people working and involved during the process, both customers and developing organization.
p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)
X - number of new tools, libraries, techniques, used in the process.
Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.
2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it.
So where does that leave us? Well, developers who've seen a lot of different problems recognize when a new problem they see rhymes with a problem they've solved before. That can allow for a very good estimate. But even then, engineers tend to think in terms of best case, or maybe even typical case. I saw a study on this a few years ago, and it showed how often engineers tended to cluster around the median time for solutions. But, since really long tasks, with big error bars have a tendency to really skew timelines, the solution averages was much farther from these median times.
Believe it or not, lawyers have this problem too. They are taught in law school to come up with an estimate based on expected effort, then they apply a formula similar to: double the estimate, then increase the time units. So a 5 hour task becomes 10days. A 2 week task becomes 4 months. Mind you, this isn't the amount of billable hours they're predicting, it's the amount of calendar time that a given task will take until it's complete. This ends up taking into account a lot of variables that lawyers have no control over. Things like court scheduling, or communication delay. I suspect it also takes into account blind spots we humans have around time estimates in isolation. Like, 1 task, if you can focus on it can be done in so many hours. But if you have to do 5 similarly sized tasks, it takes more than 5 times as long, simply because it's easy to expend resources like brain power, and the estimate ignores the refractory periods necessary once the task is completed. (BTW this was one of the problems with the very first stop watch study in the rail yard, where the rail workers didn't work at their sustainable pace, but worked at their depletion pace).
Software development is not surrounded by this sort of infrastructure or codification. My discovery process establishes these lines of communication, and I have no idea when I'll uncover a black box or when one will be imposed upon me.
More concretely, I sample with replacement N times from the empirical distributions of each step, then sum the steps to get N “samples” from the total distribution.
This is called bootstrapping: https://en.m.wikipedia.org/wiki/Bootstrapping_(statistics)
It isn’t too hard to do, and I can confirm that it works reasonably well.
Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.
We could say, always say it will take longer than you think?
Though by this principle, it seems that "overestimates" are likely to be actually accurate?
Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person a factor by which their estimates were off, and this factor was consistent enough that it could be reliably used as a multiplier to improve estimation accuracy.
> Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}
https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.
Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points.
I would snapshot the sprint each day, so each day I could see how many tickets got removed/added. The end result being I could show my manager, look, when volatility is low, we almost always finish the sprint. When the volatility is high, we don't, it doesn't matter if we are over/under velocity because we don't have the time to properly plan and get clarity on asks. Have our product team think more than two weeks out and we'll deliver. That worked to a degree.
More often, the focus on estimating comes from management layers where incentives are not structured to reward anyone for accurate estimates, merely to punish them for missed deadlines.
Time to finished is only one dimension of estimation. With any unit of engineering work there may be code debt added or removed, complexity increased or decreased, morale increased or decreased, etc.
Focusing only on time, especially in a punitive way surely negatively impacts the others.
There is often understandable resistance to this at first. To address concerns, I find it helpful to share with stakeholders that a reasonably accurate estimate, one which could be legitimately used in planning concerns, is really only possible in one of two situations:
A) the outstanding work is a carbon-copy of a previous
effort, such as the second time provisioning a data
center for the same system.
B) the remaining new functional work is determined
by the team to be in the last quartile and is
well-defined, including remaining risks to
successful completion.
Micro-estimates are the enabler of micro-management. A healthy team identifies the highest priority tasks to perform and does so in descending order, where priority is defined as risk to project success.
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
[1] https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anch...
and follow the first link labeled
Main article: Anchoring (cognitive bias)
Actually, you may also read the first link you sent and be equally surprised:
Anchoring bias (also known as anchoring heuristic or anchoring effect)
And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to <1 day chunks.
But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated?
The more projects I work on, the bigger of a fan of spiral development [0] I become.
Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk.
This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates.
And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is.
Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments.
Those dates were mostly informed guesses of what would actually happen or go wrong. Importantly this was between friends. Needless to say, they turned out very accurate.
I have the same anecdotal experience with a possible explanation:
Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation:
Engineer: "I think that would be a day's work"
Me: "This will need to interact with team X's package. Have you accounted for time spent interacting with them?"
Engineer: "Oh no, I guess two days then"
Me: "Will this account for edge case 1 and 2?"
Engineer: "Ah yes, I guess it would be three days then"
Me: "Testing?"
Engineer: "Maybe let's say a week?"
On the other hand experienced devs might have their judgement clouded by past events:
"Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
No, actually, this sounds quite realistic and in many cases even reasonable. Medical insurance does this literally all the time. Insurance companies of many different kinds in general have to do this to prevent fraud and keep costs (and by extension premiums) low.
> There is no fixed path when modernizing a complex legacy system. There is no rulebook to follow.
Of course not. But as an engineer tasked with this kind of project your estimate should reflect some kind of plan for accomplishing the project, where the plan has more concrete and actionable steps that make estimation easier. And if you are good at your job, your estimate should account for known-unknowns (eg this part is contingent on something partially out of our control and may be delayed by X months) and give enough slack to handle inevitable unknown-unknowns without excessive padding. And uncertainty regarding any particular risks or variance in how long somethign takes should be explicitly noted and communicated.
My $0.02:
The unfixable estimate vs deadline problem ultimately boils down to money. A particular project might be worth it if it ties up 10 people for 3 months, but not worth it if it ties up 10 people for 12 months. And relatedly, businesses oftentimes find themselves needing something finished by a certain time to close a sale/keep a customer happy/catch up to a competitor, and the stakeholders on the other end (customers, investors, partners) need some kind of date for their own planning.
Good estimation is really about identifying the probability distribution of the completion date, rather than a single "expected" completion date, and identifying/communicating the related risks. For a big project this itself probably will take a few days to months to complete and communicate. If you do this properly, there should never be any ambiguity as to what is an estimate and what is a deadline. If you don't do this, you are basically assuming that your manager (and their managers and so on) can read your mind and have the exact same understanding as you do regarding how firm the estimate is + what the risks and possibly "actual completion times" are. You're also denying them the opportunity to help you derisk or accelerate the project by eg adding more people to work on it, reach out to some external stakeholders, or communicating the end date to eg investors/customers in a way that reflects risks. You also need to update the people that care about the completion semi regularly to tell them about any new risks or known unknowns for the same reasons.
If you are wildly off with your estimate even after spending the time to breakdown the project with a more actionable plan, identify risks, and come up with ranges/a distribution of outcomes - let's say you blow past your p99 time to completion - you are probably just bad at your job (or trying to operate above your skill level) and it would probably be very reasonable for your manager to hold you to a deadline with the threat of firing you/canceling the project. Yes, the sunk cost fallacy dictates that even projects that run over should probably be completed in many cases (though since overall budget/personnel are usually constrained I think the opportunity cost of doing other things becomes pretty important). But if people can't trust you to estimate properly they probably can't trust you to lead a project or to have estimated the remaining time to finish the project.
It's still a "skill issue" but it's more about knowing how long it will take you or your team. If you don't have the relevant experience with the tech or with the team, you can't really gauge how long something will take.
Before I estimate larger projects I always ask who will be on my team. The estimate is very different depending on the answer.
1. If we’re talking about bamboozling people who are either ignorant or willfully obtuse, excess precision is a stupid but useful tool for getting a realistic multiple of 3x-4x past them.
2. If the target audience understands excess precision, the excess precision is a nice little in-joke to flatter them and acknowledge their cleverness.
3. The absurdity of the precision illustrates tha very imprecision of the estimate.
Note that this also comes out about the same if you're using months (12 months -> 24 years (2.4 decades)) and (at least within a factor of two-ish) weeks (52 weeks -> 104 months (0.867 decades).
I'm not claiming this is accurate, I'm stating that it's a heuristic I'm familiar with.
This may have been in Arthur Bloch's Murphy's Law and Other Reasons Things Go Wrong, though I'm not finding it in comparable collections. Possibly from project planning literature I was reading in the 1990s (DeMarco & Lister, Brooks, Boehm, McConnell, etc.).
The whole world runs on deadlines and timelines. Even a president is elected for a specific duration. If you're in a B2B setting, the customer demands (sometimes even contractually binding) at least the Quarter when something will be delivered.
Time is the only common denominator by which different activities can be coordinated. Without some heed to time, there will be no coherence.
Our bad assumption is in thinking that only the final output matters, regardless of when and where it is delivered. Like saying that it only matters if the train arrives at the station, regardless of when it does.
The problem is anyone depending on us downstream will get impacted. And yes, estimation is tough, requires foresight, and maybe a lot more things, but that's what being a professional means.
Contractors have to plan for surprises as well. The thing is they've done enough similar work to understand the risks and account for them in budget and timelines.
I think a lot of software engineers, possibly because of the classical world they inhabit, are reluctant to look at things as probabilistic. Your estimate can take into account unknowns you just need to estimate the likeliness of encountering certain snags and the penalty they will impose.
Software is the same thing. There are unknowns but there aren't unlimited possibilities.
Went through a roughly 3 year rewrite process while utilizing maintenance mode on the framework I had originally decided on back in 2014 and which sadly had an "upgrade path" of "you look like you could really use a full rewrite for your entire frontend" to get on the very next major version in like 2016. I'd say the main "use" for utilizing their maintenance support, was the fact that they would still fix issues with browser incompatibility, security issues, etc.
Like the fact that back in the day Chrome changed background tabs to no-longer respond to push notifications unless they are the active tab (after some delay)...it broke things in our app. But luckily we able to lean on the vendor for those types of issues, because there was very little my team could do to make a rewrite of a massive webapp any faster than it was already going.
Glad it's done, and I am out.
My comment was not really geared towards chaotic organizations but general sense (especially in myriad threads on this forum) that SWEs think that somehow our profession is so “special” that we cannot possible know how long something will take. I simply do not accept that and personally believe that more likely vast majority of SWEs simply suck at their job. there are roughly 4.5 million of us, how many are really good at their jobs (big part of which is estimation)? probably like 0.4% :)
As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^)
I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way.
I heard someone summarize this as saying, a surgeon may perform the same surgery over and over for decades, while if a programmer does something more than a few times, it becomes an app (or library, etc).
In a sense, unless we are building the same thing we've built before, we are, by definition, always operating at the limit of our abilities.
Negative side effects were about what you'd imagine. Some low performers unjustly shielded themselves. Safeguards were overbuilt as proof "something" was changed to prevent a failure repeat. Executive promotion criteria could get squirrelly. Etc.
But on the whole, I think the individual/team productivity boost and agility created by honesty was a huge net win.
A lot of less experienced engineers also are just bad at estimating and don't do a good job clarifying blockers/risks/etc when participating in planning poker with a scrum master/manager, who may also not be very good at their jobs. Obviously a lot of what I wrote is overkill for "you said this was only one story point but it actually took you two days!" but I think this environment being most SWE's first/only exposure to estimation causes them to take the opposite lesson than what they should (that estimation is awful/bullshit, it doesn't matter if you blow past it/everybody always blows past it, you will be argued with if you estimate something as too high, you are incentivized to excessively overestimate to keep your workload low / prevent people getting angry). But that's really only a productive mindset to have when the stakes are low.
I do think leaders, from executives to managers/tech leads/"scrum masters", should be more in the habit of proving estimates/deadlines for risks and ranges than they are. A lot of the time these things become games of telephone were eg an engineer comes up with a plan with all the risks identified and detailed completion dates, and then their manager converts that into a single date given to the CEO as a reasonable deadline. That said, if you actively communication the current ETA and risks proactively throughout a project you also end up with a convenient paper trial and give people multiple opportunities to correct miscommunication.
There's the cases where it's used to roughly schedule work, or to prioritize features. My boss wants to know roughly how much is on our plates, so he can plan for known upcoming work.
Then there's the cases where it's more of a XY situation, where the boss is asking for estimates because in reality they've got a customer on the hook but they won't sign unless we can implement some functionality before go-live, or something along those lines. Typically that'll be a hard deadline, as customer will either have to switch to us or pay another year of licensing, and the boss wants to know if I can deliver.
I try to suss out if it's the latter, and if I'm unsure I will simply ask why they want the estimate.
If that's the case and it'll be a struggle to make the deadline, I'll try to help figure out if we can perhaps solve the core issue some other way. Perhaps a temporary solution that the client can live with for a week or two extra while we finish the proper solution, or perhaps we just simplify our proposed solution, enabling us to leverage existing infrastructure, and that turns out to be good enough for the customer.
Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.
This is software though, if X has actually been done before then it doesn't need to be done again. It is already done.
Task X clearly had the potential to blow out by 3 months, and they are now working on task Y that is similar to X. It is a reasonable position to assume that there are other as-yet-unknown issues that might cause it to blow out by 3 months until someone has demonstrated that all the unknown unknowns are also resolved by doing it quickly. That is just basic evidence based planning.
Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them.
It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks are in the estimate. It allows reasoning about risk. It allows things like "OK, currently we have 30% error bars either way - what are the biggest contributors to that? Can we knock one or two of those out when we spend a few days investigating?"
It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.
And that's because their entire existence is based upon money, not results. I've only ever had one good manager, and that was because he knew what he didn't know and accepted that we do and are trying our best.
Things take longer but if you over-estimate the project won’t come in significantly any earlier.
I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid.
Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".
There is a spectrum of complexity: simple, complicated, complex. These can be framed in terms of ergodicity and you can search for Barry O'Reilly residuality theory if you want to go down this rabbit hole.
In a simple system we can easily predict the future states based on knowledge of past states. In a complicated system, we can also predict future states based on past, but it requires expert knowledge, though it's still fundamentally able to be understood (e.g. SpaceX rockets). These are both ergodic systems. Complex systems are non-ergodic.
Construction is a complicated system that exists within a complicated environment.
Software is a complicated system that exists within a complex environment.
Complex environments can be wrangled along three dimensions: constraining the environment until we can treat it as "only complicated", evolutionary survivorship via random stress and remediation, and avoiding commoditization.
Construction benefits from all three. Environments are constrained to enable the things we build to operate (cars work mostly on paved roads). There is a history of evolutionary survivorship spanning millennia. And construction is less easily commoditized (people typically do the same thing they did yesterday, and repeat for decades). All of this contributes to the ability to a better ballpark estimate.
Software primarily only attempts to constrain the computing environment in which the software runs: If you build your app to run in a container that can tolerate getting yanked and reincarnated elsewhere, you're golden, i.e. cloud computing is an example of constraining a complex environment until it can be treated as "only complicated". But the business environment remains complex and largely unconstrained. We attempt to constrain it via "give us your requirements", but that's more of an anchoring or negotiating technique than actually addressing the complex business environment. Software doesn't have millennia of evolutionary battle testing. And software is more easily commoditized, meaning if you do the same thing you did yesterday on repeat, that turns into a library or an app, so fundamentally you're always being pushed into novel territory, which therefore is less battle tested by evolutionary survivorship. All of this contributes to less clear estimates in software.
"provided they control most of the dependencies" is a pretty important caveat by the way. many times I've seen people get the rug pulled out from under them by partner teams at the last second. it doesn't matter how clever you are or how hard you work. if you depend on something owned by a team far away in the org chart, they can always blow up your project with little consequence.
The issue isn't around tasks that are predictable in nature and therefore easy to estimate with a small margin of error, it's around complexity in software, unforeseen things, bugs, etc, which can compound for larger long term projects.
If engineers give estimates close to what it would be if everything goes right, then they risk overpromising and underdelivering if something goes wrong (hofstader's law). They might've just wanted to do the right thing by saving the company money and time, but in the end they footgunned themselves.
Or engineers intentionally over-estimate in order to manage the complexity, but then you end up with a lot of padding and parkinson's law. Because as soon as the engineer starts underpromising and overdelivering consistently, management will pressure them to lower their estimates because they have a track record of doing that, so instead they're incentivized to pad and then fill up the entire time they estimated even if it took less time.
Sprints were probably invented in order to deal with some of these issues, so that people just work with a bunch of smaller tickets that are much easier to estimate, with the more complex long term estimates going to management, which are incentivized to get it right because they're shareholders. That often leads to micromanagement and burnout, and it doesn't fix the padding/overestimation issue either, it might even amplify it in a lot of cases.
People here mention giving ranges or probability distributions, and have also equally mentioned that they don't work because management wants a single number, or management just assumes the best-case or middle-case of the range as the actual estimate, and then they still get in trouble for giving ranges and it didn't solve anything. It also doesn't solve the problem of unanticipated setbacks, the whole you don't know what you don't know thing, which can only really be solved culturally in some way.
While there are certainly bad managers that want to squeeze their workers, a lot of the time management is probably also pressured to give estimates and that's why they want and need that accuracy, because they're pressured by investors and clients that want to know how much time and money something will cost.
Overall the entire problem is a system cultural issue around managing complexity.
So yeah. Predicting the future is hard.
Definitely did not seen this. Under performers are underestimating or just do wild random guesses. Under performance is most likely to be in the form of "making small estimate, try to make it technically, but then it has about millions of problems".
Big estimates require courage and confidence - under performers usually do not have either. They are too scared to estimate high.
1. Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic".
2. On top of that, add another x2 (which can be recalibrated as you learn how accurate this tech team is over time with estimates). Don't tell the developers about this, but make sure your higher-ups understand that this is what they need to be prepared for in terms of budgeting and time limits.
The reason you don't ask the developers to multiply by 4 directly, is to keep them motivated to aim for the x2, and avoid slacking or over engineering while feeling overly comfortable early on.
But by having the extra x2 in reserve, your back is covered, and you can afford to be cheritable with the dev team as they (as usually happens) go a bit over the x2 estimate.
This buys some early goodwill that can later be traded back in if you need them to up their game later on.
The alternative to the above is to exclusively find managers (at all levels) that can combine manager skills with high level engineering skills. Such managers often have the ability to expose unneccery delays directly, which includes the ability to tell apart delays caused by devs slacking from incompetence, scope creep or unexpected but valid causes.
Such people are really hard to find, though, for most companies. But companies that manage to build such high level top to bottom tech lead cultures may certainly be able to go from the 4x back down to 2x or even 1x compared to companies with non-technical managers.
Also, many engineering teams WILL take any time given to them.
But instead of making estimates and plans into hard deadlines (when facing the engineers), managers can make sure the organization is ready for overruns.
And as the estimated completion time approaches, they can remain reasonable understanding as long as the devs can explain what parts took longer than estimated, and why.
Part of this is for the manager to make sure customers, sales and/or higher level managers also do not treat the planned completion time as a deadline. And if promises have to be made, customer facing deadlines must be significantly later than the estimated completion time.
When I was naive and believed that Agile was not a sinister micromanagement toolkit to mess with programmers, I tried to explain to people that about half of our estimates should overshoot and half undershoot or they are biased and that there should be more overshoots since there is no upper bound on how much time a task can take if the estimate is wrong.
Ye. No. The burndown chart shouls be as straight as possible.
as things stand what is my incentive to provide an accurate estimate? if no one can question my estimate and hold me to it (well perhaps they can question it but we as industry have successfully been able to convince everyone that these are just estimates, nothing else...) what is my incentive to be accurate? If like one of the commenters above can say "it'll be 2 to 3 weeks" there is an INSANE difference between 2 and 3 weeks, 33% difference. it's like coming to buy a house and agent says "this house is $200k or $300k but you sign here on the bunch of dotted lines and we'll tell you all about it eventually before you have to cut a check." It is good to be in this industry (and especially if you WFH) - say 2 to 3 weeks, finish in 2 and get a week of working on your wellness (or another job :) )
This usually works though in water based heating systems where the flow in the radiators is proportional to the error in temperature.
In practice it might work for electrical radiators too, as the radiator wont cut off when just the air close to it is warm.
Not really with price, but when I've had my house built, the date was overshoot by about 30% too, because of various reasons, like having to stop for winter because some supplies were late by a week several times or my builders had to help teams at other places from time to time (because other teams were late too), not doing anything at my house sometimes for days. So even when building homes (something they do again and again) you can't really put exact estimates.
Ryan, if you are out there reading this - ty.
Reminds me of: Always Multiply Your Estimates by π (2021), https://news.ycombinator.com/item?id=28667174
> ... scope creep ...
If you want to know what Tesla does right and most of us do wrong, it's this: they ship something small, as fast as they can. Then they listen. Then they make a decision. Then they stick to it. And repeat.
They don't make decisions any better than we do. That's key. It's not the quality of the decisions that matters. Well, I mean, all else being equal, higher quality decisions are better. But even if your decisions aren't optimal, sticking to them, unless you're completely wrong, usually works better than changing them.
I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent.
In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad.
The strategy need some social status or incubent code knowledge relative to the team though, to get the good tasks.
Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me.
So I switched to estimates I could meet 90% of the time, and on the slow 10% I worked extra hours to meet my estimate anyway. Managers were happy. If I told them it would be done by Tuesday, it would be done by Tuesday.
But it had enormous benefits beyond that. In almost 90% of cases, I had free time. Sometimes I'd admit to finishing early, but I also used that time to clean up technical debt, automate the tedious parts of my job, or advance my skills. After a while, I could give estimates as short as my old 50% estimates, and still beat them 90% of the time because I'd made my tasks so much easier. Less technical debt also meant the resulting code was less likely to have bugs.
After a while, it seemed to me that all the other devs were overworked and I had it easy. But management gave me raises, and when they got in a jam, I was the guy they called on to bail them out.
If you "look good" too often, your estimates will be distrusted. So, just play some videogames and look like you're a genius at estimating.
"We'd like to replace an excel table for some calculations with a dialog. Here's the template, how long do you need?" which sounds simple enough turns into:
1- Decypher what the example excel template developed by someone over 10 years even does.
2- Oh, there are actually 10 templates and manual actions that give the end result.
2.5- Oh, btw, we asked an external company about doing this for us a while back and they wanted 1kk euros, crazy right?
3- Oh, we also need to generate, send and track offers via the app with the ability to add comments and upload files related to the offer. We also want the user to be queried about what data he has on hand so that calculations he cannot complete are not offered/he's notified as to what else he needs to proceed.
4- Oh, we also need change tracking/audit logs for everything.
5- Oh, we also need to get data from this place, find a free API and also a way to get data out of this software here.
In comparison to that at my previous job the tasks were way smaller and clearer so I'd essentially give myself deadlines when talking to my manager by saying X and Y should be done by Z, A by B.
The only thing I can think of in this situation is to essentially make internal pseudo contracts regarding requirements but then I'm making a pseudo contract with someone 3 levels in the hierarchy above me who's also the person who can terminate me. It's not like that pseudo contract will be read by anyone besides us so it seems better to display lots of uncertainty. At least if you're senior you have more authority in discussion and don't really have to give a fuck since everyone's looking to hire senior devs + your downgrade is a normal dev position. From junior the downgrade seems to be testing or McDonalds and you get to redo junior.
To only assign blame to people/teams when they’ve guaranteed in writing that it would be so and so, avoiding the downsides.
And blaming the process when there were no such guarantees?
At the very least, you need to do a bit of legwork to gather data prior to giving an estimate. Call it design, call it architecture, call it research, call it proof-of-concept, I don't care. Just stop insisting that decisions be made in a vacuum of data. Real results from running code trumps everything.
To be clear, you can produce software without using the scientific method. You can build anything without a data-driven process. But you get what you pay for. The head-in-the-sand approach ignores valuable information and yields poor quality as a result - it doesn't fit the definition of engineering.
E.g. if blame is assigned when there's a written guarantee, why would anyone ever make a written guarantee?
And not trying to be obtuse, but I've only ever seen blameless cultures work in absolute. Compromises let back in all the nasty mal-incentives you see driving unproductive CYA behaviors.
It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.
The thermostat is meant to be far away. This isn't a valid analogy if the thermostat is measuring the temperature of the heater rather than the room.
> Also, many engineering teams WILL take any time given to them.
Agree, engineering teams are not single-stage heaters. They can make more progress toward the goal by working harder (in the short term), or reducing quality, or reducing scope.
But holding hours/week, quality and scope equal, engineering teams aren't going to implement faster because the deadline is sooner. If there is actual slack in the schedule, they will tend to increase scope (i.e. address tech debt, quality of life improvements, plan better).
It might seem that engineers take all the time given to them because most engineering orgs tend to oversubscribe engineering (which makes business sense, since engineering is expensive).
https://www.penguinrandomhouse.com/books/690632/weve-got-you...
Also doing bidding for those estimates in addition could mean that there might be strong incentives for a lot of corner cutting for certain tasks, etc. People will value short term gains over long term gains when there's such pressure.
To answer it personally, which of the two, 7 figure bonus or being fired, it'd be I'd quit. If someone is structuring the development of software based on this premise, then they are going to need a different kind of person than me. But I admit I'm probably an outlier here. I don't really work for the money, and my salary is enough, and I don't like undo pressure.
For arguments sake let's say the 7 figures is $1,000,000. To offer that kind of bonus the project is likely going to be a larger one. And I'm assuming my estimate is determining the deadline, so of course I'm making sure it's something I think I can achieve.
But then there are other significant problems with this structure and the likelihood of meeting the deadline, and, more importantly, generating good code and user experience.
- +5% (in ignoring the -5% as no one cares if you're early unless it creates some sort of QA burden) implies a narrow window. On a 6 month project that is ~6 days. Enough that personnel changes or other uncontrollable factors could lead to a missed deadline. One person getting fed up and leaving would be a huge problem.
- The specification would have to be really clear and agreed upon, since there is much at stake.
- Any changes, scope creep, customer requests, could change the development time, and you'd have to have some sort negotiating buffer built in since there is now so much at stake. Otherwise you're going to get literally everything rejected by the developer as they drive towards the deadline (maybe that's what you want, though).
- Is the result worth having? A focus on a deadline, in my experience, tends to shortchange quality. But maybe the deadline is more important than quality.
- And lastly, if that deadline is missed, or worse, something changes the scope of the project and the bonus is not awarded because that led to the deadline being missed, you're going to have some super pissed developers that will not trust such an arrangement in the future.
I suspect you're talking about situations beyond my pay-grade. I've been a meat and potatoes programmer working in e-commerce and integrations mostly, and we don't see 7 figure bonuses. We certainly have had can't miss deadlines that we mostly didn't miss, but mostly those deadlines were due to external factors (API deprecation mostly), or financial considerations, or lastly, arbitrary deadlines set by management. On the latter, those mostly got missed. But that was to be expected as they were not tied to reality.
And I'd second leetcrews comment below of, "...but it's not a sustainable approach for delivering features". Maybe this scenario works once or twice, but it seems like a terrible way to develop software.
But still, an interesting thought experiment.
Something like a new engineer disagreeing with a PM, a PM disagreeing with higher management, etc…
There’s many reasons why that would be a favourable choice.
I've done it backend, I've done it frontend. With web apps it's always possible, it's the fundamental nature of the web and browsers.
Frontend is trivial because of how browsers work, every page could run a different framework if you were that mad.
Backend I've had two frameworks on one server for multiple migration projects. There's usually a way unless you're switching language.
But worst case scenario, say you wanted to change everything, I'd stick a load balancer in front. Route according to the end point requested. Then gradually migrate end points. You might need some craziness around authentication, but that's the sort of issue that is solvable with a week's work by a single, good, developer.
What was so complicated that stopped you doing that? Genuinely interested.
And a major problem with group estimates is that given how much knowledge a person has about the code, the effective time will vary so much.
So dunno. I have no experiance as a team lead or manager.
I would probably not track task time at all as a manager. It would give the illusion of insight. Rather some loose percent worked by project per programmer.
The application was originally written in Vaadin 7, Vaadin 8 had an absolute ton of breaking changes and we could not migrate in time, and then the breaking changes continued to compound as new releases happened and they migrated away from GWT, making a "big bang" rewrite not practical.
Their extended support included a tool called multi-platform runtime, which allowed the old application and new application to be run side-by-side and each section replaced one at a time. So that is essentially what we did. Still took 3+ years to do the rewrite.
Management in most places is rather interested in getting planning right, not making up numbers and then failing at achieving them. They often lack the training to get it right (both because we have non-engineers as managers, and because we give shit management training to the engineers that become managers), but "management quits listening" is just an excuse.
I'm in this thing for ~4 decades now, at a good number of companies of all sizes (3-200,000) and I've seen the "not listening and insisting on made up numbers" exactly once. I see however a lot of engineers refuse to even attempt to make reasonable estimates.
Second, always pad your estimates. If you have been in the industry longer than 6 months, you'll already know how "off" your estimates can be. Take the actual delivery date, divide that by the estimated date, and that's your multiplier.