7 ms·

Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through

Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's actually my favorite part of the job. But the business invariably doesn't want to spend the time and money to do that. They'd generally much rather start with a fairly vague description of what they need and let the devs keep throwing stuff against the wall and see what sticks. Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.

stepbeek 5y ago
The business might not know enough for that estimate to be possible either. It reminds me of this quote from Andrew Wiles about mathematics: "Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. One goes into the ﬁrst room, and it’s dark, completely dark. One stumbles around bumping into the furniture, and gradually, you learn where each piece of furniture is, and ﬁnally, after six months or so, you ﬁnd the light switch. You turn it on, and suddenly, it’s all illuminated. You can see exactly where you were." [1] [1] Source: https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/ https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...
BjoernKW 5y ago
A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome. However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/ https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi... Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint. On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements. This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.
- tshaddox 5y ago
  > However, in the end, code is just a very detailed specification of the design that produces a desired outcome. Yes, exactly. The code is a technical specification that is so clear that a very dumb uncreative machine can follow it perfectly!
- EricE 5y ago
  "A common misunderstanding about software creation is that code is the desired result." Here here! If I have my product owner hat on I don't give a flip about the code itself; I'm interested in the business value a properly coded application unlocks.
snarf21 5y ago
Well said. My current rule based on experience is that estimates should only be hours/days/weeks/months/quarters/years with NO numbers. It is to give a sense of scale and effort so it could be prioritized and/or modified. If they want exact dates, then it is like you said, several days/weeks to go get an accurate date. I only wish that the sales team had to commit to closing dates the same way software teams do.
- brightball 5y ago
  I’m a big fan of avoiding numbers in estimations. The moment a number is included, people start adding them together to create metrics that don’t show any useful information.
- mtippett 5y ago
  That's actually a good hack. I tend to take a similar approach, but using approximate days in a fibonacci sequence. Start at the high end, will it take... years: NO quarters: NO months: erm... NO. weeks: maybe days: Unlikely hours: Ha. No. So you end up with a range (days?-weeks-months). That's too broad, what could go wrong to avoid making it months long project (well we could investigate X, Y, and watch for Z). What needs to go perfect for it to be days? (well we could... wait, days is unlikely). Those discussions about the high and the low to get "reasonable" confidence are super important.
  - snarf21 5y ago
    Yeah, I always think about my structure as "some small number of h/d/w/m/q/y". I count 1 week the same as 3 weeks in terms of scale. ymmv
- cpeterso 5y ago
  I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ... The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points let compare two tasks. If you try to give t-shirt sizes points (e.g. "M = 2*S"), then you might as well skip the t-shirt abstraction and just use story points.
brightball 5y ago
This is 100% accurate and it's the reason that I prefer the SAFe (Scaled Agile) approach to estimation and planning over the common Scrum approaches. Doing the bulk of your planning during a 2-3 day PI Planning event lets a lot of people dive into a few things, preparing an estimate for the coming quarter, mapping dependencies across teams, lining them up with other planned work and outlining risks to the plan. Then the developers get to explain the plan to upper management, discuss any potential revisions and get moving...with everyone on the same page. This also keeps any estimation beyond the current quarter firmly in the realm of subject-to-change. That's the most critical part of it. Tech people and business people being out of alignment on expectations is where everything goes sideways and all of the friction comes from. Out of all of the methodologies I've come across in my career, this is the only approach I've seen that really balances development realities with a level of "enough" future planning to help business people make informed decisions.
- tomrod 5y ago
  In practice, devs are still writing code on PI days.
  - brightball 5y ago
    How so?
    - tomrod 5y ago
      With computers and dev tools, trying to get the current PI complete.
      - brightball 5y ago
        If that happens you’re just supposed to include what is still to be done in the next PI while you stop everything for PI planning. There are too many people involved to just skip it to keep working.
        5y ago
