5 ms·

I might be in a 1% of engineers that believe in estimation. Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possi

I might be in a 1% of engineers that believe in estimation. Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possible, it is that you are simply not experienced enough. That's fine. There is something called skills, and you can go get them. Have you made a plan? Great, then is there is some task in your plan that you can't estimate? In rare cases that might be inherently true, but in the majority of cases if you are senior enough any given task you're asked to do at Company A is going to be something similar to some task you've done in your prior experience and you can collect personal data on that. A plan with per task estimates and you have an estimate for a deliverable. The next piece, and this is crucial, is you aim at and execute rigorously to the plan -- prioritizing as you go. If you do any "padding" for insurance, you DO NOT add arbitrary constants or double etc to your estimates. You add extra scope, ie tasks delivering real value, to your plan, but scope that can be cut, if needed, as part of your rigorous execution, en route, if you find in iterations that you're slipping.

qprofyeh 3y ago
I tend to disagree. Estimate this more complex situation: Integrate vendor B’s API where you don’t have prior experience with vendor B’s product let alone their API, and where our system is built specifically around vendor A’s API and workflow. This requires backend and frontend (customer and admin UI) changes given that everything is tied to vendor A’s API currently.
- IanCal 3y ago
  Have you ever done this before? How long has it taken in the past? What are the key first steps? Investigate the API and product right? How long has that taken when you've done it before? Your first deliverable is a plan of it's that unknown. Now you've investigated you know more about what needs to be done. You can compare it to previous times you've done similar things and estimate how long it should take.
  - qprofyeh 3y ago
    Your basic approach is sound. Problem is the existence of unknown unknowns, those that only appear when you reach a later stage where these unknown unknowns decide to present themselves. Often causing an unknown amount of unknown effort requires from an unknown team member or third party. This invalidates earlier timeframes, and in worst case even the entire strategy. How does one put a proper estimate on this? Any answer is but a wild guess. (This is where PMs provide added value by realigning business and product teams around the new situation.)
    - IanCal 3y ago
      The more experience you have the more you're used to these things happening. I don't have to know that a specific thing might go wrong but I'm used to there being some random bullshit (weird CI, library happens to be deprecated, version inconsistencies, data turns out to have a fatal flaw, licensing, whatever). You can't plan for everything though, and you're right this is where a good PM helps. But then again this is all just estimates. The better you can estimate the better you can plan.
lostdog 3y ago
> Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possible, it is that you are simply not experienced enough. Perhaps you work in a simple domain? This would be infeasible at my current job, and that's including the best-in-the-industry people with 20 years experience.
- wellpast 3y ago
  What’s your domain? Are you working on a mission critical system? Are you trying to solve an algorithmic problem that is novel enough to warrant a publication after you solve it? If not, I doubt estimating is innately infeasible. If your best-in-industry people can’t do it it’s because they probably haven’t valued it enough in their career to develop the particular skill set.
  - Zanfa 3y ago
    I have some experience with healthcare software and the core of it is pretty simple. The 2 biggest sources of unknowns however are quirks of the existing system and edge cases in human processes. Neither can be accurately estimated for because complex systems are never documented in enough detail and even humans who have been using them for decades overlook and misremember things. I’m sure this is the case in any complex enough business system as well.
efficax 3y ago
the map becomes the territory here. if you have enough information to accurately estimate a project then you've already done the bulk of the work, and all you have left to do is type. The reason estimates are hard is because the work surprises you. You find out there are problems you didn't expect that must be solved to meet the stated goals. This happens all the time, it always happens on anything non trivial, which is why you have to add time to estimates beyond your initial assumptions. What experience teaches you is that this is going to happen, and it even gives you an inkling of the sorts of ways it might happen, and even better it makes it easier for you to resolve these issues when they do happen because they tend to be similar to other problems you've encountered before, but what it can't tell you is which problems you'll run into, becuase you won't run into them, until you do.
- wellpast 3y ago
  > if you have enough information to accurately estimate a project then you've already done the bulk of the work This is false. I’ve learnt 10s of new UX frameworks in my career and it takes about 20 hours from scratch to become proficient enough in one to design a new complex widget in it (say) — but knowing that doesn’t suddenly absolve me from spending those 20 hours.
  - pyrale 3y ago
    So you're saying you're giving quotes for a project in a framework you don't even know?
