7 ms·

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that inf

All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could never had been foreseen, it's an impossibly hard problem bla bla. But best to bail from the vicinity of the project once reality starts to manifest itself. By that time you should be on the next project perhaps at the next company again promising the stars.

jcarrano 3y ago
Some questions are asked expecting a particular answer, rather than the truth. "How long is this going to take" is one of those.
- pixl97 3y ago
  If you get to the destination too quickly someone will make your destination farther away and harder to reach.
- HeyLaughingBoy 3y ago
  That's when you respond with "when do you need it done?" And you can probably work together to see what can realistically be completed by whatever date they had in mind.
rewmie 3y ago
> The way anything actually gets done is by initially being overly optimistic (...) I don't think so. At most, planners plan for the happy path and then add slack to help them manage expectations. Sometimes stuff emerges and projects adapt. Sometimes your slack covers it, sometimes it doesn't and you get delays and extra costs. That's a Project Manager's dish of the day. > then lock it in via sunk costs You're presuming that clients are oblivious to issues of delays and cost overruns, and the negotiation stages don't include accountability specifications.
mettamage 3y ago
This feels bleak. I'm not implying you're wrong. Frankly, I wouldn't know enough for or against. And if I had to choose, I'd be inclined to agree. It just feels bleak.
redpenguin101 3y ago
It's undeniably true that estimates are often driven mostly by what number will be acceptable. But it doesn't invalidate the points the article makes. Even when this distorting element of business drivers are removed, estimation is still very hard. You might get reprimanded if you give accurate estimates - that doesn't change the fact you mostly can't give accurate estimates even if you wanted to.
- RunSet 3y ago
  > you mostly can't give accurate estimates even if you wanted to. Ah, an optimist. I long for a world where software development estimates and those who expect them are perceived as the unfunny jokes they are. Why do naked emperors make such wretched despots?
  - Shaanie 3y ago
    On the other hand, you really do need some kind of estimate. You'd never hire an hourly contractor to remake your roof if he refused to give any kind of estimate, why wouldn't the same apply to software engineering? That being said, accurate estimates are usually not needed, but the order of magnitude is. Knowing if the change is days, weeks or years of work is important - and while we're bad at estimates, we're rarely "I estimated 2 weeks but it took 6 months"-bad.
    - jiggawatts 3y ago
      Estimate how long it will take to develop room temperature superconductors. To assist you, let me paint a picture to put you in the right frame of mind: You have never worked with superconductors of any kind and you’re not even a physicist. You’re one of those “scientist types” that are indistinguishable in the eyes of account managers. You’re in a thirty minute Teams meeting with a disinterested project mismanager that wants not just a finish date (on a specific date), but the milestone dates on the way there. You haven’t even met the team you’ll be working with. You haven’t yet spoken with the customer. Your “requirements” (lol) is literally just three words. Your “obstinance” at refusing to be professional and “do your job” is being thrown in your face by the PM and is being recorded for your next review meeting. Replace “room temperature superconductors” with any one of dozens of IT technologies or tasks and you have a nearly verbatim replay of my career and my challenges with estimation. Here’s the thing: if you’re doing something for the first time, you can’t estimate it. If you’re doing it a second time, you can’t estimate it either because it’ll benefit from reuse in a way not experienced the first time. If you’re doing things three or more times in IT, you had better automate the process… another unpredictable first-time activity. You’re either a meat robot doing repetitive work best done by scripts or LLMs - or by definition you are doing things for the first time and can’t estimate accurately. I don’t do the equivalent of putting down roof tiles in my work. Do you?
alentred 3y ago
It depends on the company, or more specifically on how the company manages the budget (people working on projects, infrastructure budgets, etc.). In many companies people would rather do the other way around: inflate their estimates to make sure that they definitely fit the reality later. This also often leads to continuously increasing budgets because or the corporate logic: “if you asked for budget but didn't use, then why did you ask for it’? So people would be actively looking for ways to spend any excess, to make sure that next time they will be trusted with their estimate, which in turn would likely be bigger than the previous one. Crazy, but true. So, it can work both ways really.
- mmcgaha 3y ago
  I have worked with both types of managers and many in between. My perception is that the sandbagger tends to be more accurate and executives tend to respect them more. The problem for the sandbagger comes when the project is large enough to get multiple estimates and the sandbagger gets put on the spot to explain his estimate. Our current project was estimated by our former VP at 4X and an outside consultant estimated the project at X. The board called the VP in to explain why his estimate was so high. We are now well into the project and former-vp's estimate is reality and former-consultant is gone.
  - Rury 3y ago
    The reason for this perception is because, if you claim it would take 4X, but you finish it in 1X, or 2X, or 3X, you can just pretend to be still working on BS things, and then viola you're finished at 4X. Otherwise, if you claim it when you actually finished, which was earlier then estimated, you look like a rockstar for having finished early.
