6 ms·

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimat

My instinct is that if you can put numbers and predictions based on real world estimations, then you are estimating simple things. For example, you can estimate how long it will drive from A to B. Google maps does a brilliant job of this, showing the busy sections. Often I get there +/- a minute from what is estimated over a 60 minute journey. But estimating how long someone will take to do a project, where the project by definition is something new in the context of the people doing it. If it wasn't then the code would already exist, and the estimate will be "how long to deploy that thing you already have using CI". So in software you are always doing something new. We are building Sydney Opera Houses, not prefab housing estates.

x86x87 3y ago
Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.
- ethbr0 3y ago
  I.e. spiral https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model
  - x86x87 3y ago
    TIL. Thanks for sharing this
    - ethbr0 3y ago
      Sure! I tossed some thoughts on the sibling comment above yours.
  - quickthrower2 3y ago
    That is interesting. Going to look more into this. When something looks like common sense codified, then I like it :-)
    - ethbr0 3y ago
      As with many development methodologies, it probably has a formal version that I'm not understanding. But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product. Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question. But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.
  - rswail 3y ago
    Sigh, this was the basis of "Iterative Development" that came along with the "Rational Unified Process" and was the precursor to the current fad of epics/stories/sprints/t-shirts/Fibonacci that has polluted current programming. People won't follow it because it means reviewing their assumptions and re-planning, but there are always external entities that will not or can not do so (other departments, finance, customers, marketing, sales, etc etc).
vletal 3y ago
> We are building Sydney Opera Houses. Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market. In reality, most devs are making unique family Vilas at best. I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.
- skeeter2020 3y ago
  Most of us our building prefab housing, but the challenge is there's infinite ways to put the modules together, and unlike real housing no physics to reduce the problem set of possbilities.
  - depereo 3y ago
    Even the prefab stuff has unknown unknowns - but everyone skimps on the geotechnical assessments of the ground you're building on...
  - ehnto 3y ago
    And the prefab modules are all from different manufacturers who follow different standards.
    - masklinn 3y ago
      And some of the hands have a tendency to put electrical between module feet and to try and bond the modules with wood glue.
- lcnPylGDnU4H9OF 3y ago
  I am reminded of software like the “Snake” malware. Not exactly “ostentasteful” like the Sydney Opera House but grand and intricate with a specific, kinda-but-not-exactly unique purpose. (I’m sure there are other examples but my mind has an information security bias and I learned about “Snake” recently.) Not the bespoke CMS I work on for Bob’s Bait Shop.
- xlii 3y ago
HankB99 3y ago
> in software you are always doing something new Yes, and invariably anything that comes up and wasn't accounted for in the estimate will take more time, not less.
- quickthrower2 3y ago
  Yes but only in waterfall do you need to accept that issue. In small “a” agile you can now go back to the business and suggest alternatives. (The Opera House was not built exactly to the original plans, for example). Of course that doesn’t work if you need to follow OKR dogma etc. and stick to the original plan.
  - rurban 3y ago
    Which plans? There weren't any, just rough sketches, plus the requirements were constantly changing. They also started construction before the planning was finished.
deadfoxygrandpa 3y ago
everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of schedule. how did that planning happen? dont tell me that was simpler than your crud app
- btilly 3y ago
  Funny fact. When I was a relatively new programmer, we used to be told we had to become better at estimating, like architects are on construction projects. Then it became common knowledge that architects are as bad as we are at estimating costs. And people no longer use that comparison. The fields that are actually able to estimate work well tend to have one big advantage. They are estimating how to do standardized tasks that are similar to ones that they have done many times before. Ones that don't have that advantage, are as bad as we are.
  - danielmarkbruce 3y ago
    There is a half decent book "How Big Things Get Done" which goes into some detail on this. TLDR - yes.
- kortilla 3y ago
  A train system is embarrassingly parallelized. It’s the equivalent of saying, we want to build 50 data centers in 3 years. It’s a lot, but it’s a lot of independent things that connect together at the end.