dalbasal 5y ago
He can ... really really accurate estimate, ... a lot of time .. building .. verifying .. actual requirements.. designing ... solution .. validating .... process will require dev resources.. resources... people.. support team.. a lot of time.. very expensive.. scary.. and I'll be nakedly responsible for my own mistakes.. </inside head> "How about we do it that other way. You mentioned devs could keep throwing stuff against the wall. I like how that sounds."
username90 5y ago
> I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently. Of course it could be true in your case, but you can't blame the inability of software engineers in general to estimate tasks on that.
- dalbasal 5y ago
  I think of it this way. All problems that become sticky problems, got that way by being sticky. Re-writes encounter the sticky problem one way. When the spec is real, the spec is vast. "Do everything GMail does" is a lot of things. In internal business app teams, the sticky issue is that no one actually understands the business problems well enough to articulate sufficiently. There's usually very little incentive to be the spec person, on either the technical or business side. It might often be the same underlying issue. The difference with rewrites is that the "conversation" happens within tech teams, no outside player.
- sreque 5y ago
  As someone who has argued against a rewrite, lost the argument, and then proceeded to do the rewrite, I would push back strongly on the notion that we have a perfect specification, which is just "do what the old thing did". This specification is woefully incomplete, of course, just as a vague requirements document for a brand new service or product is incomplete. When someone proposes a rewrite for software, I ask him or her to think critically along the following questions: 1) What is the purpose of the rewrite? What do you hope to accomplish by it? What business objectives are furthered by the rewrite? 2) Explain in detail what is wrong the the existing code base, and why it is untenable to fix those problems piecemeal. 3) Explain in detail how the rewrite will avoid, overcome, or improve significantly on all the problems mentioned in 2). In my most recent, case, and as I expect in many others, I couldn't convince anyone to engage on any of these questions. For 1), we were told that the org planned to build significant new features on the product and the rewrite will help. However, the company's priorities changed significantly even as the rewrite was just getting started. By the time I left the company, I was not aware of any short or long-term plans to continue adding functionality to the now-rewritten product. For 2), the level of detail was along the lines of "the code base is awful. I hate it!" And, that's about it. Question 3) is, of course, impossible to answer if you failed to answer 2). Failure to be able to answer these types of questions is also in my eyes a strong indicator that you don't understand the existing product very well. And why would we? The existing team that built the thing had all left by that point, which is, in my experience, the norm, not the outlier. It's normal for devs to build something for a few years and then peace out, either via an internal transfer to another team or a new job opportunity. I believe that much of software is knowledge acquisition, and much of the cost of software maintenance is in dealing with the failure to transfer and maintain acquired knowledge over time. Rewrites can be spurred by ignorance, and that same ignorance can lead to the rewrite taking much longer than expected.
handrous 5y ago
IMO the best use of "agile"-style planning is to replace the estimation process with development. After 6-12 weeks you'll have some amount of working (if minimal) software, and a decent (by software planning standards) idea of how long at least the first major set of features will take. If you like what you see so far, and the estimate doesn't seem like it'll wreck your budget or timeline, you keep going. If not, you reconsider things or stop. ...Or you can spend that 6-12 weeks just estimating, involving more time by more people, have only a somewhat-better idea of how long the first set of features will take, and no working software to show for it. In practice, however, I find few businesses willing to either have a 1.5-3 month estimation window, or to start development with none but a wildly vague estimate, amounting to a guess, waiting 1.5-3 months to find out what a somewhat-accurate estimate may look like.
- regularfry 5y ago
  The unfortunate truth is that as soon as someone in the process wants an estimate, rather than wanting to see delivered value, you've already got a situation in which "agile"-style planning is on the back foot. Aside from any business value there may be in the estimate itself, insisting on being given one is a political move designed to put software delivery organisations on the defensive: the framing is that IT is a cost centre, not a value source. That's so common that it's easy to forget that it's not the only choice.