vlovich123 3y ago
Shoot for the stars and you might hit the moon.
distcs 3y ago
> All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Depends on the workplace I guess. Haven't seen this where I've worked. quite the opposite. Some managers I've worked with taught me to multiple estimates by 2X before writing it on paper.
- jasongi 3y ago
  An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate. The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.
  - distcs 3y ago
    > The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand. Planning poker creating a sort of prisoner's dilemma is an intriguing thought. Mind explaining a little how it leads to something like prisoner's dilemma. I'd like to grok the connection between the two things.
    - pmg102 3y ago
      I'll have a go: If you ask developer A how long it will take, the best outcome for them is that they AND EVERYONE ELSE go high. So they should go high. BUT if everyone else goes low, but they go high, then they look bad. So they're forced to go lower. But then not too low, or they won't be able to deliver in time. So perhaps this settles on an estimate that's "as low as possible but no lower"?
      - HeyLaughingBoy 3y ago
        > the best outcome for them is that they AND EVERYONE ELSE go high But it's really not. The best outcome for them is that they are 100% accurate. Now, I understand that that's generally not feasible, but assuming that you need to pad everything by a huge amount is part of the problem. As a general rule, I've found that the kind of answer that gets the best response is on the order of "about X time to complete development, Y to get through testing, Z if you need any documentation, release notes or user instructions, I think A, B & C are risk items that could delay completion. If Sally and Jared aren't around for us to ask questions, that will also delay things so we need timely responses from them." Give good answers and you'll find people take you a lot more seriously.
coldcode 3y ago
My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.
- commandlinefan 3y ago
  > making the estimate pointless. If it's any consolation, the estimate would have been pointless even if they never changed their minds about anything too.
- HeyLaughingBoy 3y ago
  > making the estimate pointless Did anyone tell them this?
  - IIsi50MHz 3y ago
    Not the same, but I once worked in a place that had reasonably accurate production data generated manually on paper, and required this data copied into Excel workbooks which generated reports that were used at weekly executive planning meetings. The various workbooks were to be created by copy-pasting the newest existing workbook of each type, entering the data, and copy-pasting some other data into the workbooks. None of these had any access controls, not even for which cells were editable. When I queried about the obviously misaligned pastes and no-content graphs rendering the reports useless, a couple people responded like "Yeah, we know the reports are crap. They want them anyway.". This was at a company that "was continuously growing at ~3% since the founding" (some decades) and "had never laid off any worker, not part-time or temps". But somebody had given up. Maybe the guy who came before me, who quit with little notice. A week? I don't remember. I was given three months for creating and documenting a physical filing system (previous guy left no documentation), and physically filing the backlog. I made it take two weeks, including going back through old Excel workbooks and physical files to repair, correct, and apply access control on the workbooks. For my next two weeks, I spent a tiny bit of each day keeping things updated, and the majority of it helping out in another department. Then they suddenly laid off all temps, no appeals from supervisors accepted. Fast-forward a few years, and I heard from an active employee that they very nearly foundered, before returning to profit, thanks to one of their largest customers taking some of their debt (calculating that their reliability and precision was worth more than the cost of trying to get any other supplier tooled, schooled, and proper rigorous). I like to think I worked myself out of a job their, by making the estimates not pointless.
commandlinefan 3y ago
> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.
- black_13 3y ago
  [dead]
- drittich 3y ago
  Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.
  - dagss 3y ago
    Did you look at sp_describe_first_result_set? https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-describe-first-result-set-transact-sql?view=sql-server-ver16 https://learn.microsoft.com/en-us/sql/relational-databases/s...
  - tempodox 3y ago
    > Really, the first build IS the process of estimating. You hit the nail on the head.
  - awinter-py 3y ago
    yes this difficult to scope some projects without starting the build
