11 ms·

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The differe

The issue with estimates are expectations. While nobody acknowledges it, you're not actually asked for an estimate, you're being asked for a quote. The difference is when you're asked for a quote, you're asked how much you will be charging, with the expectations that you'll be willing to eat into your own margins to give a lower quote. That's why it's a negotiation, where you negotiate how much extra effort, time and headcount you're willing to give, how much tech dept you're willing to take, etc., for the privilege of getting their business. If you see it for what it really is, you'll see that it works pretty well actually. The business gets more out of you for less to them. It was never about having an accurate timeline or helping with planning or prioritizing, and always about negotiating a better contract with the dev team. Now keep in mind that the "business" in this case is a person who need to report that through their amazing prowess of administration and management, they personally managed to get X feature out during their last review cycle at Y cost with impact Z. This person will not need to deal with developer satisfaction, retention and performance. They will not need to deal with the impact the lower margins they pushed for had on the next feature delivery, or the continued maintainance of the systems. And if the dev team had to lower the quality too much in order to meet the quote they put out, that will be 100% their fault, the "business" will know not to use them for their next contract, or they'll expect the dev team to take on fixing all the issues at their own expense once more.

quickthrower2 6y ago
That is the degenerate scenario, but it’s not always true. Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it. And I’ve also seen wise use of estimation but that is rarer!
- didibus 6y ago
  > And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. All you need is relative sizing between requests. This seems twice as much work as that but gives us half the benefit. Ok probably we shouldn't do this one first. And even then, often time impact is all you need for priorities. Like who cares what takes you longer, if you just focus on building the next most impactful thing you'll very often succeed. The question of: "When are we going to be done this?" Is almost always irrelevant except for what I mentioned "asking for a quote". Like, who cares when it's done? What else you'd rather we do? I can tell you if your alternative will be any faster or not. And is this not the most impactful thing? If so, let's finish it and stop slowing us down with these irrelevant questions. Now for headcount, it's the same thing. Look how much you did last year with what headcount. Ask yourself if what you're hoping to do this year is of the same relative size, twice as big, half as big, or smaller? And then plan headcount accordingly. If twice as big, double head count. Overtime you'll learn if twice as big requires doubling headcount or 1.5x or 1.2x or 2.3x etc.
  - jeffreygoesto 6y ago
    Get something ready for Christmas business? Get a car on the road? Finish the cruise ship in time? ...
    - didibus 6y ago
      > In the context of software development? While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing". Is that correct? Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?" That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example. My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.
      - x0x0 6y ago
        Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going. There's tons of things that require broadly knowing when X is going to be done beyond capacity issues.
        imtringued 6y ago
        If you create low quality estimates willy nilly then don't be surprised that you will break them.
snarf21 6y ago
The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward. These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"
- corry 6y ago
  'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc). Engineering is obviously different... what's the measure? LOCs? Obviously not... Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.
  - didibus 6y ago
    I think you're talking about goals, which isn't the same as estimates. A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area. But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.
    - 6y ago