mr-wendel 5y ago
What a fine cut of beef this was! The very last sentence is what really gets me: > It requires buy in and input from the entire business stack. In my experience, this makes or breaks everything. Unless you have external buy-in and external understanding of all the points steverb enumerated: - Inaccurate estimates don't matter: there is so much wack-a-mole going on that by the time you're done it just doesn't matter as everyone is 3+ focus hijacks removed from when you started. - Accurate estimates cause heartburn: they wanted it weeks ago and now you're showing up with a number far larger than anyone wants to hear, but they can't tell you where to cut scope. Additionally, the point of estimates is planning, and planning really only matters when it aligns priorities for multiple teams... the more alignment needed the more important this becomes. Everyone has to do the dance or it's just no fun.
mason55 5y ago
> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build." Stating it like that usually makes people realize how ridiculous it is to commit to something, but you don't know what, but you'll still do it by a certain date. And it makes them feel like you're being willing to work with them/gives them some decision making power.
- lowercased 5y ago
  > commit to something, but you don't know what... The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'. I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken. But... fortunately, I've not had project work like that in a while :)
  - mason55 5y ago
    Yeah, it's definitely different if you're working on a contract basis. At least with internal stakeholders, whether you're building product, doing enterprise integrations, or building internal tooling, you just need to make sure that you have exec backup (or you are the exec). If you have buy-in then you can basically just set your team's policy and be done with it. For contract work you have to do the process over and over. Frankly, if I was doing contract dev, I'd state it as an upfront policy and move to quickly fire any customers that didn't buy in.
  - whimsicalism 5y ago
codegeek 5y ago
That's why I try to give Ballpark first, not estimates if I can get away with it. I would say "This can cost anywhere from $x to $y units (time/money)" where $y-$x is usually a big range. Then we start breaking it down further if there is interest and for that we need everyone involved like you said. Not always easy but sometimes it works.
lxe 5y ago
> But the business invariably doesn't want to spend the time and money to do that. Most engineers can actually estimate things fairly well when they take the time to iterate on a PoC and gather all sorts of details. Estimation fails when management has unrealistic expectations, e.g. asking for an estimate immediately after a proposal, or some set of initial documents are written.
waylandsmithers 5y ago
My own personal anecdote: I worked for a company that produced reports for insurance adjusters. Sometimes the reports were small enough to take an hour, and some large enough to take a week to produce. For some reason the company was obsessed with the "month-end" cycle- people on the last day of the month would work overtime until midnight and occasionally skip usual quality control checks to get things out the door. (And then take the next day off or come in at noon or whatever.) For reasons I will never understand, with three days left in the month a certain director would spend the whole day running around with a spreadsheet of all the reports that were open and ask people for a red/yellow/green estimate of whether they would be done. The next day and the next he'd repeat the process to get his most accurate estimate of the monthly revenue. Then two days later, the controller would just hand him the actual revenue numbers for the month ended.
- solveit 5y ago
  Perhaps an insider trader trying to outpace all the other insider traders?
pwthornton 5y ago
This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do. The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe a similar bridge under similar conditions would take similar amount of time). This is not what most places do (and most places don’t spend a lot of time after the fact really seeing how long each phase and part of the process took). I’d argue that estimates should be removed from day-to0-day engineers and placed with program managers or others whose job is to see how long work has taken and make schedules and estimates off of previous known work. The other way to get more accurate estimates is to build in systems and processes that require less and less custom work over time. So many software shops and tech companies never invest in this and every new major feature or project is heavily custom work.
- ppeetteerr 5y ago
  Depends on what you mean by accuracy. There is no bullseye with estimates. It's a means to set expectations and to show that you've thoughtfully analyzed the work. Part of your argument rests on reducing novelty. However, that's already covered by the myriad of manufacturing process improvement books. Programming is unique because every project is novel. Any migration, any integration, is going to be heavily dependent on company culture and environment. Like it or not, estimates are necessary to weight A against B, to scope, to plan marketing releases, to compete, to sell, to budget, etc. You may not get value from it as a coder, but that doesn't mean that there is no value in it.