- okaram 3y ago
  I have found a sure way to get estimates... Do the work, and say how long it took me.
Nowado 3y ago
Are you trying to say you correctly estimate your own projects?
mdgrech23 3y ago
I'd also add once the project gets going and leadership realizes it's starting to fall behind they'll ask what they can do to help. I'll reply w/ very real answers like we need wireframes, or language strings or this endpoint isn't ready and we don't even have a spec blah blah but that never seems to go anywhere. Anyone w/ real power is so far out of the weeds and usually busy w/ other things and those of us in the know are in the weeds and have no real power. While I'm at it there's another thing that boggles my mind. Leaders will say this is the most important project at the company and so much is riding on this project blah blah blah and then they give you a max of 10 minutes to explain all the issues you're facing before they seemingly move on to the next thing. I don't doubt it's importance. I genuinely believe them when they say this is really important but then put your money where your mouth is, roll up your sleeves and actually start driving shit.
- bavell 3y ago
  Very similar experience in my ~decade of experience in software dev as an entrepreneur.
raincole 3y ago
By this logic, programmers should be able to accurately estimate the schedule for personal projects or small scale open source projects where no one can "reprimand" them. It's so far from reality that it's almost satire.
- aleph_minus_one 3y ago
  > By this logic, programmers should be able to accurately estimate the schedule for personal projects or small scale open source projects where no one can "reprimand" them. In my experience many good and experienced programmers are able to do that. The reason why you get different observations is that in many cases, if you do such a project, you do it because the journey is the destination, i.e. you do such projects to try out new interesting technologies, i.e. the central gola is not finishing the project, but to get exposure to programming topics that you consider interesting. Finishing such small scale open-source projects to a given maturity is just rather a desired side effect and not a goal.
isaacremuant 3y ago
That cynical take is actually quite accurate in many contexts. People are definitely trained via bad managerial incentives to do this and end up doing it even without thinking. It's also funny how people talk agile but then want full project estimates with milestones down the line because that's how they get to pretend that: - they can give real assurances to the customer - they're valuable PMs with a tech contribution (when it's mostly the M&M customer management and meetings, they're good at) There's all flavours of situations and people, of course, but it's definitely a common trend in companies, even those that have high renown and are seen as leaders of an industry.
rkangel 3y ago
This is definitely true in some places. I have worked on Defence contracts that worked in exactly that way - win the initial bid by being cheapest, and then have the MOD pay you to fix all the bugs later. OTOH, it's not the culture where I work currently. We are expensive, we know we're expensive but the reason we can get away with it is because we deliver. That's on several fronts like technical capability but also because when we say "It'll cost X to get you what you want" it usually ends up costing them something close to X. Part of doing that is that if we don't have enough information to build the thing, we might do a "Phase zero" for a fixed period of time looking at the biggest question marks and that means we're much better informed to quote the main piece of work.
swader999 3y ago
If you gave accurate estimates you'd get fired for taking so long to produce those estimates. Ask your stakeholders how accurate each estimate needs to be and how much they want to spend on estimating. Where I'm at now a simple complexity score of 1,3,5,8,13 works fine and gives us +-30% variance and predictive power for new work when translating points into time spent after about three months of work and collecting the velocity. We spend about five minutes answering how complex is this for each story. To get a 10% variance takes the team a half day for anything non trivial. You have to go through this exercise in both extremes with the stakeholders and then you get buy in for the fast estimating. Google Mike Griffiths cone of uncertainty for the real take on this.
- HeyLaughingBoy 3y ago
  A team I was once on would take 2-4 days to estimate how much work we could get done in the next two months. We were usually pretty close! The important thing to understand here is that we had complete buy-in from Management. This was part of our process, and they understood that we needed that time to do a good job of estimation and risk management. The problem in most organizations seems to be that no one is willing to absorb the cost of real estimation.
  - Shaanie 3y ago
    While that may be a reason, I strongly suspect the real reason is that engineers simply don't want to spend time estimating. In my experience most people think breaking projects down into small chunks and estimating each chunk is terribly boring, they'd much rather have bigger and less defined chunks so they can start coding faster. I think thorough planning and estimations usually makes for both better and faster outcomes, but I'm unlikely to push for it simply because a full day of planning (or more) every two weeks is pretty damn boring. Doing some light high-level planning and diving into things is less efficient, but way more fun even if you end up having to backtrack more etc.
    - HeyLaughingBoy 3y ago
      I agree that it's boring as hell. It usually starts out as kind of fun, but halfway through the first day, your eyes are starting to glaze over. OTOH, it's part of a quality process and if your organization is driven by the need to produce high-quality output, accurate size & effort estimations are a part of how you get there.
