13 ms·

When did estimates turn into deadlines?

327 points by alexzeitler 2y ago

baxtr 2y ago
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.
- floren 2y ago
  > 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?
  - dhosek 2y ago
    There’s a whole generation of developers who have internalized this.
    - ikiris 2y ago
      There’s a whole generation of management who have caused this due to their own behavior.
      - deleted 2y ago
        [deleted]
  - dtgriscom 2y ago
    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.
    - EasyMark 2y ago
      I do something similar but I use the Indiana version of 3.2 https://www.mentalfloss.com/article/30214/new-math-time-indiana-tried-change-pi-32 https://www.mentalfloss.com/article/30214/new-math-time-indi...
- darekkay 2y ago
  > the first number you put out will be remembered This is called anchoring effect, a psychological bias.
  - robocat 2y ago
    I think you meant "anchoring bias": https://www.scribbr.com/research-bias/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 https://en.m.wikipedia.org/wiki/Anchoring_effect
    - kgwgk 2y ago
      Is it? If you visit https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anchoring_bias https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anch... and follow the first link labeled Main article: Anchoring (cognitive bias) you may be surprised. Actually, you may also read the first link you sent and be equally surprised: Anchoring bias (also known as anchoring heuristic or anchoring effect) https://www.scribbr.com/research-bias/anchoring-bias/#what https://www.scribbr.com/research-bias/anchoring-bias/#what
- vander_elst 2y ago
  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.
  - baxtr 2y ago
    Nice algorithm!
    - dizhn 2y ago
      Governments around the world must be using it too where a year turns into 3 decades.
NikkiA 2y ago
Sometime around 1956 at a guess.
nextworddev 2y ago
Multiply your original estimate by 3, works most of the time
- loloquwowndueo 2y ago
  Montgomery Scott recommends 4 instead.
  - deleted 2y ago
    [deleted]
  - ben_w 2y ago
    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.
    - mmcdermott 2y ago
      > 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.
      - ben_w 2y ago
        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.
  - ikiris 2y ago
    By the book admiral, hours could seem like days.
- rectang 2y ago
  Multiply by π — it's more accurate.
dspillett 2y ago
> When did estimates turn into deadlines? In my personal experience: the first time I gave what could be construed as an official estimate.
- readthenotes1 2y ago
  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...
  - takemetoearth 2y ago
    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.
  - dspillett 2y ago
    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.
OutOfHere 2y ago
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.
redleggedfrog 2y ago
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.
- aoeusnth1 2y ago
  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.
  - Moru 2y ago
    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.
  - eminent101 2y ago
    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.
snakeyjake 2y ago
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.
ahallock 2y ago
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"?
- dijit 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - jeltz 2y ago
    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.
- goalieca 2y ago
  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.
- takemetoearth 2y ago
  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.
kanisae 2y ago
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.
tartoran 2y ago
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...
rogerbinns 2y ago
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.
- dhosek 2y ago
  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.
avidiax 2y ago
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.
- trashtester 2y ago
  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.
  - avidiax 2y ago
    > 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).
LeifCarrotson 2y ago
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.
- analog31 2y ago
  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.
  - Tostino 2y ago
    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.
deleted 2y ago
[deleted]
tyingq 2y ago
"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.
- brookst 2y ago
  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.
  - tyingq 2y ago
    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.
- bargainbot3k 2y ago
  [flagged]
- SoftTalker 2y ago
  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.
kelseyfrog 2y ago
> 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.
- bigstrat2003 2y ago
  Also, insurance does do stuff like that.
  - kelseyfrog 2y ago
    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.
stevage 2y ago
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.
- kareemm 2y ago
  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.
  - stevage 2y ago
    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?
  - intelVISA 2y ago
    Best way but hard to find clients open to this as it requires more trust especially if it starts to drag on.
neom 2y ago
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. :)
- opdahl 2y ago
  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.
wglb 2y ago
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.
renewiltord 2y ago
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.
GoToRO 2y ago
When marches were replaced with sprints.
- deleted 2y ago
  [deleted]
albert_e 2y ago
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
jph 2y ago
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 https://github.com/SixArm/project-management-rope-estimate
- the8472 2y ago
  Sounds like they need curves (probability distributions), not point estimates.
  - senkora 2y ago
    +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) https://en.m.wikipedia.org/wiki/Bootstrapping_(statistics) It isn’t too hard to do, and I can confirm that it works reasonably well.
  - skirmish 2y ago
    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.