- regularfry 5y ago
  I've seen counting tickets work fairly well. If the team is well-practised at breaking work down into tickets below a certain size, chances are good that the number of tickets completed per month will be fairly stable. That reduces the problem to "can you break this piece of work down into tickets, please", which isn't framed as an estimation problem with any attendant "no, that estimate's too big, try again" pressure. The bonus is that you can tell when a team has a stable enough process for this to work by looking at their ticket history over a few months, and the "estimate" (projection, really) is provided by the team themselves, so you don't get into a toxic situation where a team feels they're being held to an estimate someone else gave on their behalf.
regularfry 5y ago
The way I express it is that estimation is fundamentally a design process. You can't get an estimate without doing design work, to some appropriate level of detail. That design work is not going to spring forth from the void unbidden, so it needs to be paid for. This does not mean that you need a big design up front, but it does mean that you need to be happy with a level of precision to the estimates commensurate with the funding that has been given to the design process.
zaidf 5y ago
At my last job, I think 15-20% of Engineering Team's time was allocated for estimations (including multiple back and forth to clarify specs with product etc.)
hyperpallium2 5y ago
It's also very useful for personal projects, where you are the entire stack. Strangely, it's still difficult to get that buy in...
Kagerjay 5y ago
Estimating is hard. I like doing it too but it takes me several days to get an accurate estimate. Takes a decent chunk of meetings, figuring out every task that needs to be done, plus major risks and blockers
anthony_barker 5y ago
Have done some apartment renovations recently I find the same thing with architecture, architects. Without a detailed plan a lot of space is wasted and the apartment ends up less nice and you often end up reconstructing stuff (if it is small and non standard). The process takes 10-15% of the total cost of the project. Do people want to spend that? No.

stepbeek 5y ago

The business might not know enough for that estimate to be possible either. It reminds me of this quote from Andrew Wiles about mathematics: "Perhaps I could best describe my experience of doing mathematics in terms of entering a dark mansion. One goes into the ﬁrst room, and it’s dark, completely dark. One stumbles around bumping into the furniture, and gradually, you learn where each piece of furniture is, and ﬁnally, after six months or so, you ﬁnd the light switch. You turn it on, and suddenly, it’s all illuminated. You can see exactly where you were." [1] [1] Source: https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-doing-mathematics/ https://micromath.wordpress.com/2011/11/06/andrew-wiles-on-d...

BjoernKW 5y ago

A common misunderstanding about software creation is that code is the desired result. Hence, estimates more often than not try to predict how long it'll take to write the code that produces a desired outcome. However, in the end, code is just a very detailed specification of the design that produces a desired outcome. There's a reason why production is called production, after all: https://www.commitstrip.com/en/2016/08/25/a-very-comprehensive-and-precise-spec/ https://www.commitstrip.com/en/2016/08/25/a-very-comprehensi... Therefore, equating code written by a software developer with the final result is a little like equating an architect's blueprint with a building that was built according to that blueprint. The fundamental difference between those disciplines, of course, is that with software development most of the manual (as in: non-automated) work is done once the code has been written, whereas with construction the by far largest part of the manual work involved happens after the architect has created the blueprint. On one hand, this is a problem of perception. On the other hand, though, it's quite understandable that customers don't want to invest the better part of the budget upfront, not knowing if the design will meet the requirements. This is where agile management methods come into play. Those can be misused or, indeed, abused, too, but the idea of eliminating waste and adapting early is a sound one.

tshaddox 5y ago
> However, in the end, code is just a very detailed specification of the design that produces a desired outcome. Yes, exactly. The code is a technical specification that is so clear that a very dumb uncreative machine can follow it perfectly!
EricE 5y ago
"A common misunderstanding about software creation is that code is the desired result." Here here! If I have my product owner hat on I don't give a flip about the code itself; I'm interested in the business value a properly coded application unlocks.

snarf21 5y ago

Well said. My current rule based on experience is that estimates should only be hours/days/weeks/months/quarters/years with NO numbers. It is to give a sense of scale and effort so it could be prioritized and/or modified. If they want exact dates, then it is like you said, several days/weeks to go get an accurate date. I only wish that the sales team had to commit to closing dates the same way software teams do.