sublinear 3y ago
Indeed. Development should not begin until all requirements have been finalized. Every project I've ever been on that had wildly wrong estimates was because management didn't actually plan jack shit either due to inexperience, laziness, malice, or all of the above. They then play the blame game to try to keep their job, and man it's so hilarious to witness the sheer carnage as everyone tears them a new asshole nowadays with the rise work from home (group chats/calls, DMs, etc.) We seriously need to drain the swamp of inept management and nepotism within business ranks. I've experienced better and it is absolutely possible to be off by less than ~25% of the total time estimated. i.e. it took 6 days instead of 5, or it took 5 months instead of 4, which is way less depressing.
- JohnFen 3y ago
  > Development should not begin until all requirements have been finalized. I agree, but this runs directly counter to Agile methodologies which are all the rage these days.
  - imtringued 3y ago
    "How to end up shipping your project three years after the planned release"-starter-kit.
JohnFen 3y ago
> the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. I have never actually experienced this personally, but I have no doubt that it's a thing in many companies. But it's really inept management. If management has some sort of hard date in mind, then the way they should pose the problem to dev is: we need this completed by xx/xx/xx -- what can be accomplished in that time?

jcarrano 3y ago

Some questions are asked expecting a particular answer, rather than the truth. "How long is this going to take" is one of those.

pixl97 3y ago
If you get to the destination too quickly someone will make your destination farther away and harder to reach.
HeyLaughingBoy 3y ago
That's when you respond with "when do you need it done?" And you can probably work together to see what can realistically be completed by whatever date they had in mind.

rewmie 3y ago

> The way anything actually gets done is by initially being overly optimistic (...) I don't think so. At most, planners plan for the happy path and then add slack to help them manage expectations. Sometimes stuff emerges and projects adapt. Sometimes your slack covers it, sometimes it doesn't and you get delays and extra costs. That's a Project Manager's dish of the day. > then lock it in via sunk costs You're presuming that clients are oblivious to issues of delays and cost overruns, and the negotiation stages don't include accountability specifications.

mettamage 3y ago

This feels bleak. I'm not implying you're wrong. Frankly, I wouldn't know enough for or against. And if I had to choose, I'd be inclined to agree. It just feels bleak.

redpenguin101 3y ago

It's undeniably true that estimates are often driven mostly by what number will be acceptable. But it doesn't invalidate the points the article makes. Even when this distorting element of business drivers are removed, estimation is still very hard. You might get reprimanded if you give accurate estimates - that doesn't change the fact you mostly can't give accurate estimates even if you wanted to.

RunSet 3y ago
> you mostly can't give accurate estimates even if you wanted to. Ah, an optimist. I long for a world where software development estimates and those who expect them are perceived as the unfunny jokes they are. Why do naked emperors make such wretched despots?
- Shaanie 3y ago
  On the other hand, you really do need some kind of estimate. You'd never hire an hourly contractor to remake your roof if he refused to give any kind of estimate, why wouldn't the same apply to software engineering? That being said, accurate estimates are usually not needed, but the order of magnitude is. Knowing if the change is days, weeks or years of work is important - and while we're bad at estimates, we're rarely "I estimated 2 weeks but it took 6 months"-bad.
  - jiggawatts 3y ago
    Estimate how long it will take to develop room temperature superconductors. To assist you, let me paint a picture to put you in the right frame of mind: You have never worked with superconductors of any kind and you’re not even a physicist. You’re one of those “scientist types” that are indistinguishable in the eyes of account managers. You’re in a thirty minute Teams meeting with a disinterested project mismanager that wants not just a finish date (on a specific date), but the milestone dates on the way there. You haven’t even met the team you’ll be working with. You haven’t yet spoken with the customer. Your “requirements” (lol) is literally just three words. Your “obstinance” at refusing to be professional and “do your job” is being thrown in your face by the PM and is being recorded for your next review meeting. Replace “room temperature superconductors” with any one of dozens of IT technologies or tasks and you have a nearly verbatim replay of my career and my challenges with estimation. Here’s the thing: if you’re doing something for the first time, you can’t estimate it. If you’re doing it a second time, you can’t estimate it either because it’ll benefit from reuse in a way not experienced the first time. If you’re doing things three or more times in IT, you had better automate the process… another unpredictable first-time activity. You’re either a meat robot doing repetitive work best done by scripts or LLMs - or by definition you are doing things for the first time and can’t estimate accurately. I don’t do the equivalent of putting down roof tiles in my work. Do you?

