I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.
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.
> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.
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.)
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.
Absolutely! That was one of the common productive outcomes: this policy / approach is screwed up, and we could do it better.
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.
The first time I'd seen a blameless post mortem, I thought it was a load of bs, as another organization had just caused the first significant production outage our app had ever had. Convenient... no blame. We went along with the process and it did not take very long to understand how this changed the culture. If someone horked a step on a manual deploy, the real question is why is this not automated. People stopped hiding mistakes - so the old snipe hunts where information to trouble shoot might 'disappear' faded and made it easier to debug and then figure out what could be done better. It helped the business understand that 'running in production' did not mean done.
100%. It was an eye opening experience. Felt somewhat akin to running an RCA on "Why do people hide mistakes?" Well, because it's in their self interest to do so!
The issue with any hybrid system is you have to play the incentives out at scale.
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.
E.g. Some people with lower amounts of credibility will be eager to make guarantees in writing, if they want to sound more convincing than someone with higher credibility who disagrees.
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.
That is probably analogous to what happens in the American healthcare sector with physicians/hospitals/insurance carriers/pharma/etc. Each one padding their bills making it horrendously expensive for everyone at the end of the chain.
The padding in healthcare is part of the system. One part is to have high prices so insurance can negotiate them down. And for hospitals in particular, prices are padded to subsidize emergency care for the indigent (which they have to provide without regard to ability to pay; thanks Reagan).
That's a hyperbolic misstatement of the situation on the ground. Poor people use free emergency rooms as primary care instead of paying for primary care physicians. That's a cost disaster no matter what you think should be done about health care. We'd be much better off with actually free primary care for the poor, and it would at least make sense to prevent the emergency room misuse since it's so wasteful. But it's politically untenable in the US to fix a broken system in any direction people don't like, even when it's Pareto optimal.
This is the story in Canada as well, but way more than the very poor, because there are not enough primary care physicians where needed, and not enough people pursue family medicine. Why would you? What med student looks at the prospect of administering a dinky small business on top of actually practicing medicine, pay well but not great, and have zero equity when they retire?
So we land in a similar position because the change might be publicly funded group practices instead of pay per service which has better optics.
Yeah it seems partial privatization is inevitable or at least the default outcome, at least in Ontario. No other way out that’s also politically viable to enact.
See "We've got you covered" for an analysis of reallocating current US healthcare spending into a general healthcare program that aligns with your thinking.
How about government is paying for treatment of people too poor to pay themselves and everyone is paying their share to finance that spending? And as a bonus everyone else will also get their medical treatment financed this way?
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day.
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.
> 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.
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.
After I presented the volatility findings, that changed. Sprints largely had to stay as they were and the team decided what we’d take on after the sprint started. It got better. But the whole sprint/scrum/agile thing is still weird. It can be helpful but in a large org it’s never easy. I hope for further improvement in the area of scheduling/estimation in software development.
...which is one of my major (of many) complaints about all "scaled agile" frameworks: the promise is that you put all this planning effort in we won't blow up your plan for the next 4/6/n sprints; you get stability and predictability, and can actually shave a yak or boil the ocean, things that are hard to progress with just a 2 week window. Who has ever seen an org with the discipline to NOT do this? Executives are rewarded for the "action imperative" and quick course corrections. They want big, bankable delivery dates AND agile responsiveness to fundamental goal changes. Good luck.
In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.
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.
So many bold claims in this comment and little to no justification.
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've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates
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
> "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
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.
Ime, as a junior dev/ops person, there is almost always scope creep and adding padding grants you room to account for the new idea your supervisor/ user thought of when being midway into development. As far as I can tell, my supervisor also assumes my estimates should be padded more because sometimes you might need wait on human i/o for longer than planned (holidays/ sick leave/...).
one thing that I like, that can help, is to add explicit things in the spec that it will NOT do. If you keep this "types" of functionality you can shut down a lot of scope creep: "we need to send an email alert after the job is done." gets answered "we can do that in a future iteration because this says the feature will not include any alerting or notifications, just log to a file and finish".
A big problem when you're a more experienced engineer is when you have your hands in a lot of things and know the relative priority of stuff and how likely it is that something else of importance will pop up. So you anticipate things getting sidetracked over time, and try to make a bit of a longer estimate, usually to give yourself the slack to do other important things without looking like you're falling behind in JIRA.
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.
I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work.
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 :)
It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.
In your 2nd example of a large corp I can see myself joining and not knowing anything about all these potential landmines etc… but if I was at that corp for say 2-3 years those would all be known things, no? And hence estimates can come with number of assumptions based on 6 other teams doing whatever it is that they need to do etc…? But I totally agree with your point and would not be disappointed if someone missed an estimate in that sort of chaos.
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% :)
I agree with the general sentiment (estimation is part of the work, ppl are not good at estimates, ppl are not good at their job)
I also think that in high churn rate companies, or where team get created and disbanded every two quarters, it’s quite difficult to have a mental model on other teams ability to deliver a dependency for your team.
And this situation I find quite common tbh
You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field.
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.
your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you?
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.
in the short term, people will work crazy hours to hit a date if it's the difference between a 7 figure bonus and getting fired. if the estimate is based on devs working reasonable hours, that's a lot of slack built in. I'm sure they hit the date more often than not in your scenario, provided they control most of the dependencies, but it's not a sustainable approach for delivering features.
"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.
I honestly do not think it is about working crazy hours. perhaps my example can be misunderstood in a sense that if you give someone 7-figure bonus they will inevitably work 20hrs/day if necessary to get there which of course would not mean that they estimated correctly but were off by 12hrs/day :)
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 :) )
> 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.
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.
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.
> 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.
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.
The big issue is when a manager knows the difficulty of the task but not the context it's being done in. A project may be perfectly reasonable to complete in 4 weeks if it's given the priority it deserves, but I know that I'm almost certainly going to get pulled off to do something else so it's going to wind up taking 12 weeks, and then with a very moderate 33% padding giving an overall length of time of 16 weeks, the manager (who has no visibility to the thing which will pull me away) thinks I'm adding 300% padding. Then they say "surely you can do it in less time if we just don't let you get pulled away" and of course you say "well I've been pulled away from all of the past 27 projects over the last 5 years" and they say "don't worry I'll make sure this time is different."
It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.
I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to.
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.
Ye and this is the problem with management using estimates as deadline.
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.
Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.
I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the only one with that experience, which might hurt in the long run. I couldn't actually imagine doing it in my current team. I think people are diligent anyway, and already work more hours than usually would be required.
I find it better to just try to protect each other within the team, to drive everyone making higher estimates.
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.
I think any process step that resembles a game might be problematic.
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.
It is however a logical follow up of the managers behaviour. If they try to hold the estimate as deadline, the estimate will be larger next time. If manager doesn't see this coming, the manager needs to work on some people skills.
The managers are often just as trained in this by the organization. If I'm in a "commitment" organization, I'm sure as hell telling them all to pad their estimates.
The punishment for a commitment culture is inflated estimates.
It's exactly this kind of prideful ego centric attitude that these managers rely on to get folks to commit to unrealistic estimates, then work nights and weekends (and cut corners) to fulfil.
I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right.
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.
Being reliable is very valuable for the company. Better for you, better for the company. Unrealistic deadlines is bad for everyone involved. Especially for day to day work
I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements.
"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.
> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.
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.
This can only hold water in reasonably small orgs. In large orgs you often have to coordinate with large number of teams to get something delivered. Those teams have changing priorities that can impact when they complete their tasks. Your teams priorities can be shifted too to fight some fire. So this small estimate has no value because it has 0 correlation to the overall delivery date higher ups can commit to for the overall project.
One way to get the point across is by stopping to pretend estimates are precise.
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.
>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.
Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".
Outside of cartoons and a couple of rather bad environments, that's just plain made up nonsense.
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.
The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.
But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.
And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?
You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences.
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.
Here is an approach for estimation that works pretty well (from the point of view of a manager).
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.
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.
Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law.
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}
Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task?
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.
Some of the best career advice I got was very early on at my first gig - I had a designer tell me, over a cup of sake, that I should just inflate all my estimates by 60%. 30% to cover the stuff I hadn’t thought of, 30% to cover what they hadn’t thought of.
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.
For starters, never commit to a timeline without doing your due diligence. We're not selling carpets. Anyone who gives a time estimate on the spot is setting themselves up for failure.
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.
if you need to deal with this, you must present estimates as ranges or distributions. Management needs a value for both concrete, legit purposes like budgets and also for (still legitimate) psychological reasons like building comfort that they know what's going on and they are in control. As you mention, people will anchor on a number and that in a nutshell is how an estimate becomes a deadline. Planning and execution will refine the value right up to the point you ship with a very accurate estimate of "how long do you think this will take?".
Problem is anything non-trivial can't be estimated: deadlines are useful to timebox the process and keep it accountable with a follow-up to see if it's worth continuing. Otherwise it becomes "just trust me bro" which is equally unfair in the opposite direction.
The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much.
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.
One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth.
I've seen projects run in parallel like this for 10+ years.
I just got done doing exactly that with my old SaaS I built / worked on for a decade.
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.
I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away.
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.
That is actually part of the "extra support" we decided to pay for.
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.
In 1505 Michelangelo gave an estimate of five years to finish the tomb for Pope Julius II.
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.
My rule: list all the tasks, estimate times for each task, add up all the estimates, and multiply the results by π. If you're using unknown technology, use π^2.
My method is take an educated guess multiply by 2 add 1 as extra buffer and then change it to the next unit, e.g. day->week, week->month, months->quarter. So for something that it should take 1 day I'd say 3 weeks. It seems a lot but at the end there's usually so much red tape, burocracy and and technical debt that it usually ends in the latter ballpark.
"Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too. Thank heavens, reality does not operate like this."
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.
It's also why they will write off a car if the estimate is much more than 70% of the value of the car. Yes the write-off may cost them more, but it's a known upper bound and it closes the claim. Insurance companies don't like open claims.
It depends on whether we're talking about estimates or negotiated rates.
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.
There's also whether they will pay at all for some things. They have some discretion to claim some damage was existing, or unrelated to the claim, caused by the repair shop, not normally covered, etc. Or where they won't pay for OEM parts if some substitute is available. There's lots of ways they can shuffle around.
One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns.
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.
Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
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.
> Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
What logic is that based on?
Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference.
Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common.
I'm going to assume we're talking about an oven below, but the principle also applies to AC:
A thermostat attached to a device will measure the temperature near the device, which typically is a bit higher elsewhere in the room, even if the sensor is at the air intake.
Also, even when the air temperature in a room reaches 72F, the walls may still be cold. This means that the temperature experienced by a person in the room will be lower than 72F, since the person will be exposed to less infrared radiation than if the room had been at 72F for a longer period of time.
So, if the goal is to reach a stable 72F (as felt by a human), the fastest way is to turn it to maybe 80F, and then turn it down when the temperature feels about right, or even a bit later (due to the thermal mass in the walls, furniture, etc).
If instead, the the temperature is set to 72F from the start, the oven will start to switch on and off quite freqently as air near the sensor reaches ~72F, and the felt temperature in the room will approach 72F assymptotically.
I live in an old house in a place that can get very cold, and I know this first hand.
> Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
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).
> 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).
If all your engineers will make use of most of the slack for such purposes, rather than unproductive activities, you've either been very skillful or very lucky in hiring them (or at least their team leads, etc).
A lot of engineers (myself included) will produce more if there is at least a moderate amount of pressure applied towards delivering something useful relatively soon.
Too much pressure can definitely have the reverse effect, as it introduces more long term technical debt than what is saved in the short term. Also, intermittent period of low pressure can lead to innovation that wouldn't happen if the pressure is always constant.
Still, most tech teams I've worked with will tend to become a bit too relaxed (leading to shorter days, longer breaks, more chatter/social media, etc) if they are presented with delivery dates 1 year in the future for tasks that "feel" like it's only going to take 3-6 months.
Which may very well lead to the task taking 15-18 months instead of the 10-12 months it really takes due to those unexpected complications nobody explicitly thought about.
This also transfers to "agile" development, and in many cases "agile" can make these issues even worse, especially for deliverables that require months to years of effort before anything economically self-sustained can be released. (For instance, if you need to replace a legacy system, the new system isn't delivering net benefit until the legacy system can be shut down.)
After too many iterations of providing "some wild-ass guess" estimates and them turning into hard deadlines, I now try to champion a No Estimates[0][1] approach with stakeholders.
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.
EDIT:
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.
This is a fun formula that caught my eye a while ago in HN, it looks flashy and very cool. Of course, just like others do their estimations, this one is just a made up formula and without any formal validity, apart from supposedly personal experience:
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.
Sadly, estimates are a negotiation. Whoever provides a number first generally loses because of "The Wince".
"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.
Not only that, in the name of efficiency where I work estimates are actively being pushed down and no spillovers are allowed. I've been in crunch like mode for over a year with no recuperation at all. I kept on hoping it will get better but it seems it's getting worse. On top of it we're all rotated to different areas of the product all the time with no recourse. Though I'm still running along I feel absolutely spent mentally...
The best estimation system I've seen is to actually BET on the completion date, closest gets a free lunch paid for by other members of the group.
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 could see that working well for managers, if they incentivize estimates as biweekly or monthly bonuses going to the most accurate one, and each person gives a detailed estimate of ballpark plus probability of what sorts of things can go wrong and how that impacts the estimate.
Of course businesses want to be able to de-risk by having highly accurate predictions of the future. Too bad those don't exist in any domain of business planning.
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.
I often see takes on this topic from the engineering side. "It's hard!". "Managers just don't understand".
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?
This is it. I'm a hardcore engineer at heart who has a lot of these sales, marketing, and product folks as friends, and can attest to the fact that they also have constraints.
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.
My estimation technique is to completely ignore the nature of the task, and instead just try to figure out the highest number the person asking will accept.
Estimates are tricky because different manager roles and different personalities bias toward totally different/incompatible concepts of what an estimate actually means. The author's article is conflating realistic and pessimistic estimates:
- 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.
+1. I wrote myself a script that does this with distributions based on my personal time tracking data for doing certain tasks.
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.
I once tried to give interval range estimates, the manager said "I cannot work with that, give me a single number". (And when I gave a single number, he said "that is much too long" and tried to negotiate it down to 10 times shorter). Happy to be out of there.
In my direct personal experience, for me it was 1969 during my first major gig. I remember one project, called the March 1 system, that slowly came into being sometime that October, if my memory serves me correctly. There was tension, of course. This was exacerbated by having to work nights to get access to the system to continue development.
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.
My technique is to give an estimate with error bars. Something like 6 weeks plus or minus 2. That then leads into discussion as to what is unknown/undefined leading to the uncertainty. Sometimes the error bars are larger than the estimate because I know there will be endless feature creep and UI revisions for something like "analytics". And sometimes the number could be negative like 6 weeks plus or minus 8. That is when the functionality already exists (eg the data is already there - you can already load it into Excel and a pivot table) and could be sufficient.
At my very first job out of college,¹ the VP who led the division that I was part of invited me into his office (I think there was someone else from the team, but this is 34 years ago so who knows) and talked about a little game he had encountered about estimates. He gave us a list of 20 things to estimate with 95% confidence (the only one I remember was the weight of a 747), all given as a range. If we did it right, we would get 19 of the 20 correct. The point was to set the range large enough that you could be confident about the answer.
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.
I would say that the trend against actual agile and towards waterfall (PRDs are totally en vogue) suggests that deadlines are how most company management looks at this. Definitely not suggesting it is right, but "really aggressive 'estimates' (that are accurate beyond human ability) you can plan on", aka deadlines, are expected of any product/engineering org today.
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.
When I give an estimate, I always reiterate that it's just an estimate that is based on limited and incomplete information, and that the real number can be more or less. If they don't like it, they're free to put someone else on the project.
And that someone usually needs to get some information to me by a certain time for my estimate to be reliable, and often doesn't. Or they need to not change the plan half way through and expect the same delivery time. Or needs to understand that when I say two tasks will take about a day each, no I can have both done by tomorrow. And do on, and so forth.
And yet Deloitte continues to exist and overcharge and overrun deadlines, and the economy, I'm told, is still doing quite well. Maybe this is all kayfabe and it doesn't actually matter.
In my experience, there are two different reasons for why I get asked for estimates.
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.
I normally only commit to "We will give an update in X (minutes/hours) to make sure we understand the problem first. Then start giving estimated timelines in ranges with specific call outs for updates and possible changes to the timeline.
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.
That's cool that they went to Sokcho!! Not many people go to Sokcho but imo it's the best city in Korea, the vibes there are on point, nobody really speaks English and it's pretty dead for the most part, but I really love Sokcho for the vibes, it's maybe the place i've felt the most at peace in my life. If you ever get the chance, I recommend Sokcho. :)
I visited Sokcho a few months ago! I agree with you, it just has such a nice and chill vibe that makes you be at peace, and lot's of interesting history in relations to North Korea. It was also really nice to go for a bike ride around the big lake that is there.
It's really simple. To succeed you need to look good in person and on paper. Under estimate and it can blow up in your face. Over estimate and you start to look incompetent. Fail to walk the tight rope and you'll soon be laid off. Succeed and you'll survive long enough to get laid off anyway when the next recession hits.
Estimates have always been deadlines. I've noticed it since at least 1999. Either your estimate goes up a certain number of management levels and then they don't want to lose face so you are stuck with it. Or a salesperson has seen it and promised it to customer and nobody wants to be the one that loses the deal so you are stuck with it.
Working in smaller steps is how you should build software. Constantly get feedback and re-evaluate what you're working on with other members of the team. Instead of giving an estimate, use t-shirt size.
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 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 does not need to be on a MVP, it can be given before that from your fellow engineers. That said there are tasks which really take a lot of research before even fellow engineers can give feedback.
I don't need constant feedback, I mostly need to be left alone to do the actual work. Problem is, the Cult of Agile gets nervous by the third daily standup where you just say you're still working on the same thing, because everyone knows no programming activity ever takes more than a large t-shirt's worth of days, however many that is.
These are all just tricks to reduce cost and make sure you get things done. You have competing constraints:
# 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.
Even worse -- giving a thorough estimate, having the other party decline and reply with a different, significantly shorter estimate, and then turning their new estimate into your new deadline. Woof!
This is especially problematic in early business when the team is small and manager act with same policy/process as when at BigCo.
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.
David Parnas wrote in A Rational Design Process (1985) [1] that accurate estimates are essentially unattainable, but we should try anyway. The point is, I think, that the ceremony of a structured process facilitates communication better than no ceremony.
Nobody is going to fix the problem without fixing the culture, which isn't easy to do.
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.
Heuristics I'd learned was "double the time and bump the unit".
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.
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.).
Then you get the dreaded can you explain why it takes so long, or I asked engineer xyz and they gave a different estimate, where is the complexity etc.
A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc.
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.
The biggest surprise to me was the project managers and leads who refused the opportunity for going from the big numbers to the small one by allowing a faster development architecture.
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.
I definitely relate to the basic issue of estimates with my one-person consulting projects. The bit they didn't mention is: who pays for the cost of the inspections and analysis? In software, it can take a long time to analyse the requirements and the solution, in order to come up with an estimate (or fixed quote), and I find it awkward trying to get paid for that time.
Do a roadmap. Fixed scope small project that you get paid for where you define requirements. Deliverable is a functional requirements doc. It derisks the project for them, and gives you more confidence when quoting a fixed scope fixed price project. You just don’t guarantee timeline. I’ve been doing it for over a decade - it works wonders.
What is the total cost of these projects and how much are you typically charging for the requirements doc?
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?
When managers refused to accept that we just can't predict the future of the creative work that is software design and implementation.
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.
I was asked to estimate a major project after a month of onboarding and such, and despite being lied to that the deadline was flexible, management decided the estimate was a suicide pact. Best part is: we all got laid off right as we finished up most of the work.
When incompetent management who scam their sorry asses to the top for a lick of the brass ring before getting their asses kicked to the curb became the norm.
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
> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate?
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.
They do, I considered adding that, but felt like it detracted from the point.
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.
The problem of estimates as they exist in a "Agile" process - they force decisions to be made when the least amount of empirical data is available. Then once work starts and information starts flowing in, you can't change your estimate. The scientific method is explicitly banned! This is often by design; data-driven decisions are incompatible with management-vibe-driven decisions.
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.
You're correct to a degree, but IME it's a discipline issue, not a skill issue as such.
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.
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).
> 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
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.
Yes I think you're right about it being based on experience.
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.
It's literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason.
Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or unrecognized systemic factor
When I cut open my ceiling to fix a plumbing issue I didn't know what I was going to find exactly, but I had a pretty good idea of the possibilities. My estimate for how long the fix would take was pretty close.
Software is the same thing. There are unknowns but there aren't unlimited possibilities.
It's a great analogy, but I think it's the kind of analogy that works on the surface and not in the details most of the time due to a) much more codification of practice in construction and b) more "fixed" knowledge of what's likely based on location and build era of the home, whereas software is much more dynamic and often subject to individual whims of developers or management.
If you're hiring architects and engineers to design and build your home, you might already have a pretty good idea of the home you want. The people you've hired provide estimates on cost and timing based on solidly known quantities. They've put in a basement like that before. They've worked with your weird materials. Their vendors report on material status daily.
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.
I guess I just don't buy that software is full of unknowns whereas construction is not.
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.
You're framing the problem in terms of mathematical expected value (probability and penalty/reward), but the business environment in which software operates is fundamentally complex (see below).
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.
No, it is a funding issue. Nobody wants to pay software engineers for actually doing prestudies to learn enough to do a proper estimate. They want a good estimate but do not want to pay for it.
Nonsense. Code is copy-pasteable; other things are not.
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.
Building brick walls is easy to estimate not because it is physical labor but because the company has done it many times before. Ask a construction company to estimate a unique one-off job and they will most likely fail. And that is despite them getting a lot of resources for investigating and planning which software engineers almost never get.
> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too.
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.
This is a very good comment and does reflect my experience. As engineers, we're the only people who can estimate something close enough, and it becomes our job to do that while taking into account the risks.
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.
Thank you! And yeah, I think a lot of software engineers miss the forest for the trees in assuming that estimates are "only estimates", in what is implicitly assumed by others (who may not have as much context) when eg communicating dates, and in the assumptions they make regarding constraints that may not actually be constrained (eg the ability to add more people to the project or partially release/launch it with reduced scope, with the remainder to be added later). It's like, people forget that a few weeks of one engineer's time costs their employer tens of thousands of dollars, and that multi-quarter/multi-person projects literally are $1mm-$10mm+ endeavors.
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.
I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.
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.
> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly.
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.)
This is literally the endgame.
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.
To shift the focus from blame to improvement is critical for fostering innovation
Just curious if the processes got tuned/adjusted as a result? And what were the negative side effects?
Absolutely! That was one of the common productive outcomes: this policy / approach is screwed up, and we could do it better.
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.
The first time I'd seen a blameless post mortem, I thought it was a load of bs, as another organization had just caused the first significant production outage our app had ever had. Convenient... no blame. We went along with the process and it did not take very long to understand how this changed the culture. If someone horked a step on a manual deploy, the real question is why is this not automated. People stopped hiding mistakes - so the old snipe hunts where information to trouble shoot might 'disappear' faded and made it easier to debug and then figure out what could be done better. It helped the business understand that 'running in production' did not mean done.
Ryan, if you are out there reading this - ty.
100%. It was an eye opening experience. Felt somewhat akin to running an RCA on "Why do people hide mistakes?" Well, because it's in their self interest to do so!
Wouldn’t a hybrid system make more sense?
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?
The issue with any hybrid system is you have to play the incentives out at scale.
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.
E.g. Some people with lower amounts of credibility will be eager to make guarantees in writing, if they want to sound more convincing than someone with higher credibility who disagrees.
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.
> padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines".
This is good advice, as devs tend to underestimate.
That is probably analogous to what happens in the American healthcare sector with physicians/hospitals/insurance carriers/pharma/etc. Each one padding their bills making it horrendously expensive for everyone at the end of the chain.
The padding in healthcare is part of the system. One part is to have high prices so insurance can negotiate them down. And for hospitals in particular, prices are padded to subsidize emergency care for the indigent (which they have to provide without regard to ability to pay; thanks Reagan).
How can you not be grateful for that? You don't have money, so you should die? Is that really what you mean?
That's a hyperbolic misstatement of the situation on the ground. Poor people use free emergency rooms as primary care instead of paying for primary care physicians. That's a cost disaster no matter what you think should be done about health care. We'd be much better off with actually free primary care for the poor, and it would at least make sense to prevent the emergency room misuse since it's so wasteful. But it's politically untenable in the US to fix a broken system in any direction people don't like, even when it's Pareto optimal.
This is the story in Canada as well, but way more than the very poor, because there are not enough primary care physicians where needed, and not enough people pursue family medicine. Why would you? What med student looks at the prospect of administering a dinky small business on top of actually practicing medicine, pay well but not great, and have zero equity when they retire? So we land in a similar position because the change might be publicly funded group practices instead of pay per service which has better optics.
Yeah it seems partial privatization is inevitable or at least the default outcome, at least in Ontario. No other way out that’s also politically viable to enact.
See "We've got you covered" for an analysis of reallocating current US healthcare spending into a general healthcare program that aligns with your thinking.
https://www.penguinrandomhouse.com/books/690632/weve-got-you...
> But it's politically untenable in the US to fix a broken system in any direction people don't like
It’s not even obvious to me that people don’t like the notion of sane, socialized healthcare. They’ve just been trained not to like the name.
How about government is paying for treatment of people too poor to pay themselves and everyone is paying their share to finance that spending? And as a bonus everyone else will also get their medical treatment financed this way?
> One part is to have high prices so insurance can negotiate them down.
One basic truism in business is that "Everybody wants a discount".
Did... did you just chide Reagan because his healthcare policy was not sociopathic enough? I'll admit, that's new. Impressive.
Yeah, it would certainly be cheaper if those uppity poors just died instead.
was this a company based out of Portland by chance? sounds like my last employer
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day.
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.
> 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.
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.
In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.
After I presented the volatility findings, that changed. Sprints largely had to stay as they were and the team decided what we’d take on after the sprint started. It got better. But the whole sprint/scrum/agile thing is still weird. It can be helpful but in a large org it’s never easy. I hope for further improvement in the area of scheduling/estimation in software development.
...which is one of my major (of many) complaints about all "scaled agile" frameworks: the promise is that you put all this planning effort in we won't blow up your plan for the next 4/6/n sprints; you get stability and predictability, and can actually shave a yak or boil the ocean, things that are hard to progress with just a 2 week window. Who has ever seen an org with the discipline to NOT do this? Executives are rewarded for the "action imperative" and quick course corrections. They want big, bankable delivery dates AND agile responsiveness to fundamental goal changes. Good luck.
> What helped me was to track Sprint Volatility in addition to Sprint Velocity.
I dread to imagine the number of bike shedding meetings and planning poker it takes to change a 5 to a 3 or 7.
Jitter in agile; I love it.
In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.
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.
So many bold claims in this comment and little to no justification.
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've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates
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
> "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
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.
I've always found that finding a similar scope problem and how long it took is the best predictor of how long the new problem is going to take.
Ime, as a junior dev/ops person, there is almost always scope creep and adding padding grants you room to account for the new idea your supervisor/ user thought of when being midway into development. As far as I can tell, my supervisor also assumes my estimates should be padded more because sometimes you might need wait on human i/o for longer than planned (holidays/ sick leave/...).
one thing that I like, that can help, is to add explicit things in the spec that it will NOT do. If you keep this "types" of functionality you can shut down a lot of scope creep: "we need to send an email alert after the job is done." gets answered "we can do that in a future iteration because this says the feature will not include any alerting or notifications, just log to a file and finish".
But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates
is the essence of this thread
A big problem when you're a more experienced engineer is when you have your hands in a lot of things and know the relative priority of stuff and how likely it is that something else of importance will pop up. So you anticipate things getting sidetracked over time, and try to make a bit of a longer estimate, usually to give yourself the slack to do other important things without looking like you're falling behind in JIRA.
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.
I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work.
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 :)
It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.
In your 2nd example of a large corp I can see myself joining and not knowing anything about all these potential landmines etc… but if I was at that corp for say 2-3 years those would all be known things, no? And hence estimates can come with number of assumptions based on 6 other teams doing whatever it is that they need to do etc…? But I totally agree with your point and would not be disappointed if someone missed an estimate in that sort of chaos.
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% :)
I agree with the general sentiment (estimation is part of the work, ppl are not good at estimates, ppl are not good at their job) I also think that in high churn rate companies, or where team get created and disbanded every two quarters, it’s quite difficult to have a mental model on other teams ability to deliver a dependency for your team. And this situation I find quite common tbh
You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field.
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.
your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you?
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.
in the short term, people will work crazy hours to hit a date if it's the difference between a 7 figure bonus and getting fired. if the estimate is based on devs working reasonable hours, that's a lot of slack built in. I'm sure they hit the date more often than not in your scenario, provided they control most of the dependencies, but it's not a sustainable approach for delivering features.
"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.
I honestly do not think it is about working crazy hours. perhaps my example can be misunderstood in a sense that if you give someone 7-figure bonus they will inevitably work 20hrs/day if necessary to get there which of course would not mean that they estimated correctly but were off by 12hrs/day :)
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 :) )
> 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.
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.
That's an interesting scenario you're proposing.
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.
> 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.
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.
The big issue is when a manager knows the difficulty of the task but not the context it's being done in. A project may be perfectly reasonable to complete in 4 weeks if it's given the priority it deserves, but I know that I'm almost certainly going to get pulled off to do something else so it's going to wind up taking 12 weeks, and then with a very moderate 33% padding giving an overall length of time of 16 weeks, the manager (who has no visibility to the thing which will pull me away) thinks I'm adding 300% padding. Then they say "surely you can do it in less time if we just don't let you get pulled away" and of course you say "well I've been pulled away from all of the past 27 projects over the last 5 years" and they say "don't worry I'll make sure this time is different."
It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.
I think a lot of them know the difference, they just don't care. The estimate is a tool to beat you with.
I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to.
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.
Ye and this is the problem with management using estimates as deadline.
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.
Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.
Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants.
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.
I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the only one with that experience, which might hurt in the long run. I couldn't actually imagine doing it in my current team. I think people are diligent anyway, and already work more hours than usually would be required. I find it better to just try to protect each other within the team, to drive everyone making higher estimates.
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.
I think any process step that resembles a game might be problematic.
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.
It is however a logical follow up of the managers behaviour. If they try to hold the estimate as deadline, the estimate will be larger next time. If manager doesn't see this coming, the manager needs to work on some people skills.
The managers are often just as trained in this by the organization. If I'm in a "commitment" organization, I'm sure as hell telling them all to pad their estimates.
The punishment for a commitment culture is inflated estimates.
It's exactly this kind of prideful ego centric attitude that these managers rely on to get folks to commit to unrealistic estimates, then work nights and weekends (and cut corners) to fulfil.
I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right.
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.
Being reliable is very valuable for the company. Better for you, better for the company. Unrealistic deadlines is bad for everyone involved. Especially for day to day work
I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements.
"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.
> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.
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.
This can only hold water in reasonably small orgs. In large orgs you often have to coordinate with large number of teams to get something delivered. Those teams have changing priorities that can impact when they complete their tasks. Your teams priorities can be shifted too to fight some fire. So this small estimate has no value because it has 0 correlation to the overall delivery date higher ups can commit to for the overall project.
> In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent.
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.
Yeah but missing estimates makes you look super duper incompetent by comparison.
One way to get the point across is by stopping to pretend estimates are precise.
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.
>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.
Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".
Outside of cartoons and a couple of rather bad environments, that's just plain made up nonsense.
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.
The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.
But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.
And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?
How can you tell what is worth doing if you don't know how long it might take?
You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences.
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.
What is the difference between a projection and an estimate?
For more info see: https://www.youtube.com/watch?v=QVBlnCTu9Ms
Who is doing it IMO.
You work backwards. You decide how much time you’re willing to spend to get the worth. Then, take steps towards it with checkpoints.
Managers are often caught in the middle
Here is an approach for estimation that works pretty well (from the point of view of a manager).
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.
> Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic". On top of that, add another x2 ...
Reminds me of: Always Multiply Your Estimates by π (2021), https://news.ycombinator.com/item?id=28667174
> ... scope creep ...
An epic treatise on scheduling, bug tracking, and triage (2017), https://apenwarr.ca/log/20171213>Ask the dev team to provide an optimistic estimate
Why? They are developers not project managers or staticians.
The irony is that managers who demand certainty often undermine the very trust and collaboration they need to get reliable insights
Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law.
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...
Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task?
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.
[0] https://en.m.wikipedia.org/wiki/Spiral_model
I’m more of a Parkinson’s Law person: "Work expands so as to fill the time available for its completion.”
Things take longer but if you over-estimate the project won’t come in significantly any earlier.
Some of the best career advice I got was very early on at my first gig - I had a designer tell me, over a cup of sake, that I should just inflate all my estimates by 60%. 30% to cover the stuff I hadn’t thought of, 30% to cover what they hadn’t thought of.
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.
For starters, never commit to a timeline without doing your due diligence. We're not selling carpets. Anyone who gives a time estimate on the spot is setting themselves up for failure.
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.
Always reminds me of this
https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub
Knew what this was without clicking on it.
if you need to deal with this, you must present estimates as ranges or distributions. Management needs a value for both concrete, legit purposes like budgets and also for (still legitimate) psychological reasons like building comfort that they know what's going on and they are in control. As you mention, people will anchor on a number and that in a nutshell is how an estimate becomes a deadline. Planning and execution will refine the value right up to the point you ship with a very accurate estimate of "how long do you think this will take?".
"then you get it done "ahead of time" and look good"
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.
Problem is anything non-trivial can't be estimated: deadlines are useful to timebox the process and keep it accountable with a follow-up to see if it's worth continuing. Otherwise it becomes "just trust me bro" which is equally unfair in the opposite direction.
"Just trust me" approaches can be just as damaging as rigid demands for precise estimates
I think "good managers" create environments where estimates are treated as collaborative tools rather than promises etched in stone
The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much.
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.
One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth.
I've seen projects run in parallel like this for 10+ years.
I just got done doing exactly that with my old SaaS I built / worked on for a decade.
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.
I've been doing this a while now, and as far as I can tell, there's always a way to run two frameworks side by side and migrate. And existing users get new stuff right away.
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.
That is actually part of the "extra support" we decided to pay for.
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.
In 1505 Michelangelo gave an estimate of five years to finish the tomb for Pope Julius II.
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.
I learned something important early in my career: the first number you put out will be remembered.
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.
> Kirk: Mr. Scott. Have you always multiplied your repair estimates by a factor of four?
> Scotty: Certainly, sir. How else can I keep my reputation as a miracle worker?
There’s a whole generation of developers who have internalized this.
There’s a whole generation of management who have caused this due to their own behavior.
My rule: list all the tasks, estimate times for each task, add up all the estimates, and multiply the results by π. If you're using unknown technology, use π^2.
I do something similar but I use the Indiana version of 3.2 https://www.mentalfloss.com/article/30214/new-math-time-indi...
My method is take an educated guess multiply by 2 add 1 as extra buffer and then change it to the next unit, e.g. day->week, week->month, months->quarter. So for something that it should take 1 day I'd say 3 weeks. It seems a lot but at the end there's usually so much red tape, burocracy and and technical debt that it usually ends in the latter ballpark.
Nice algorithm!
Governments around the world must be using it too where a year turns into 3 decades.
> the first number you put out will be remembered
This is called anchoring effect, a psychological bias.
I think you meant "anchoring bias": https://www.scribbr.com/research-bias/anchoring-bias/
Anchoring effect is something related but subltley different: https://en.m.wikipedia.org/wiki/Anchoring_effect
Is it? If you visit
https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anch...
and follow the first link labeled
you may be surprised.Actually, you may also read the first link you sent and be equally surprised:
https://www.scribbr.com/research-bias/anchoring-bias/#what"Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too. Thank heavens, reality does not operate like this."
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.
It's also why they will write off a car if the estimate is much more than 70% of the value of the car. Yes the write-off may cost them more, but it's a known upper bound and it closes the claim. Insurance companies don't like open claims.
It depends on whether we're talking about estimates or negotiated rates.
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.
There's also whether they will pay at all for some things. They have some discretion to claim some damage was existing, or unrelated to the claim, caused by the repair shop, not normally covered, etc. Or where they won't pay for OEM parts if some substitute is available. There's lots of ways they can shuffle around.
One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns.
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.
Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
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.
> Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
What logic is that based on?
Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference.
Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common.
I'm going to assume we're talking about an oven below, but the principle also applies to AC:
A thermostat attached to a device will measure the temperature near the device, which typically is a bit higher elsewhere in the room, even if the sensor is at the air intake.
Also, even when the air temperature in a room reaches 72F, the walls may still be cold. This means that the temperature experienced by a person in the room will be lower than 72F, since the person will be exposed to less infrared radiation than if the room had been at 72F for a longer period of time.
So, if the goal is to reach a stable 72F (as felt by a human), the fastest way is to turn it to maybe 80F, and then turn it down when the temperature feels about right, or even a bit later (due to the thermal mass in the walls, furniture, etc).
If instead, the the temperature is set to 72F from the start, the oven will start to switch on and off quite freqently as air near the sensor reaches ~72F, and the felt temperature in the room will approach 72F assymptotically.
I live in an old house in a place that can get very cold, and I know this first hand.
For a large room where the vent is far away from the sensor I can get behind that.
For a fan forced oven, not so much.
> Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.
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).
> 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).
If all your engineers will make use of most of the slack for such purposes, rather than unproductive activities, you've either been very skillful or very lucky in hiring them (or at least their team leads, etc).
A lot of engineers (myself included) will produce more if there is at least a moderate amount of pressure applied towards delivering something useful relatively soon.
Too much pressure can definitely have the reverse effect, as it introduces more long term technical debt than what is saved in the short term. Also, intermittent period of low pressure can lead to innovation that wouldn't happen if the pressure is always constant.
Still, most tech teams I've worked with will tend to become a bit too relaxed (leading to shorter days, longer breaks, more chatter/social media, etc) if they are presented with delivery dates 1 year in the future for tasks that "feel" like it's only going to take 3-6 months.
Which may very well lead to the task taking 15-18 months instead of the 10-12 months it really takes due to those unexpected complications nobody explicitly thought about.
This also transfers to "agile" development, and in many cases "agile" can make these issues even worse, especially for deliverables that require months to years of effort before anything economically self-sustained can be released. (For instance, if you need to replace a legacy system, the new system isn't delivering net benefit until the legacy system can be shut down.)
> 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".
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.
After too many iterations of providing "some wild-ass guess" estimates and them turning into hard deadlines, I now try to champion a No Estimates[0][1] approach with stakeholders.
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:
EDIT: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
This is a fun formula that caught my eye a while ago in HN, it looks flashy and very cool. Of course, just like others do their estimations, this one is just a made up formula and without any formal validity, apart from supposedly personal experience:
https://news.ycombinator.com/item?id=37965582
The X factor is likely correct, but needs some additional notes.
Include additional X quantity for unknown unknowns, not just the known unknowns.
Sadly, estimates are a negotiation. Whoever provides a number first generally loses because of "The Wince".
"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.
Not only that, in the name of efficiency where I work estimates are actively being pushed down and no spillovers are allowed. I've been in crunch like mode for over a year with no recuperation at all. I kept on hoping it will get better but it seems it's getting worse. On top of it we're all rotated to different areas of the product all the time with no recourse. Though I'm still running along I feel absolutely spent mentally...
The best estimation system I've seen is to actually BET on the completion date, closest gets a free lunch paid for by other members of the group.
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 could see that working well for managers, if they incentivize estimates as biweekly or monthly bonuses going to the most accurate one, and each person gives a detailed estimate of ballpark plus probability of what sorts of things can go wrong and how that impacts the estimate.
Of course businesses want to be able to de-risk by having highly accurate predictions of the future. Too bad those don't exist in any domain of business planning.
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.
I often see takes on this topic from the engineering side. "It's hard!". "Managers just don't understand".
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?
This is it. I'm a hardcore engineer at heart who has a lot of these sales, marketing, and product folks as friends, and can attest to the fact that they also have constraints.
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.
Presidents are technically timeboxed, at least in the US.
My estimation technique is to completely ignore the nature of the task, and instead just try to figure out the highest number the person asking will accept.
Funny, their technique is to completely ignore the nature of the task and ask for the smallest possible number you will accept.
Estimates are tricky because different manager roles and different personalities bias toward totally different/incompatible concepts of what an estimate actually means. The author's article is conflating realistic and pessimistic estimates:
- 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.
https://github.com/SixArm/project-management-rope-estimate
Sounds like they need curves (probability distributions), not point estimates.
+1. I wrote myself a script that does this with distributions based on my personal time tracking data for doing certain tasks.
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.
I once tried to give interval range estimates, the manager said "I cannot work with that, give me a single number". (And when I gave a single number, he said "that is much too long" and tried to negotiate it down to 10 times shorter). Happy to be out of there.
In my direct personal experience, for me it was 1969 during my first major gig. I remember one project, called the March 1 system, that slowly came into being sometime that October, if my memory serves me correctly. There was tension, of course. This was exacerbated by having to work nights to get access to the system to continue development.
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.
My technique is to give an estimate with error bars. Something like 6 weeks plus or minus 2. That then leads into discussion as to what is unknown/undefined leading to the uncertainty. Sometimes the error bars are larger than the estimate because I know there will be endless feature creep and UI revisions for something like "analytics". And sometimes the number could be negative like 6 weeks plus or minus 8. That is when the functionality already exists (eg the data is already there - you can already load it into Excel and a pivot table) and could be sufficient.
At my very first job out of college,¹ the VP who led the division that I was part of invited me into his office (I think there was someone else from the team, but this is 34 years ago so who knows) and talked about a little game he had encountered about estimates. He gave us a list of 20 things to estimate with 95% confidence (the only one I remember was the weight of a 747), all given as a range. If we did it right, we would get 19 of the 20 correct. The point was to set the range large enough that you could be confident about the answer.
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.
I would say that the trend against actual agile and towards waterfall (PRDs are totally en vogue) suggests that deadlines are how most company management looks at this. Definitely not suggesting it is right, but "really aggressive 'estimates' (that are accurate beyond human ability) you can plan on", aka deadlines, are expected of any product/engineering org today.
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.
When I give an estimate, I always reiterate that it's just an estimate that is based on limited and incomplete information, and that the real number can be more or less. If they don't like it, they're free to put someone else on the project.
> When did estimates turn into deadlines?
In my personal experience: the first time I gave what could be construed as an official estimate.
The deadline portion come in when someone expects to pay for the work or to pay for the opportunity cost for the work not being completed...
And that someone usually needs to get some information to me by a certain time for my estimate to be reliable, and often doesn't. Or they need to not change the plan half way through and expect the same delivery time. Or needs to understand that when I say two tasks will take about a day each, no I can have both done by tomorrow. And do on, and so forth.
And yet Deloitte continues to exist and overcharge and overrun deadlines, and the economy, I'm told, is still doing quite well. Maybe this is all kayfabe and it doesn't actually matter.
In my experience, there are two different reasons for why I get asked for estimates.
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.
I normally only commit to "We will give an update in X (minutes/hours) to make sure we understand the problem first. Then start giving estimated timelines in ranges with specific call outs for updates and possible changes to the timeline.
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.
That's cool that they went to Sokcho!! Not many people go to Sokcho but imo it's the best city in Korea, the vibes there are on point, nobody really speaks English and it's pretty dead for the most part, but I really love Sokcho for the vibes, it's maybe the place i've felt the most at peace in my life. If you ever get the chance, I recommend Sokcho. :)
I visited Sokcho a few months ago! I agree with you, it just has such a nice and chill vibe that makes you be at peace, and lot's of interesting history in relations to North Korea. It was also really nice to go for a bike ride around the big lake that is there.
It's really simple. To succeed you need to look good in person and on paper. Under estimate and it can blow up in your face. Over estimate and you start to look incompetent. Fail to walk the tight rope and you'll soon be laid off. Succeed and you'll survive long enough to get laid off anyway when the next recession hits.
Estimates have always been deadlines. I've noticed it since at least 1999. Either your estimate goes up a certain number of management levels and then they don't want to lose face so you are stuck with it. Or a salesperson has seen it and promised it to customer and nobody wants to be the one that loses the deal so you are stuck with it.
Working in smaller steps is how you should build software. Constantly get feedback and re-evaluate what you're working on with other members of the team. Instead of giving an estimate, use t-shirt size.
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"?
but what if I’m working on something meaningful?
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.
Feedback does not need to be on a MVP, it can be given before that from your fellow engineers. That said there are tasks which really take a lot of research before even fellow engineers can give feedback.
Agile pretty much throws out estimating anything bigger than a sprint. Even then, points don’t mean time and velocity can be wild for a mature team.
I don't need constant feedback, I mostly need to be left alone to do the actual work. Problem is, the Cult of Agile gets nervous by the third daily standup where you just say you're still working on the same thing, because everyone knows no programming activity ever takes more than a large t-shirt's worth of days, however many that is.
These are all just tricks to reduce cost and make sure you get things done. You have competing constraints:
# 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.
Even worse -- giving a thorough estimate, having the other party decline and reply with a different, significantly shorter estimate, and then turning their new estimate into your new deadline. Woof!
I learned how to manage client expectations from Scotty in Star Trek: https://youtu.be/L3jXhmr_o9A
This is especially problematic in early business when the team is small and manager act with same policy/process as when at BigCo.
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.
David Parnas wrote in A Rational Design Process (1985) [1] that accurate estimates are essentially unattainable, but we should try anyway. The point is, I think, that the ceremony of a structured process facilitates communication better than no ceremony.
[1] https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
Nobody is going to fix the problem without fixing the culture, which isn't easy to do.
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.
Multiply your original estimate by 3, works most of the time
Heuristics I'd learned was "double the time and bump the unit".
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'm not sure where this turned up, but it's a long time ago, going on three decades.)
That means it was 1.5 years (wall clock) ago right?
I like this method.
So 1 year -> 2 decades?
Yes.
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.).
Then you get the dreaded can you explain why it takes so long, or I asked engineer xyz and they gave a different estimate, where is the complexity etc.
If you already asked someone, I'm not needed here so I'm going back to work on project Y that already is late enough.
I prefer pi myself. For the sort of false precision that managers love.
I've heard "multiply by 2, use next time unit" rule. So 1 hour -> 2 days, 2 weeks -> 4 months, etc..
Montgomery Scott recommends 4 instead.
A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc.
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.
> A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc.
I don't know. Going from 8 hours => 16 days seems like quite the markup.
The biggest surprise to me was the project managers and leads who refused the opportunity for going from the big numbers to the small one by allowing a faster development architecture.
By the book admiral, hours could seem like days.
Multiply by π — it's more accurate.
Accurate and precise is different things :)
Of course you’re right, however:
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.
I definitely relate to the basic issue of estimates with my one-person consulting projects. The bit they didn't mention is: who pays for the cost of the inspections and analysis? In software, it can take a long time to analyse the requirements and the solution, in order to come up with an estimate (or fixed quote), and I find it awkward trying to get paid for that time.
Do a roadmap. Fixed scope small project that you get paid for where you define requirements. Deliverable is a functional requirements doc. It derisks the project for them, and gives you more confidence when quoting a fixed scope fixed price project. You just don’t guarantee timeline. I’ve been doing it for over a decade - it works wonders.
What is the total cost of these projects and how much are you typically charging for the requirements doc?
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?
Best way but hard to find clients open to this as it requires more trust especially if it starts to drag on.
When managers refused to accept that we just can't predict the future of the creative work that is software design and implementation.
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.
I was asked to estimate a major project after a month of onboarding and such, and despite being lied to that the deadline was flexible, management decided the estimate was a suicide pact. Best part is: we all got laid off right as we finished up most of the work.
So yeah. Predicting the future is hard.
When incompetent management who scam their sorry asses to the top for a lick of the brass ring before getting their asses kicked to the curb became the norm.
This is a problem people and we're not impressed.
when an external / vendor team picks a project...
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
> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate?
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.
Also, insurance does do stuff like that.
They do, I considered adding that, but felt like it detracted from the point.
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.
Estimates turned into deadlines around the time oneone came up with the concept of an estimate.
Sometime around 1956 at a guess.
The problem of estimates as they exist in a "Agile" process - they force decisions to be made when the least amount of empirical data is available. Then once work starts and information starts flowing in, you can't change your estimate. The scientific method is explicitly banned! This is often by design; data-driven decisions are incompatible with management-vibe-driven decisions.
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.
A lot of ink has been spilled on this topic.
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.
You're correct to a degree, but IME it's a discipline issue, not a skill issue as such.
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.
> It's a skill issue.
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).
> 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
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.
That's a narrow view of what surgery entails and also a grand interpretation of what professional programming actually looks like.
Yes I think you're right about it being based on experience.
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.
It's literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason.
Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or unrecognized systemic factor
When I cut open my ceiling to fix a plumbing issue I didn't know what I was going to find exactly, but I had a pretty good idea of the possibilities. My estimate for how long the fix would take was pretty close.
Software is the same thing. There are unknowns but there aren't unlimited possibilities.
It's a great analogy, but I think it's the kind of analogy that works on the surface and not in the details most of the time due to a) much more codification of practice in construction and b) more "fixed" knowledge of what's likely based on location and build era of the home, whereas software is much more dynamic and often subject to individual whims of developers or management.
If you're hiring architects and engineers to design and build your home, you might already have a pretty good idea of the home you want. The people you've hired provide estimates on cost and timing based on solidly known quantities. They've put in a basement like that before. They've worked with your weird materials. Their vendors report on material status daily.
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.
I guess I just don't buy that software is full of unknowns whereas construction is not.
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.
You're framing the problem in terms of mathematical expected value (probability and penalty/reward), but the business environment in which software operates is fundamentally complex (see below).
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.
No, it is a funding issue. Nobody wants to pay software engineers for actually doing prestudies to learn enough to do a proper estimate. They want a good estimate but do not want to pay for it.
Nonsense. Code is copy-pasteable; other things are not.
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.
Building brick walls is easy to estimate not because it is physical labor but because the company has done it many times before. Ask a construction company to estimate a unique one-off job and they will most likely fail. And that is despite them getting a lot of resources for investigating and planning which software engineers almost never get.
Yes exactly this. Perhaps when I said "skill issue" I should have said "experience" instead as another poster suggested.
>that hurt will not go away anytime soon
Feel the Bern.
When marches were replaced with sprints.
> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too.
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.
This is a very good comment and does reflect my experience. As engineers, we're the only people who can estimate something close enough, and it becomes our job to do that while taking into account the risks.
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.
Thank you! And yeah, I think a lot of software engineers miss the forest for the trees in assuming that estimates are "only estimates", in what is implicitly assumed by others (who may not have as much context) when eg communicating dates, and in the assumptions they make regarding constraints that may not actually be constrained (eg the ability to add more people to the project or partially release/launch it with reduced scope, with the remainder to be added later). It's like, people forget that a few weeks of one engineer's time costs their employer tens of thousands of dollars, and that multi-quarter/multi-person projects literally are $1mm-$10mm+ endeavors.
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.