brightball 5y ago
I’m a big fan of avoiding numbers in estimations. The moment a number is included, people start adding them together to create metrics that don’t show any useful information.
mtippett 5y ago
That's actually a good hack. I tend to take a similar approach, but using approximate days in a fibonacci sequence. Start at the high end, will it take... years: NO quarters: NO months: erm... NO. weeks: maybe days: Unlikely hours: Ha. No. So you end up with a range (days?-weeks-months). That's too broad, what could go wrong to avoid making it months long project (well we could investigate X, Y, and watch for Z). What needs to go perfect for it to be days? (well we could... wait, days is unlikely). Those discussions about the high and the low to get "reasonable" confidence are super important.
- snarf21 5y ago
  Yeah, I always think about my structure as "some small number of h/d/w/m/q/y". I count 1 week the same as 3 weeks in terms of scale. ymmv
cpeterso 5y ago
I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ... The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points let compare two tasks. If you try to give t-shirt sizes points (e.g. "M = 2*S"), then you might as well skip the t-shirt abstraction and just use story points.

brightball 5y ago

This is 100% accurate and it's the reason that I prefer the SAFe (Scaled Agile) approach to estimation and planning over the common Scrum approaches. Doing the bulk of your planning during a 2-3 day PI Planning event lets a lot of people dive into a few things, preparing an estimate for the coming quarter, mapping dependencies across teams, lining them up with other planned work and outlining risks to the plan. Then the developers get to explain the plan to upper management, discuss any potential revisions and get moving...with everyone on the same page. This also keeps any estimation beyond the current quarter firmly in the realm of subject-to-change. That's the most critical part of it. Tech people and business people being out of alignment on expectations is where everything goes sideways and all of the friction comes from. Out of all of the methodologies I've come across in my career, this is the only approach I've seen that really balances development realities with a level of "enough" future planning to help business people make informed decisions.

tomrod 5y ago
In practice, devs are still writing code on PI days.
- brightball 5y ago
  How so?
  - tomrod 5y ago
    With computers and dev tools, trying to get the current PI complete.
    - brightball 5y ago
      If that happens you’re just supposed to include what is still to be done in the next PI while you stop everything for PI planning. There are too many people involved to just skip it to keep working.
      - 5y ago

dalbasal 5y ago

He can ... really really accurate estimate, ... a lot of time .. building .. verifying .. actual requirements.. designing ... solution .. validating .... process will require dev resources.. resources... people.. support team.. a lot of time.. very expensive.. scary.. and I'll be nakedly responsible for my own mistakes.. </inside head> "How about we do it that other way. You mentioned devs could keep throwing stuff against the wall. I like how that sounds."

username90 5y ago

> I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently. Of course it could be true in your case, but you can't blame the inability of software engineers in general to estimate tasks on that.

dalbasal 5y ago
I think of it this way. All problems that become sticky problems, got that way by being sticky. Re-writes encounter the sticky problem one way. When the spec is real, the spec is vast. "Do everything GMail does" is a lot of things. In internal business app teams, the sticky issue is that no one actually understands the business problems well enough to articulate sufficiently. There's usually very little incentive to be the spec person, on either the technical or business side. It might often be the same underlying issue. The difference with rewrites is that the "conversation" happens within tech teams, no outside player.
sreque 5y ago
As someone who has argued against a rewrite, lost the argument, and then proceeded to do the rewrite, I would push back strongly on the notion that we have a perfect specification, which is just "do what the old thing did". This specification is woefully incomplete, of course, just as a vague requirements document for a brand new service or product is incomplete. When someone proposes a rewrite for software, I ask him or her to think critically along the following questions: 1) What is the purpose of the rewrite? What do you hope to accomplish by it? What business objectives are furthered by the rewrite? 2) Explain in detail what is wrong the the existing code base, and why it is untenable to fix those problems piecemeal. 3) Explain in detail how the rewrite will avoid, overcome, or improve significantly on all the problems mentioned in 2). In my most recent, case, and as I expect in many others, I couldn't convince anyone to engage on any of these questions. For 1), we were told that the org planned to build significant new features on the product and the rewrite will help. However, the company's priorities changed significantly even as the rewrite was just getting started. By the time I left the company, I was not aware of any short or long-term plans to continue adding functionality to the now-rewritten product. For 2), the level of detail was along the lines of "the code base is awful. I hate it!" And, that's about it. Question 3) is, of course, impossible to answer if you failed to answer 2). Failure to be able to answer these types of questions is also in my eyes a strong indicator that you don't understand the existing product very well. And why would we? The existing team that built the thing had all left by that point, which is, in my experience, the norm, not the outlier. It's normal for devs to build something for a few years and then peace out, either via an internal transfer to another team or a new job opportunity. I believe that much of software is knowledge acquisition, and much of the cost of software maintenance is in dealing with the failure to transfer and maintain acquired knowledge over time. Rewrites can be spurred by ignorance, and that same ignorance can lead to the rewrite taking much longer than expected.