alentred 3y ago

It depends on the company, or more specifically on how the company manages the budget (people working on projects, infrastructure budgets, etc.). In many companies people would rather do the other way around: inflate their estimates to make sure that they definitely fit the reality later. This also often leads to continuously increasing budgets because or the corporate logic: “if you asked for budget but didn't use, then why did you ask for it’? So people would be actively looking for ways to spend any excess, to make sure that next time they will be trusted with their estimate, which in turn would likely be bigger than the previous one. Crazy, but true. So, it can work both ways really.

mmcgaha 3y ago
I have worked with both types of managers and many in between. My perception is that the sandbagger tends to be more accurate and executives tend to respect them more. The problem for the sandbagger comes when the project is large enough to get multiple estimates and the sandbagger gets put on the spot to explain his estimate. Our current project was estimated by our former VP at 4X and an outside consultant estimated the project at X. The board called the VP in to explain why his estimate was so high. We are now well into the project and former-vp's estimate is reality and former-consultant is gone.
- Rury 3y ago
  The reason for this perception is because, if you claim it would take 4X, but you finish it in 1X, or 2X, or 3X, you can just pretend to be still working on BS things, and then viola you're finished at 4X. Otherwise, if you claim it when you actually finished, which was earlier then estimated, you look like a rockstar for having finished early.

vlovich123 3y ago

Shoot for the stars and you might hit the moon.

distcs 3y ago

> All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Depends on the workplace I guess. Haven't seen this where I've worked. quite the opposite. Some managers I've worked with taught me to multiple estimates by 2X before writing it on paper.

jasongi 3y ago
An overblown estimate is arguably just as damaging as an overly optimistic one. The thing about estimates I’ve found is that the actual amount of time it takes to complete a task will never shrink to match an estimate, but it almost certainly will grow to match an estimate. The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand.
- distcs 3y ago
  > The reason planning poker exists is to create a sort of prisoner’s dilemma between developers to stop this getting out of hand. Planning poker creating a sort of prisoner's dilemma is an intriguing thought. Mind explaining a little how it leads to something like prisoner's dilemma. I'd like to grok the connection between the two things.
  - pmg102 3y ago
    I'll have a go: If you ask developer A how long it will take, the best outcome for them is that they AND EVERYONE ELSE go high. So they should go high. BUT if everyone else goes low, but they go high, then they look bad. So they're forced to go lower. But then not too low, or they won't be able to deliver in time. So perhaps this settles on an estimate that's "as low as possible but no lower"?
    - HeyLaughingBoy 3y ago
      > the best outcome for them is that they AND EVERYONE ELSE go high But it's really not. The best outcome for them is that they are 100% accurate. Now, I understand that that's generally not feasible, but assuming that you need to pad everything by a huge amount is part of the problem. As a general rule, I've found that the kind of answer that gets the best response is on the order of "about X time to complete development, Y to get through testing, Z if you need any documentation, release notes or user instructions, I think A, B & C are risk items that could delay completion. If Sally and Jared aren't around for us to ask questions, that will also delay things so we need timely responses from them." Give good answers and you'll find people take you a lot more seriously.

coldcode 3y ago

My last employer required us to do project-long estimates based on whatever they asked for up front. However, they then felt like changing everything on a daily basis, making the estimate pointless.