xyzelement 6y ago
I never experienced the dynamic you are talking about. Sounds like your workplace is terrible. I've almost always had business partners that were just that - partners - invested in the product and the team long term. I am the same way now that I am "the business." Estimation is a useful forcing exercise for thinking through what something takes, identifying risks and hard parts and deciding upfront what to do about them. It also becomes a good measure of people's integrity - what they do once it's apparent the estimate is off. 100% of the time, when engineering came back saying "we underestimated X, it's much harder" - it was totally fine.
daanlo 6y ago
Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their marketing budget. The customer care agent that gets shouted at because feature xyz is broken / not working as the customer expects, would like to give the customer an answer when it will be fixed. The customer care manager is also worried about her team members‘ retention. So having a rough or concrete time line / roadmap is helpful for these parts of the business. I also believe that a feature request is incomplete without an estimate. It is like a friend asking you to go buy him a car. What does he need a 3000$ subaru from 2003 or a 2021 Ferrari? Of course the friend can give you an insanely accurate list of specifications, but giving you a budget + some guidelines will probably be more effective for your friend and more fun for you. Especially considering that you know much more about cars (read software) than your friend. Knowing the budget you will be able to make much better choices. If you take the allegory of a quote (which I think is correct) then you need to consider that the haggling process always also includes scope of the product. „I‘ll give you 5000$ for the car, but only if you include a free car wash“. And you can always use an estimate as defense against feature creep. „We are running low on budget, I suggest descoping xyz into the next iteration. Otherwise we won‘t be able to ship on time“. If on time is not defined then you can never have this conversation.
- cheschire 6y ago
  And to continue your metaphor, most software estimation comes from someone describing a car they like, and based on your mock ups you and others decide on a price, how long is acceptable to build, etc. So then you goto build the car and everything's going great till you find out that the latest research shows the specific design of engine you're using doesn't work with the eco friendly fuel that is now being mandated by the government. And suddenly killing cows is uncool so you have to change all your chairs to fabric or source fake leather, but half of your company thinks that endorsing fake leather is hide-appropriation and you're now spending a third of your time in HR going through training. And eventually you get about a week out from delivering the car and the customer calls your PM and says they want the car to have a top speed 30mph over the original specs while maintaining the fuel efficiency rating. And the doors should swing up, instead of out. Like billionaires'.
- 6y ago
koonsolo 6y ago
I once had a manager that thought he could negotiate estimates. That is like negotiating with the weatherman about the weather. Sure, maybe in the end you can convince them it will be finished sooner. But the fact is that it really doesn't change reality.
- benhurmarcel 6y ago
  I find it much less stressful to deal with since I've made peace with the fact that some managers want to be lied to.
  - discreteevent 6y ago
    Be careful because those lies become expectations for everyone that manager speaks to.
- lixtra 6y ago
  Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another. - does it have to be instant or can we run it as a batch - maybe it’s enough to have this tool in English only Etc.
  - IanCal 6y ago
    I think this is a vital point. Estimates help narrow down what is important and what isn't. Maybe you want features x, y and z. If it takes a day then X is worthwhile, if it's going to take a month don't bother. Z must be done so if that's going to take a long time we need to drop y. One of the best product owners I've worked for would often ask for estimates and base plans and features from those. Some things would be easy technically and valuable, others harder and just a nice to have (but worth it if it only pushed things back a day).
    - ryandrake 6y ago
      I remember an interview at a well known tech-ish company where the question started out as “Estimate this project” with a good description of the scope and team. After I said something like 4 months, interviewer said, “OK. The CEO says it needs to be done in 2 weeks. What now?” I thought this was a basic project management question about trading off quality, scope, schedule, staffing, etc. and offered the usual suggestions of cutting scope (nope CEO demands entire scope), cutting quality (nope can’t compromise quality), increasing the team, contracting out, reprioritizing and realeasing P1s in 2 weeks (nope, nope, nope). Obviously I didn’t get the job. Later I learned from an acquaintance inside the company that the right answer was probably “Work the team 24 hour days, nights and weekends, for 2weeks to deliver what the CEO wants. I think I dodged a bullet there.