handrous 5y ago

IMO the best use of "agile"-style planning is to replace the estimation process with development. After 6-12 weeks you'll have some amount of working (if minimal) software, and a decent (by software planning standards) idea of how long at least the first major set of features will take. If you like what you see so far, and the estimate doesn't seem like it'll wreck your budget or timeline, you keep going. If not, you reconsider things or stop. ...Or you can spend that 6-12 weeks just estimating, involving more time by more people, have only a somewhat-better idea of how long the first set of features will take, and no working software to show for it. In practice, however, I find few businesses willing to either have a 1.5-3 month estimation window, or to start development with none but a wildly vague estimate, amounting to a guess, waiting 1.5-3 months to find out what a somewhat-accurate estimate may look like.

regularfry 5y ago
The unfortunate truth is that as soon as someone in the process wants an estimate, rather than wanting to see delivered value, you've already got a situation in which "agile"-style planning is on the back foot. Aside from any business value there may be in the estimate itself, insisting on being given one is a political move designed to put software delivery organisations on the defensive: the framing is that IT is a cost centre, not a value source. That's so common that it's easy to forget that it's not the only choice.

mr-wendel 5y ago

What a fine cut of beef this was! The very last sentence is what really gets me: > It requires buy in and input from the entire business stack. In my experience, this makes or breaks everything. Unless you have external buy-in and external understanding of all the points steverb enumerated: - Inaccurate estimates don't matter: there is so much wack-a-mole going on that by the time you're done it just doesn't matter as everyone is 3+ focus hijacks removed from when you started. - Accurate estimates cause heartburn: they wanted it weeks ago and now you're showing up with a number far larger than anyone wants to hear, but they can't tell you where to cut scope. Additionally, the point of estimates is planning, and planning really only matters when it aligns priorities for multiple teams... the more alignment needed the more important this becomes. Everyone has to do the dance or it's just no fun.

mason55 5y ago

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack. And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is: "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build." Stating it like that usually makes people realize how ridiculous it is to commit to something, but you don't know what, but you'll still do it by a certain date. And it makes them feel like you're being willing to work with them/gives them some decision making power.

lowercased 5y ago
> commit to something, but you don't know what... The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'. I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken. But... fortunately, I've not had project work like that in a while :)
- mason55 5y ago
  Yeah, it's definitely different if you're working on a contract basis. At least with internal stakeholders, whether you're building product, doing enterprise integrations, or building internal tooling, you just need to make sure that you have exec backup (or you are the exec). If you have buy-in then you can basically just set your team's policy and be done with it. For contract work you have to do the process over and over. Frankly, if I was doing contract dev, I'd state it as an upfront policy and move to quickly fire any customers that didn't buy in.
- whimsicalism 5y ago

codegeek 5y ago

That's why I try to give Ballpark first, not estimates if I can get away with it. I would say "This can cost anywhere from $x to $y units (time/money)" where $y-$x is usually a big range. Then we start breaking it down further if there is interest and for that we need everyone involved like you said. Not always easy but sometimes it works.

lxe 5y ago

> But the business invariably doesn't want to spend the time and money to do that. Most engineers can actually estimate things fairly well when they take the time to iterate on a PoC and gather all sorts of details. Estimation fails when management has unrealistic expectations, e.g. asking for an estimate immediately after a proposal, or some set of initial documents are written.