commandlinefan 3y ago
> making the estimate pointless. If it's any consolation, the estimate would have been pointless even if they never changed their minds about anything too.
HeyLaughingBoy 3y ago
> making the estimate pointless Did anyone tell them this?
- IIsi50MHz 3y ago
  Not the same, but I once worked in a place that had reasonably accurate production data generated manually on paper, and required this data copied into Excel workbooks which generated reports that were used at weekly executive planning meetings. The various workbooks were to be created by copy-pasting the newest existing workbook of each type, entering the data, and copy-pasting some other data into the workbooks. None of these had any access controls, not even for which cells were editable. When I queried about the obviously misaligned pastes and no-content graphs rendering the reports useless, a couple people responded like "Yeah, we know the reports are crap. They want them anyway.". This was at a company that "was continuously growing at ~3% since the founding" (some decades) and "had never laid off any worker, not part-time or temps". But somebody had given up. Maybe the guy who came before me, who quit with little notice. A week? I don't remember. I was given three months for creating and documenting a physical filing system (previous guy left no documentation), and physically filing the backlog. I made it take two weeks, including going back through old Excel workbooks and physical files to repair, correct, and apply access control on the workbooks. For my next two weeks, I spent a tiny bit of each day keeping things updated, and the majority of it helping out in another department. Then they suddenly laid off all temps, no appeals from supervisors accepted. Fast-forward a few years, and I heard from an active employee that they very nearly foundered, before returning to profit, thanks to one of their largest customers taking some of their debt (calculating that their reliability and precision was worth more than the cost of trying to get any other supplier tooled, schooled, and proper rigorous). I like to think I worked myself out of a job their, by making the estimates not pointless.

commandlinefan 3y ago

> if you gave accurate estimates, you'd get reprimanded I like the cynicism, but this implies that you can give accurate estimate, which I also take exception to. To give an accurate estimate, you'd have to first have a complete specification, which I've never seen.

black_13 3y ago
[dead]
drittich 3y ago
Pretty much correct, IMO. Really, the first build (and usually the only one, unfortunately) IS the process of estimating. I try to POC as much as possible to make sure I know where the landmines are. Just this week, I blew by one of my own recent estimates because I assumed I could pretty easily determine the output column names and data types for any arbitrary SQL Server stored procedure using a SQL query. Many implementation hours and attempts later, I realized my folly, and I am not new to SQL.
- dagss 3y ago
  Did you look at sp_describe_first_result_set? https://learn.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-describe-first-result-set-transact-sql?view=sql-server-ver16 https://learn.microsoft.com/en-us/sql/relational-databases/s...
- tempodox 3y ago
  > Really, the first build IS the process of estimating. You hit the nail on the head.
- awinter-py 3y ago
  yes this difficult to scope some projects without starting the build
okaram 3y ago
I have found a sure way to get estimates... Do the work, and say how long it took me.

Nowado 3y ago

Are you trying to say you correctly estimate your own projects?

mdgrech23 3y ago

I'd also add once the project gets going and leadership realizes it's starting to fall behind they'll ask what they can do to help. I'll reply w/ very real answers like we need wireframes, or language strings or this endpoint isn't ready and we don't even have a spec blah blah but that never seems to go anywhere. Anyone w/ real power is so far out of the weeds and usually busy w/ other things and those of us in the know are in the weeds and have no real power. While I'm at it there's another thing that boggles my mind. Leaders will say this is the most important project at the company and so much is riding on this project blah blah blah and then they give you a max of 10 minutes to explain all the issues you're facing before they seemingly move on to the next thing. I don't doubt it's importance. I genuinely believe them when they say this is really important but then put your money where your mouth is, roll up your sleeves and actually start driving shit.

bavell 3y ago
Very similar experience in my ~decade of experience in software dev as an entrepreneur.

raincole 3y ago

By this logic, programmers should be able to accurately estimate the schedule for personal projects or small scale open source projects where no one can "reprimand" them. It's so far from reality that it's almost satire.

aleph_minus_one 3y ago
> By this logic, programmers should be able to accurately estimate the schedule for personal projects or small scale open source projects where no one can "reprimand" them. In my experience many good and experienced programmers are able to do that. The reason why you get different observations is that in many cases, if you do such a project, you do it because the journey is the destination, i.e. you do such projects to try out new interesting technologies, i.e. the central gola is not finishing the project, but to get exposure to programming topics that you consider interesting. Finishing such small scale open-source projects to a given maturity is just rather a desired side effect and not a goal.