rswail 6y ago
I call it the "What's the earliest date you can't prove you won't be finished by?" management question.
swiftcoder 6y ago
And of course once the dev team realises that their "estimates" are actually being treated as quotes, and that their ability to find time to vacation, sleep, or even see their families will be contingent on their quote being sufficiently padded... Now you have a recipe for a highly adversarial relationship between management and engineering throughout the planning and development process.
bjoernbu 6y ago
There may be a lot of uncerntainty in Data Science and ML projects. However, recently I started feeling like I actually have it better than someone from pure software engineering sides of things: For either, there is often a function from time spent to quality. 100% perfection is basically impossible and before that the function increases very slowly, seemlingly logarithmicly. For SWE, expectations are often close perfect solutions. Too greedy effort estimations cause a lot of trouble. For DS/ML, however, perfect is usually off the table and this fact is widely (not universally though) accepted. When it is accepted to give estimates in this way, suddenly there no harm from being quoted on it and I really don't mind to give estimates anymore, where I just make a guess at a good 80/20 point. If I am wrong with that point, chances are nobody on the outside/higher up ever knows. This may be different in domains where very clear targets have to be met (e.g., "self driving cars that pass lawmaker's requirements for use on the streets") and then I'd guess it is a true nightmare. Like this, I never felt overly pressured by ML/DS deadlines over the last years. Some things were great successes, sometimes the quality wasn't great enough and projects were stopped or customers left. But there never really was a case where anyone thought that working extra long might have been an option to meet higher expectations. I don't really have a solution for SWE, I don't really see how one would sell something like "I can do it in X time and it will only crash / stop working / make mistakes / become too slow / have vulnerabilities so often. More time will lead to fewer problems". This just isn't what's expected. But at least for complex systems and security vulnerabilities, I'd argue it is actually quite true. Guarantees for 100% perfection just aren't realistic. Avoiding the most obvious pitfalls is done rather quickly and the more time spend, the more is needed for further improvements.
ohthehugemanate 6y ago
This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level. TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out. Personally I offer my customers to either pay by the week, or pay by extremely fixed scope with a 3 month definition period up front and a 50% buffer above the estimate. I stress that paying by the sprint lets them change objectives at any time, gives them an always-current report of how much "effort budget" they have left to work with, and guarantees they only pay for what they use. That felt like a risky move the first time I did it, but I never lost any business over it.
- zyber 6y ago
  I think that everyone still converts what-ever-unit used to time. For example, from one of my earlier jobs, we had "T-shirt"-size units, ranging from XS to XL. It took two weeks after introducing them until someone figured out that XS is two hours, so in a sprint you should be able to do $SPRINT_DURATION / 2 XS tasks. And then the person figured that S was equal to, say 4 hours and so on and we were back on square one. But we didn't estimate in concrete time units. /s