throwaway106382 2y ago
I learned how to manage client expectations from Scotty in Star Trek: https://youtu.be/L3jXhmr_o9A https://youtu.be/L3jXhmr_o9A
jappgar 2y ago
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.
- HelloMcFly 2y ago
  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
  - jappgar 2y ago
    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.
    - HelloMcFly 2y ago
      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.
- jeltz 2y ago
  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.
- 2y ago
djbusby 2y ago
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.
severilon 2y ago
[dead]
russellbeattie 2y ago
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.
Aeolun 2y ago
Estimates turned into deadlines around the time oneone came up with the concept of an estimate.
pseudosavant 2y ago
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.
yoelhacks 2y ago
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?
- cplat 2y ago
  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.
  - takemetoearth 2y ago
    Presidents are technically timeboxed, at least in the US.
j1elo 2y ago
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 https://news.ycombinator.com/item?id=37965582 My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniques, used in the process. Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4. 2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.
- mjevans 2y ago
  The X factor is likely correct, but needs some additional notes. Include additional X quantity for unknown unknowns, not just the known unknowns.
resters 2y ago
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.
AdieuToLogic 2y ago
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. 0 - https://www.youtube.com/watch?v=MhbT7EvYN0c https://www.youtube.com/watch?v=MhbT7EvYN0c 1 - https://www.goodreads.com/book/show/30650836-noestimates https://www.goodreads.com/book/show/30650836-noestimates
jimjimjim 2y ago
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.
halfcat 2y ago
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/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...
softwaredoug 2y ago
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.
- ristos 2y ago
  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.
weitendorf 2y ago
> 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.
magicalhippo 2y ago
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.
MrMcCall 2y ago
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.
- takemetoearth 2y ago
  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.
mydriasis 2y ago
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!
ristos 2y ago
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.
disambiguation 2y ago
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.
spjt 2y ago
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.
- bberrry 2y ago
  Funny, their technique is to completely ignore the nature of the task and ask for the smallest possible number you will accept.
sublinear 2y ago
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.
hoseja 2y ago
>that hurt will not go away anytime soon Feel the Bern.
black_13 2y ago
[dead]
perrygeo 2y ago
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.

327 points by alexzeitler 2y ago

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.

floren 2y ago
> 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?
- dhosek 2y ago
  There’s a whole generation of developers who have internalized this.
  - ikiris 2y ago
    There’s a whole generation of management who have caused this due to their own behavior.
    - deleted 2y ago
      [deleted]
- dtgriscom 2y ago
  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.
  - EasyMark 2y ago
    I do something similar but I use the Indiana version of 3.2 https://www.mentalfloss.com/article/30214/new-math-time-indiana-tried-change-pi-32 https://www.mentalfloss.com/article/30214/new-math-time-indi...
darekkay 2y ago
> the first number you put out will be remembered This is called anchoring effect, a psychological bias.
- robocat 2y ago
  I think you meant "anchoring bias": https://www.scribbr.com/research-bias/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 https://en.m.wikipedia.org/wiki/Anchoring_effect
  - kgwgk 2y ago
    Is it? If you visit https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anchoring_bias https://www.wikipedia.org/wiki/List_of_cognitive_biases#Anch... and follow the first link labeled Main article: Anchoring (cognitive bias) you may be surprised. Actually, you may also read the first link you sent and be equally surprised: Anchoring bias (also known as anchoring heuristic or anchoring effect) https://www.scribbr.com/research-bias/anchoring-bias/#what https://www.scribbr.com/research-bias/anchoring-bias/#what
vander_elst 2y ago
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.
- baxtr 2y ago
  Nice algorithm!
  - dizhn 2y ago
    Governments around the world must be using it too where a year turns into 3 decades.

NikkiA 2y ago

Sometime around 1956 at a guess.

nextworddev 2y ago

Multiply your original estimate by 3, works most of the time

loloquwowndueo 2y ago
Montgomery Scott recommends 4 instead.
- deleted 2y ago
  [deleted]
- ben_w 2y ago
  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.
  - mmcdermott 2y ago
    > 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.
    - ben_w 2y ago
      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.
- ikiris 2y ago
  By the book admiral, hours could seem like days.
rectang 2y ago
Multiply by π — it's more accurate.

dspillett 2y ago

> When did estimates turn into deadlines? In my personal experience: the first time I gave what could be construed as an official estimate.