isaacremuant 3y ago

That cynical take is actually quite accurate in many contexts. People are definitely trained via bad managerial incentives to do this and end up doing it even without thinking. It's also funny how people talk agile but then want full project estimates with milestones down the line because that's how they get to pretend that: - they can give real assurances to the customer - they're valuable PMs with a tech contribution (when it's mostly the M&M customer management and meetings, they're good at) There's all flavours of situations and people, of course, but it's definitely a common trend in companies, even those that have high renown and are seen as leaders of an industry.

rkangel 3y ago

This is definitely true in some places. I have worked on Defence contracts that worked in exactly that way - win the initial bid by being cheapest, and then have the MOD pay you to fix all the bugs later. OTOH, it's not the culture where I work currently. We are expensive, we know we're expensive but the reason we can get away with it is because we deliver. That's on several fronts like technical capability but also because when we say "It'll cost X to get you what you want" it usually ends up costing them something close to X. Part of doing that is that if we don't have enough information to build the thing, we might do a "Phase zero" for a fixed period of time looking at the biggest question marks and that means we're much better informed to quote the main piece of work.

swader999 3y ago

If you gave accurate estimates you'd get fired for taking so long to produce those estimates. Ask your stakeholders how accurate each estimate needs to be and how much they want to spend on estimating. Where I'm at now a simple complexity score of 1,3,5,8,13 works fine and gives us +-30% variance and predictive power for new work when translating points into time spent after about three months of work and collecting the velocity. We spend about five minutes answering how complex is this for each story. To get a 10% variance takes the team a half day for anything non trivial. You have to go through this exercise in both extremes with the stakeholders and then you get buy in for the fast estimating. Google Mike Griffiths cone of uncertainty for the real take on this.

HeyLaughingBoy 3y ago
A team I was once on would take 2-4 days to estimate how much work we could get done in the next two months. We were usually pretty close! The important thing to understand here is that we had complete buy-in from Management. This was part of our process, and they understood that we needed that time to do a good job of estimation and risk management. The problem in most organizations seems to be that no one is willing to absorb the cost of real estimation.
- Shaanie 3y ago
  While that may be a reason, I strongly suspect the real reason is that engineers simply don't want to spend time estimating. In my experience most people think breaking projects down into small chunks and estimating each chunk is terribly boring, they'd much rather have bigger and less defined chunks so they can start coding faster. I think thorough planning and estimations usually makes for both better and faster outcomes, but I'm unlikely to push for it simply because a full day of planning (or more) every two weeks is pretty damn boring. Doing some light high-level planning and diving into things is less efficient, but way more fun even if you end up having to backtrack more etc.
  - HeyLaughingBoy 3y ago
    I agree that it's boring as hell. It usually starts out as kind of fun, but halfway through the first day, your eyes are starting to glaze over. OTOH, it's part of a quality process and if your organization is driven by the need to produce high-quality output, accurate size & effort estimations are a part of how you get there.

sublinear 3y ago

Indeed. Development should not begin until all requirements have been finalized. Every project I've ever been on that had wildly wrong estimates was because management didn't actually plan jack shit either due to inexperience, laziness, malice, or all of the above. They then play the blame game to try to keep their job, and man it's so hilarious to witness the sheer carnage as everyone tears them a new asshole nowadays with the rise work from home (group chats/calls, DMs, etc.) We seriously need to drain the swamp of inept management and nepotism within business ranks. I've experienced better and it is absolutely possible to be off by less than ~25% of the total time estimated. i.e. it took 6 days instead of 5, or it took 5 months instead of 4, which is way less depressing.

JohnFen 3y ago
> Development should not begin until all requirements have been finalized. I agree, but this runs directly counter to Agile methodologies which are all the rage these days.
- imtringued 3y ago
  "How to end up shipping your project three years after the planned release"-starter-kit.

JohnFen 3y ago

> the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. I have never actually experienced this personally, but I have no doubt that it's a thing in many companies. But it's really inept management. If management has some sort of hard date in mind, then the way they should pose the problem to dev is: we need this completed by xx/xx/xx -- what can be accomplished in that time?