stiray 6y ago
I have noticed this article during the "Parkinson's law of triviality"[1] meeting (within phase where technical guys are typically silent) and almost started laughing when someone asked about "over the thumb effort estimates" (that are always becoming carved into rock deadlines). It really made my day :) [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
parentheses 6y ago
Agreed that often times estimates are mistaken for quotes. Aside from that, my personal experience has been that those who work adjacent to software understands that there’s an element of uncertainty. If those that we work with don’t, it is on us to educate. Improving estimation will eventually improve quality of life for all involved.
JamesBarney 6y ago
I don't really understand what type of environment you're talking about. Some parts seems to hint the devs are an outside consulting shop, and some parts hint that the devs are on an internal team. Most internal teams can blow through dev deadlines over and over again for years without any real repercussions. And while outside dev shops can't blow through estimates like internal teams the individual devs usually can unless they're in a leadership role.

quickthrower2 6y ago

That is the degenerate scenario, but it’s not always true. Often I see this haggling down of estimates and then microagression if estimates are not met but no need to work for free to make up for it. And I’ve also seen wise use of estimation but that is rarer!

didibus 6y ago
> And I’ve also seen wise use of estimation but that is rarer I've got a question for you here, what is a wise use of estimation? What problems are estimates the ideal solution for? In the context of software development? I can think of only two: planning headcount and priorities (aka planning the order in which you do things). When you focus on those problems, you realize there's no need for an accurate estimate. All you need is relative sizing between requests. This seems twice as much work as that but gives us half the benefit. Ok probably we shouldn't do this one first. And even then, often time impact is all you need for priorities. Like who cares what takes you longer, if you just focus on building the next most impactful thing you'll very often succeed. The question of: "When are we going to be done this?" Is almost always irrelevant except for what I mentioned "asking for a quote". Like, who cares when it's done? What else you'd rather we do? I can tell you if your alternative will be any faster or not. And is this not the most impactful thing? If so, let's finish it and stop slowing us down with these irrelevant questions. Now for headcount, it's the same thing. Look how much you did last year with what headcount. Ask yourself if what you're hoping to do this year is of the same relative size, twice as big, half as big, or smaller? And then plan headcount accordingly. If twice as big, double head count. Overtime you'll learn if twice as big requires doubling headcount or 1.5x or 1.2x or 2.3x etc.
- jeffreygoesto 6y ago
  Get something ready for Christmas business? Get a car on the road? Finish the cruise ship in time? ...
  - didibus 6y ago
    > In the context of software development? While your examples I'm not sure are super relevant from a software development context. I think you're pointing out that the estimate would help you decide when you need to start so you are done before the "real life events that needs the thing". Is that correct? Like for example I'm not sure it's useful to learn that no, you will not be ready for the Christmas event. Or no the cruise ship will not be ready in time. But it might be useful to know: "If I want to be ready for the Christmas event when should I get started and how many developers do I need?" That's a good example I guess, though I haven't seen this issue arise very often in software. I could imagine someone needing to know when to start feature freeze and prep work for scaling up leading up to a big sale event if you run an online store for example. My take on this is that asking devs to guess that time would obviously not work. And if you did this type of forecasting for any other discipline, you'd instead gather historical data about how much time things took in the past and plot that to forecast how much you'd think it takes in the future. Which is a process that can be done without needing to ask a dev for their personal not data based guesstimate.
    - x0x0 6y ago
      Inter-team dependencies. Marketing pushes. Customer commitments. New sales dependent on certain features. Building features to increase TAM. Partner commitments for interoperability / joint deployments. Even presentations of your roadmap to customers and prospects to get them bought into your vision of where the product is going. There's tons of things that require broadly knowing when X is going to be done beyond capacity issues.
      - imtringued 6y ago
        If you create low quality estimates willy nilly then don't be surprised that you will break them.

snarf21 6y ago

The issue is that you are being asked to estimate something that has never been done before. Even houses always go over time and money and that is fairly straight forward. These days, I only give estimates in terms of units but without numbers. Hours, days, weeks, months, quarters or years. Some relatively small number of those units. If you want a quote it will take an extra 1/4 of the estimate worth of time for an exact timeline. I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"

corry 6y ago
'I really wish we would treat sales people the same way. "How much money is this contract for? What date will it be signed?"'. In well-run sales teams, that is exactly what happens. There is a constant move towards more accuracy and tightness in forecasting. In poorly run sales teams, the reps basically set their owns quotas (padded, of course, to mitigate against massive uncertainty) and then are very imprecise at managing the WIP. Which sounds like a poorly run engineering team too. In sales, though, at least there is a very objective measure ($$$ closed) at the end of the period. Also, the period is fixed typically (months, quarters, etc). Engineering is obviously different... what's the measure? LOCs? Obviously not... Edit: just to be clear, I'm saying that well-run sales teams and well-run engineering teams probably have a lot in common, not that they are exactly the same.
- didibus 6y ago
  I think you're talking about goals, which isn't the same as estimates. A well run sales team, like a well run dev team do benefit from goals. Like increase X by Y. That's because it can guide your decision process of what you'll spend your time on and what you won't. It can also push for focused innovation around a particular area. But I think OP meant what if you asked the sales team: How much time will it take you to close the deal with X? Would they be able to estimate that? Which is different from asking them: "Try and close X Y% faster than it took us to close Z last time." The former would be asking for an estimate, the latter would be setting a goal.
  - 6y ago

xyzelement 6y ago

I never experienced the dynamic you are talking about. Sounds like your workplace is terrible. I've almost always had business partners that were just that - partners - invested in the product and the team long term. I am the same way now that I am "the business." Estimation is a useful forcing exercise for thinking through what something takes, identifying risks and hard parts and deciding upfront what to do about them. It also becomes a good measure of people's integrity - what they do once it's apparent the estimate is off. 100% of the time, when engineering came back saying "we underestimated X, it's much harder" - it was totally fine.

daanlo 6y ago

Software doesn‘t exist in a vacuum. The marketing team needs to know when the landing page / qr code (whatever) is implemented, because they need to plan their marketing budget. The customer care agent that gets shouted at because feature xyz is broken / not working as the customer expects, would like to give the customer an answer when it will be fixed. The customer care manager is also worried about her team members‘ retention. So having a rough or concrete time line / roadmap is helpful for these parts of the business. I also believe that a feature request is incomplete without an estimate. It is like a friend asking you to go buy him a car. What does he need a 3000$ subaru from 2003 or a 2021 Ferrari? Of course the friend can give you an insanely accurate list of specifications, but giving you a budget + some guidelines will probably be more effective for your friend and more fun for you. Especially considering that you know much more about cars (read software) than your friend. Knowing the budget you will be able to make much better choices. If you take the allegory of a quote (which I think is correct) then you need to consider that the haggling process always also includes scope of the product. „I‘ll give you 5000$ for the car, but only if you include a free car wash“. And you can always use an estimate as defense against feature creep. „We are running low on budget, I suggest descoping xyz into the next iteration. Otherwise we won‘t be able to ship on time“. If on time is not defined then you can never have this conversation.

cheschire 6y ago
And to continue your metaphor, most software estimation comes from someone describing a car they like, and based on your mock ups you and others decide on a price, how long is acceptable to build, etc. So then you goto build the car and everything's going great till you find out that the latest research shows the specific design of engine you're using doesn't work with the eco friendly fuel that is now being mandated by the government. And suddenly killing cows is uncool so you have to change all your chairs to fabric or source fake leather, but half of your company thinks that endorsing fake leather is hide-appropriation and you're now spending a third of your time in HR going through training. And eventually you get about a week out from delivering the car and the customer calls your PM and says they want the car to have a top speed 30mph over the original specs while maintaining the fuel efficiency rating. And the doors should swing up, instead of out. Like billionaires'.
6y ago

koonsolo 6y ago

I once had a manager that thought he could negotiate estimates. That is like negotiating with the weatherman about the weather. Sure, maybe in the end you can convince them it will be finished sooner. But the fact is that it really doesn't change reality.

benhurmarcel 6y ago
I find it much less stressful to deal with since I've made peace with the fact that some managers want to be lied to.
- discreteevent 6y ago
  Be careful because those lies become expectations for everyone that manager speaks to.
lixtra 6y ago
Typically there are many dimensions to a solution, the negotiation can be about trading one dimension for another. - does it have to be instant or can we run it as a batch - maybe it’s enough to have this tool in English only Etc.
- IanCal 6y ago
  I think this is a vital point. Estimates help narrow down what is important and what isn't. Maybe you want features x, y and z. If it takes a day then X is worthwhile, if it's going to take a month don't bother. Z must be done so if that's going to take a long time we need to drop y. One of the best product owners I've worked for would often ask for estimates and base plans and features from those. Some things would be easy technically and valuable, others harder and just a nice to have (but worth it if it only pushed things back a day).
  - ryandrake 6y ago
    I remember an interview at a well known tech-ish company where the question started out as “Estimate this project” with a good description of the scope and team. After I said something like 4 months, interviewer said, “OK. The CEO says it needs to be done in 2 weeks. What now?” I thought this was a basic project management question about trading off quality, scope, schedule, staffing, etc. and offered the usual suggestions of cutting scope (nope CEO demands entire scope), cutting quality (nope can’t compromise quality), increasing the team, contracting out, reprioritizing and realeasing P1s in 2 weeks (nope, nope, nope). Obviously I didn’t get the job. Later I learned from an acquaintance inside the company that the right answer was probably “Work the team 24 hour days, nights and weekends, for 2weeks to deliver what the CEO wants. I think I dodged a bullet there.

rswail 6y ago

I call it the "What's the earliest date you can't prove you won't be finished by?" management question.

swiftcoder 6y ago

And of course once the dev team realises that their "estimates" are actually being treated as quotes, and that their ability to find time to vacation, sleep, or even see their families will be contingent on their quote being sufficiently padded... Now you have a recipe for a highly adversarial relationship between management and engineering throughout the planning and development process.

bjoernbu 6y ago

There may be a lot of uncerntainty in Data Science and ML projects. However, recently I started feeling like I actually have it better than someone from pure software engineering sides of things: For either, there is often a function from time spent to quality. 100% perfection is basically impossible and before that the function increases very slowly, seemlingly logarithmicly. For SWE, expectations are often close perfect solutions. Too greedy effort estimations cause a lot of trouble. For DS/ML, however, perfect is usually off the table and this fact is widely (not universally though) accepted. When it is accepted to give estimates in this way, suddenly there no harm from being quoted on it and I really don't mind to give estimates anymore, where I just make a guess at a good 80/20 point. If I am wrong with that point, chances are nobody on the outside/higher up ever knows. This may be different in domains where very clear targets have to be met (e.g., "self driving cars that pass lawmaker's requirements for use on the streets") and then I'd guess it is a true nightmare. Like this, I never felt overly pressured by ML/DS deadlines over the last years. Some things were great successes, sometimes the quality wasn't great enough and projects were stopped or customers left. But there never really was a case where anyone thought that working extra long might have been an option to meet higher expectations. I don't really have a solution for SWE, I don't really see how one would sell something like "I can do it in X time and it will only crash / stop working / make mistakes / become too slow / have vulnerabilities so often. More time will lead to fewer problems". This just isn't what's expected. But at least for complex systems and security vulnerabilities, I'd argue it is actually quite true. Guarantees for 100% perfection just aren't realistic. Avoiding the most obvious pitfalls is done rather quickly and the more time spend, the more is needed for further improvements.

ohthehugemanate 6y ago

This is only true when estimates are in concrete units, the way we did it in the 80s and 90s. Unfortunately that still impacts contract structure today and it's hard to change on that level. TFA is talking about estimates inside projects, which are not time based anymore in any environment that cares about the problems you laid out. Personally I offer my customers to either pay by the week, or pay by extremely fixed scope with a 3 month definition period up front and a 50% buffer above the estimate. I stress that paying by the sprint lets them change objectives at any time, gives them an always-current report of how much "effort budget" they have left to work with, and guarantees they only pay for what they use. That felt like a risky move the first time I did it, but I never lost any business over it.

zyber 6y ago
I think that everyone still converts what-ever-unit used to time. For example, from one of my earlier jobs, we had "T-shirt"-size units, ranging from XS to XL. It took two weeks after introducing them until someone figured out that XS is two hours, so in a sprint you should be able to do $SPRINT_DURATION / 2 XS tasks. And then the person figured that S was equal to, say 4 hours and so on and we were back on square one. But we didn't estimate in concrete time units. /s

stiray 6y ago

I have noticed this article during the "Parkinson's law of triviality"[1] meeting (within phase where technical guys are typically silent) and almost started laughing when someone asked about "over the thumb effort estimates" (that are always becoming carved into rock deadlines). It really made my day :) [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality

parentheses 6y ago

Agreed that often times estimates are mistaken for quotes. Aside from that, my personal experience has been that those who work adjacent to software understands that there’s an element of uncertainty. If those that we work with don’t, it is on us to educate. Improving estimation will eventually improve quality of life for all involved.

JamesBarney 6y ago

I don't really understand what type of environment you're talking about. Some parts seems to hint the devs are an outside consulting shop, and some parts hint that the devs are on an internal team. Most internal teams can blow through dev deadlines over and over again for years without any real repercussions. And while outside dev shops can't blow through estimates like internal teams the individual devs usually can unless they're in a leadership role.