- quickthrower2 3y ago
  A falacy here is there are commercial just-crud apps. There are not. If it is just crud then just rails scaffold it, and estimate day 1 day. We could be better and more like the subset of real infrastructure projects that are on time and budget. There is probably a subset of software that is too. You need to a great waterfall. Probably allow prototypes that can be thrown away and have a decent budget for the design phase that will shore up the design and therefore the estimate. And have developers on one project. Hire project managers that are on their 15th ERP build and making a similar one for you. And use last decades tech so there are less uncertainties (probably not a bad idea for many things - gimme that winforms app without all the slower SPA spinners!) Even with all this what software lacks is classic Engineering (long degree, good concepts taught, respectable education over leetcode practice and so on). Problem is California will piss all over your business with move fast attitude unless you are boring enough to be off their radar. Be boring!
doctor_eval 3y ago
Totally agree with this. Most commercial software projects that I’ve worked on start with a horrific RFP process and legacy integrations that make otherwise simple projects into bespoke nightmares. The whole process of commercial software procurement and project assurance is a mess. And then you get consulting firms and body shops involved…
regularfry 3y ago
I actually disagree. Well, sort of. We can almost always say "it can't possibly take less than X". In fact, that X is often what gets given as the estimate, which is... not good, when you think about it. We can also often say "it is very unlikely to take more than Y". Between X and Y is the range of possible values for a real estimate. The problem comes when X and Y aren't just far apart, they're orders of magnitude apart. If you go back to your stakeholders with that range, what you should be able to hope for is a reasoned discussion not about how Y is too big (which it almost certainly will be) but on how to reduce the size of the range. That involves having more information about either the problem or the solution, so you (or they) are either off into more analysis, or you're into solution design. When you have a design in terms of subparts similar to things that have been built before, you've got something that's less Sydney Opera House and more Sydney Opera House LEGO Creator Expert Set 10234. So yes, at the specific point in time where someone asks you "how long to do this thing that's never been done before" there's almost certainly not enough information to give a response that bears relation to reality, but that should be the start of the conversation, not the end.

x86x87 3y ago

Also, to get better estimates you need to sometimes do some [research] work. Without it ykur guesses are even wilder but with it you have to ack that you've spent time on it, evenif you never get to do the actual work.

ethbr0 3y ago
I.e. spiral https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model
- x86x87 3y ago
  TIL. Thanks for sharing this
  - ethbr0 3y ago
    Sure! I tossed some thoughts on the sibling comment above yours.
- quickthrower2 3y ago
  That is interesting. Going to look more into this. When something looks like common sense codified, then I like it :-)
  - ethbr0 3y ago
    As with many development methodologies, it probably has a formal version that I'm not understanding. But in my head, it's always been (1) identify areas of risk, (2) sprint to a prototype that decreases or quantifies that risk, (3) evaluate whether you've reduced risk sufficiently, then either (4a) proceed to the next risk or (4b) do another prototype sprint on this risk, and finally after all pockets of risk have been reduced (5) begin building your finished product. Believe it comes from state of the art development for military procurement, where "What is even possible?" is a valid question. But it always resonated with software planning for me, by making it more about risk reduction rather than guessing.
- rswail 3y ago
  Sigh, this was the basis of "Iterative Development" that came along with the "Rational Unified Process" and was the precursor to the current fad of epics/stories/sprints/t-shirts/Fibonacci that has polluted current programming. People won't follow it because it means reviewing their assumptions and re-planning, but there are always external entities that will not or can not do so (other departments, finance, customers, marketing, sales, etc etc).

vletal 3y ago

> We are building Sydney Opera Houses. Sorry, this made me laugh. I know there are software engineers which build clean and polished beautiful mega structures. I _aspire_ to that. Yet that is a niche market. In reality, most devs are making unique family Vilas at best. I wish I could ever say I feel like I contributed to an equivalent of 'Sydney Opera House'.

skeeter2020 3y ago
Most of us our building prefab housing, but the challenge is there's infinite ways to put the modules together, and unlike real housing no physics to reduce the problem set of possbilities.
- depereo 3y ago
  Even the prefab stuff has unknown unknowns - but everyone skimps on the geotechnical assessments of the ground you're building on...
- ehnto 3y ago
  And the prefab modules are all from different manufacturers who follow different standards.
  - masklinn 3y ago
    And some of the hands have a tendency to put electrical between module feet and to try and bond the modules with wood glue.