waylandsmithers 5y ago

My own personal anecdote: I worked for a company that produced reports for insurance adjusters. Sometimes the reports were small enough to take an hour, and some large enough to take a week to produce. For some reason the company was obsessed with the "month-end" cycle- people on the last day of the month would work overtime until midnight and occasionally skip usual quality control checks to get things out the door. (And then take the next day off or come in at noon or whatever.) For reasons I will never understand, with three days left in the month a certain director would spend the whole day running around with a spreadsheet of all the reports that were open and ask people for a red/yellow/green estimate of whether they would be done. The next day and the next he'd repeat the process to get his most accurate estimate of the monthly revenue. Then two days later, the controller would just hand him the actual revenue numbers for the month ended.

solveit 5y ago
Perhaps an insider trader trying to outpace all the other insider traders?

pwthornton 5y ago

This is generally why I don’t see a ton of value in trying to do accurate estimation. You’ll get better velocity and delivery not wasting your time on all of the faux story point estimating that scrum and other systems do. The most proven way to do accurate estimation is to base new estimates off of previous delivered work (i.e. we’ve built this suspension bridge design before and it took us this long, so we believe a similar bridge under similar conditions would take similar amount of time). This is not what most places do (and most places don’t spend a lot of time after the fact really seeing how long each phase and part of the process took). I’d argue that estimates should be removed from day-to0-day engineers and placed with program managers or others whose job is to see how long work has taken and make schedules and estimates off of previous known work. The other way to get more accurate estimates is to build in systems and processes that require less and less custom work over time. So many software shops and tech companies never invest in this and every new major feature or project is heavily custom work.

ppeetteerr 5y ago
Depends on what you mean by accuracy. There is no bullseye with estimates. It's a means to set expectations and to show that you've thoughtfully analyzed the work. Part of your argument rests on reducing novelty. However, that's already covered by the myriad of manufacturing process improvement books. Programming is unique because every project is novel. Any migration, any integration, is going to be heavily dependent on company culture and environment. Like it or not, estimates are necessary to weight A against B, to scope, to plan marketing releases, to compete, to sell, to budget, etc. You may not get value from it as a coder, but that doesn't mean that there is no value in it.
regularfry 5y ago
I've seen counting tickets work fairly well. If the team is well-practised at breaking work down into tickets below a certain size, chances are good that the number of tickets completed per month will be fairly stable. That reduces the problem to "can you break this piece of work down into tickets, please", which isn't framed as an estimation problem with any attendant "no, that estimate's too big, try again" pressure. The bonus is that you can tell when a team has a stable enough process for this to work by looking at their ticket history over a few months, and the "estimate" (projection, really) is provided by the team themselves, so you don't get into a toxic situation where a team feels they're being held to an estimate someone else gave on their behalf.

regularfry 5y ago

The way I express it is that estimation is fundamentally a design process. You can't get an estimate without doing design work, to some appropriate level of detail. That design work is not going to spring forth from the void unbidden, so it needs to be paid for. This does not mean that you need a big design up front, but it does mean that you need to be happy with a level of precision to the estimates commensurate with the funding that has been given to the design process.

zaidf 5y ago

At my last job, I think 15-20% of Engineering Team's time was allocated for estimations (including multiple back and forth to clarify specs with product etc.)

hyperpallium2 5y ago

It's also very useful for personal projects, where you are the entire stack. Strangely, it's still difficult to get that buy in...

Kagerjay 5y ago

Estimating is hard. I like doing it too but it takes me several days to get an accurate estimate. Takes a decent chunk of meetings, figuring out every task that needs to be done, plus major risks and blockers

anthony_barker 5y ago

Have done some apartment renovations recently I find the same thing with architecture, architects. Without a detailed plan a lot of space is wasted and the apartment ends up less nice and you often end up reconstructing stuff (if it is small and non standard). The process takes 10-15% of the total cost of the project. Do people want to spend that? No.