readthenotes1 2y ago
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...
- takemetoearth 2y ago
  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.
- dspillett 2y ago
  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.

OutOfHere 2y ago

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.

redleggedfrog 2y ago

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.

aoeusnth1 2y ago
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.
- Moru 2y ago
  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.
- eminent101 2y ago
  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.

snakeyjake 2y ago

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.

ahallock 2y ago

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"?

dijit 2y ago
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.
- deleted 2y ago
  [deleted]
- jeltz 2y ago
  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.
goalieca 2y ago
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.
takemetoearth 2y ago
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.

kanisae 2y ago

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.

tartoran 2y ago

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...

rogerbinns 2y ago

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.

dhosek 2y ago
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.

avidiax 2y ago

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.

trashtester 2y ago
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.
- avidiax 2y ago
  > 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).

LeifCarrotson 2y ago

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.

analog31 2y ago
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.
- Tostino 2y ago
  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.

deleted 2y ago

[deleted]

tyingq 2y ago

"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.

brookst 2y ago
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.
- tyingq 2y ago
  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.
bargainbot3k 2y ago
[flagged]
SoftTalker 2y ago
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.

kelseyfrog 2y ago

> 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.

bigstrat2003 2y ago
Also, insurance does do stuff like that.
- kelseyfrog 2y ago
  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.

stevage 2y ago

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.

kareemm 2y ago
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.
- stevage 2y ago
  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?
- intelVISA 2y ago
  Best way but hard to find clients open to this as it requires more trust especially if it starts to drag on.

neom 2y ago

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. :)

opdahl 2y ago
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.

wglb 2y ago

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.

renewiltord 2y ago

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.

GoToRO 2y ago

When marches were replaced with sprints.

deleted 2y ago
[deleted]

albert_e 2y ago

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

jph 2y ago

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 https://github.com/SixArm/project-management-rope-estimate

the8472 2y ago
Sounds like they need curves (probability distributions), not point estimates.
- senkora 2y ago
  +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) https://en.m.wikipedia.org/wiki/Bootstrapping_(statistics) It isn’t too hard to do, and I can confirm that it works reasonably well.
- skirmish 2y ago
  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.

throwaway106382 2y ago

I learned how to manage client expectations from Scotty in Star Trek: https://youtu.be/L3jXhmr_o9A https://youtu.be/L3jXhmr_o9A

jappgar 2y ago

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.

HelloMcFly 2y ago
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
- jappgar 2y ago
  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.
  - HelloMcFly 2y ago
    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.
jeltz 2y ago
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.
2y ago

djbusby 2y ago

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.

severilon 2y ago

[dead]

russellbeattie 2y ago

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.

Aeolun 2y ago

Estimates turned into deadlines around the time oneone came up with the concept of an estimate.

pseudosavant 2y ago

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.

yoelhacks 2y ago

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?

cplat 2y ago
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.
- takemetoearth 2y ago
  Presidents are technically timeboxed, at least in the US.

j1elo 2y ago

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 https://news.ycombinator.com/item?id=37965582 My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniques, used in the process. Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4. 2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.

mjevans 2y ago
The X factor is likely correct, but needs some additional notes. Include additional X quantity for unknown unknowns, not just the known unknowns.

resters 2y ago

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.

AdieuToLogic 2y ago

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. 0 - https://www.youtube.com/watch?v=MhbT7EvYN0c https://www.youtube.com/watch?v=MhbT7EvYN0c 1 - https://www.goodreads.com/book/show/30650836-noestimates https://www.goodreads.com/book/show/30650836-noestimates

jimjimjim 2y ago

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.

halfcat 2y ago

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/fakeit.pdf https://users.ece.utexas.edu/~perry/education/SE-Intro/fakei...

softwaredoug 2y ago

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.

ristos 2y ago
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.

weitendorf 2y ago

> 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.

magicalhippo 2y ago

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.

MrMcCall 2y ago

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.

takemetoearth 2y ago
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.

mydriasis 2y ago

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!

ristos 2y ago

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.

disambiguation 2y ago

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.

spjt 2y ago

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.

bberrry 2y ago
Funny, their technique is to completely ignore the nature of the task and ask for the smallest possible number you will accept.

sublinear 2y ago

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.

hoseja 2y ago

>that hurt will not go away anytime soon Feel the Bern.

black_13 2y ago

[dead]

perrygeo 2y ago

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.