goto11 3y ago
The second time you are doing exactly the same thing you will be a lot faster, and the third time you will write a script to automate it. If others are doing the same thing repeatedly across the industry, automated tools will appear. It follows that the majority of a developers time (at any level of experience) will be spent doing things they haven't done before.
sirwhinesalot 3y ago
Go look at the SysMLv2 spec. I want you to implement me a parser for it in Python. The resulting AST must respect the relations between fields defined in the standard. How long will it take you? It's just implementing what's written in a pdf, shouldn't be hard to break down and estimate. I'll wait.

qprofyeh 3y ago

I tend to disagree. Estimate this more complex situation: Integrate vendor B’s API where you don’t have prior experience with vendor B’s product let alone their API, and where our system is built specifically around vendor A’s API and workflow. This requires backend and frontend (customer and admin UI) changes given that everything is tied to vendor A’s API currently.

IanCal 3y ago
Have you ever done this before? How long has it taken in the past? What are the key first steps? Investigate the API and product right? How long has that taken when you've done it before? Your first deliverable is a plan of it's that unknown. Now you've investigated you know more about what needs to be done. You can compare it to previous times you've done similar things and estimate how long it should take.
- qprofyeh 3y ago
  Your basic approach is sound. Problem is the existence of unknown unknowns, those that only appear when you reach a later stage where these unknown unknowns decide to present themselves. Often causing an unknown amount of unknown effort requires from an unknown team member or third party. This invalidates earlier timeframes, and in worst case even the entire strategy. How does one put a proper estimate on this? Any answer is but a wild guess. (This is where PMs provide added value by realigning business and product teams around the new situation.)
  - IanCal 3y ago
    The more experience you have the more you're used to these things happening. I don't have to know that a specific thing might go wrong but I'm used to there being some random bullshit (weird CI, library happens to be deprecated, version inconsistencies, data turns out to have a fatal flaw, licensing, whatever). You can't plan for everything though, and you're right this is where a good PM helps. But then again this is all just estimates. The better you can estimate the better you can plan.

lostdog 3y ago

> Can you make a step plan for some deliverable? No? Then, sorry, it's not that planning is not possible, it is that you are simply not experienced enough. Perhaps you work in a simple domain? This would be infeasible at my current job, and that's including the best-in-the-industry people with 20 years experience.

wellpast 3y ago
What’s your domain? Are you working on a mission critical system? Are you trying to solve an algorithmic problem that is novel enough to warrant a publication after you solve it? If not, I doubt estimating is innately infeasible. If your best-in-industry people can’t do it it’s because they probably haven’t valued it enough in their career to develop the particular skill set.
- Zanfa 3y ago
  I have some experience with healthcare software and the core of it is pretty simple. The 2 biggest sources of unknowns however are quirks of the existing system and edge cases in human processes. Neither can be accurately estimated for because complex systems are never documented in enough detail and even humans who have been using them for decades overlook and misremember things. I’m sure this is the case in any complex enough business system as well.

efficax 3y ago

the map becomes the territory here. if you have enough information to accurately estimate a project then you've already done the bulk of the work, and all you have left to do is type. The reason estimates are hard is because the work surprises you. You find out there are problems you didn't expect that must be solved to meet the stated goals. This happens all the time, it always happens on anything non trivial, which is why you have to add time to estimates beyond your initial assumptions. What experience teaches you is that this is going to happen, and it even gives you an inkling of the sorts of ways it might happen, and even better it makes it easier for you to resolve these issues when they do happen because they tend to be similar to other problems you've encountered before, but what it can't tell you is which problems you'll run into, becuase you won't run into them, until you do.

wellpast 3y ago
> if you have enough information to accurately estimate a project then you've already done the bulk of the work This is false. I’ve learnt 10s of new UX frameworks in my career and it takes about 20 hours from scratch to become proficient enough in one to design a new complex widget in it (say) — but knowing that doesn’t suddenly absolve me from spending those 20 hours.
- pyrale 3y ago
  So you're saying you're giving quotes for a project in a framework you don't even know?

goto11 3y ago

The second time you are doing exactly the same thing you will be a lot faster, and the third time you will write a script to automate it. If others are doing the same thing repeatedly across the industry, automated tools will appear. It follows that the majority of a developers time (at any level of experience) will be spent doing things they haven't done before.

sirwhinesalot 3y ago

Go look at the SysMLv2 spec. I want you to implement me a parser for it in Python. The resulting AST must respect the relations between fields defined in the standard. How long will it take you? It's just implementing what's written in a pdf, shouldn't be hard to break down and estimate. I'll wait.