lcnPylGDnU4H9OF 3y ago
I am reminded of software like the “Snake” malware. Not exactly “ostentasteful” like the Sydney Opera House but grand and intricate with a specific, kinda-but-not-exactly unique purpose. (I’m sure there are other examples but my mind has an information security bias and I learned about “Snake” recently.) Not the bespoke CMS I work on for Bob’s Bait Shop.
xlii 3y ago

HankB99 3y ago

> in software you are always doing something new Yes, and invariably anything that comes up and wasn't accounted for in the estimate will take more time, not less.

quickthrower2 3y ago
Yes but only in waterfall do you need to accept that issue. In small “a” agile you can now go back to the business and suggest alternatives. (The Opera House was not built exactly to the original plans, for example). Of course that doesn’t work if you need to follow OKR dogma etc. and stick to the original plan.
- rurban 3y ago
  Which plans? There weren't any, just rough sketches, plus the requirements were constantly changing. They also started construction before the planning was finished.

deadfoxygrandpa 3y ago

everyone works on stuff that's more complicated than it looks from the outside, and many other fields are able to estimate the amount of work it takes to do something. why cant software? example: in 2006 china formalized plans to build a totally new high speed train system that spans the entire country by 2020, a totally new level of scale that had never been done before. and the plan worked out even a bit ahead of schedule. how did that planning happen? dont tell me that was simpler than your crud app

btilly 3y ago
Funny fact. When I was a relatively new programmer, we used to be told we had to become better at estimating, like architects are on construction projects. Then it became common knowledge that architects are as bad as we are at estimating costs. And people no longer use that comparison. The fields that are actually able to estimate work well tend to have one big advantage. They are estimating how to do standardized tasks that are similar to ones that they have done many times before. Ones that don't have that advantage, are as bad as we are.
- danielmarkbruce 3y ago
  There is a half decent book "How Big Things Get Done" which goes into some detail on this. TLDR - yes.
kortilla 3y ago
A train system is embarrassingly parallelized. It’s the equivalent of saying, we want to build 50 data centers in 3 years. It’s a lot, but it’s a lot of independent things that connect together at the end.
quickthrower2 3y ago
A falacy here is there are commercial just-crud apps. There are not. If it is just crud then just rails scaffold it, and estimate day 1 day. We could be better and more like the subset of real infrastructure projects that are on time and budget. There is probably a subset of software that is too. You need to a great waterfall. Probably allow prototypes that can be thrown away and have a decent budget for the design phase that will shore up the design and therefore the estimate. And have developers on one project. Hire project managers that are on their 15th ERP build and making a similar one for you. And use last decades tech so there are less uncertainties (probably not a bad idea for many things - gimme that winforms app without all the slower SPA spinners!) Even with all this what software lacks is classic Engineering (long degree, good concepts taught, respectable education over leetcode practice and so on). Problem is California will piss all over your business with move fast attitude unless you are boring enough to be off their radar. Be boring!

doctor_eval 3y ago

Totally agree with this. Most commercial software projects that I’ve worked on start with a horrific RFP process and legacy integrations that make otherwise simple projects into bespoke nightmares. The whole process of commercial software procurement and project assurance is a mess. And then you get consulting firms and body shops involved…

regularfry 3y ago

I actually disagree. Well, sort of. We can almost always say "it can't possibly take less than X". In fact, that X is often what gets given as the estimate, which is... not good, when you think about it. We can also often say "it is very unlikely to take more than Y". Between X and Y is the range of possible values for a real estimate. The problem comes when X and Y aren't just far apart, they're orders of magnitude apart. If you go back to your stakeholders with that range, what you should be able to hope for is a reasoned discussion not about how Y is too big (which it almost certainly will be) but on how to reduce the size of the range. That involves having more information about either the problem or the solution, so you (or they) are either off into more analysis, or you're into solution design. When you have a design in terms of subparts similar to things that have been built before, you've got something that's less Sydney Opera House and more Sydney Opera House LEGO Creator Expert Set 10234. So yes, at the specific point in time where someone asks you "how long to do this thing that's never been done before" there's almost certainly not enough information to give a response that bears relation to reality, but that should be the start of the conversation, not the end.