5 ms·

I don't think there's any question that people always want this estimate. The problem with most software is that there really isn't one, since it's usually an o

I don't think there's any question that people always want this estimate. The problem with most software is that there really isn't one, since it's usually an open-ended search for a solution. Also, a job on his home is exactly what it should not be compared with, since that's the sort of repeatable job that can be estimated.

davidivadavid 4y ago
That begs for supporting evidence. I doubt most software is open-ended research.
- commandlinefan 4y ago
  > I doubt most software is open-ended research. No, just all software that provides any sort of tangible benefit to anybody. I’m sure you could estimate fairly accurately how long it would take to implement quicksort - but nobody’s going to ask you that.
- pulvinar 4y ago
  Frederick Brooks' "Mythical Man-Month" book is the classic answer. For my own evidence I base it on 50 years experience. I just wrote a piece of code that I had all working, but then I discovered a new method (requiring rewriting it all) that greatly improved it in every respect. So was I 90% done before that? Coding is just a very non-linear and never-ending process.
  - kube-system 4y ago
    You were 100% done. And then you discovered an opportunity for new work. I know many developers enjoy the art of software development and want to continually improve it, but that isn’t always the task you are being paid to do.
    - remkop22 4y ago
      This exactly. There are many ways to remodel a bathroom. Some more optimal than others. Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).
- sdeframond 4y ago
  An argument is that it is open-ended research by definition. Else we would just reuse something that already exists.
  - hgsgm 4y ago
    Some devs do work that could be replaced by software, but management doesn't know and the dev likes a paycheck.
  - yibg 4y ago
    That same argument can be applied to home renovations then. The carpenter has build many cabinets before, but perhaps not YOUR exact cabinet. So then no estimate is expected in that case?
    - yamtaddle 4y ago
      The carpenter rarely discovers a few days in that the screwdriver they have to use on this project only works every other week. Or that literally every measurement on every component is off by 20% because "that's how it's done" with whatever garbage you stuck them with. Vendors and even open-source libraries are often liars or just missing what seems like it ought to be obvious functionality. Sometimes tools are just broken. I once was assigned a Java AWS Lambda project, which, great, supported, right, says so right on the website? Except half the CLI tool functionality just didn't work, at the time, for Java projects, and I mean the official tools. It was alpha-tier supported at best. Usable, sorta, kinda, but you're gonna lose some time un-fucking the situation, and the whole thing would be slower to develop than it needed to be. You'd not know that unless you went and did a focused search on their issue tracker(s), which isn't really reasonable to do for all the stuff you might use in a typical project (some of which you might not even know you need until you've started work). "Great, so now you know that for estimating next time, if you get assigned a task exactly like that one" well, no, not really, because that was like four years ago and the situation's probably totally different now (maybe better, maybe worse, who knows?) That's why I think giving 4-8 weeks of development time with some basic t-shirt sizing or pointing for tasks and just seeing how it's going is better, before estimating. I think if you can't afford that, before getting the estimate, you can't afford a half-decent estimate at all and just need to deal with the fact you're going to get a terrible estimate with an absolutely huge range ("six to eighteen months"). Which, fine to ask for that up front then refine it after some dev time! It just needs to be clear and expected that those early estimates are going to have some wild variance—but they can definitely tell you "is this more a 1-year project, or more a 5-year project?" which does have some real value.
- nostrademons 4y ago
  If it's not you copy & modify a snippet from StackOverflow, or call a library. It's not strictly correct that most software is open-ended research. Most economically valuable software is open-ended research, because otherwise a solution already exists and you don't need to pay a software developer to write it. Software is a somewhat unique industry in having zero cost of replication. The only other industry like this is creative & artistic pursuits (writing, artwork, music, film, etc.). That industry is also notoriously difficult to estimate and tends to be an area where the the greatest works of art are done when they're done. (How long have people been waiting for George R. R. Martin to finish A Song of Ice and Fire?)
benjaminwootton 4y ago
Even if the job was incredibly small and predictable, my point is that he would likely not be prepared to sign off an open ended project with an uncapped budget.
- hgsgm 4y ago
  That's why he should sign off on a capped budget for an incremental milestone.
pydry 4y ago
I find it kind of funny how both sides take an "it's just not realistic" approach to each other's complaints and then the compromise is usually "You pretend you can make an estimate and I'll pretend to believe it".
ghaff 4y ago
>since that's the sort of repeatable job that can be estimated To some degree and depends on the job. Start opening up walls in an old house and tell me how cookie cutter it is. When I used to run shipyard jobs on offshore drilling rigs, I can tell you that every single job ran into all sorts of problems that were individually not predictable. It's also just nonsense to think that most software is this uniquely open-ended snowflake. Most engineering jobs require problem-solving that can be affected by all sorts of things in the physical world--plus you sometimes just have to build and try out designs and maybe they work, maybe they need to be refined a bit, and sometimes you have to toss them out and start again from scratch.
- kayodelycaon 4y ago
  I have an old house. More often than not, replacing a light fixture is a multi-day task.
  - wlonkly 4y ago
    I think that's the parent comment's point -- there are rabbit holes and yak shaving in old houses, but trades still estimate work on them all the time (and sometimes take the risk of binding quotes).
- vegetablepotpie 4y ago
  You’re right, there is a high variability in the complexity in physical tasks just based on factors you cannot predict. The quality of things that impact physical work versus software is fundamentally different. I see people on here post construction projects as the poster child for things that can be estimated with traditional project management techniques. This is wrong because most construction projects come in over cost and over schedule. This can be because materials costs change, labor costs change, the soil at your site may not be what you expected, weather impacts, and stakeholders may demand something different after the project is estimated. Although these are unknown quantities, these factors existence are known. Whereas in software, you’re more likely to encounter unknown unknowns. These are factors that nobody thinks are even possibilities until you run into them because nobody has done anything similar before. An example from my experience is when I was working on implementing a marching cubes algorithm on a GPU, we did research to make sure that you could do it. But when it came time to implement, we found that the cube data was expressed as a set of faces, and not a set of vertexes and no efficient algorithm existed for that expression of the data that could be mapped to a single instruction multiple data paradigm. We could not preprocess the data to convert it to vertexes because it would not offer any speed up if we did. To implement the acceleration we wanted, you’d have to change how the data was stored in the application. Which is a very different project with very different timescales. We ended up abandoning the effort and moved to other work. This happened because we made a discovery that no one could have predicted, in the implementation, that had an unknown impact. In physical projects, you might find there are a lot of unknown things that can happen, that you may not predict. You can certainly reduce this by bringing in experts to a project, people who have seen much more than you. Certainly there is still potential for black swan events. But these are rare. Where as in software, the experts you may bring on may not necessarily know more than you, you are frequently your own expert. Black swan events in software projects are common.

davidivadavid 4y ago

That begs for supporting evidence. I doubt most software is open-ended research.

commandlinefan 4y ago
> I doubt most software is open-ended research. No, just all software that provides any sort of tangible benefit to anybody. I’m sure you could estimate fairly accurately how long it would take to implement quicksort - but nobody’s going to ask you that.
pulvinar 4y ago
Frederick Brooks' "Mythical Man-Month" book is the classic answer. For my own evidence I base it on 50 years experience. I just wrote a piece of code that I had all working, but then I discovered a new method (requiring rewriting it all) that greatly improved it in every respect. So was I 90% done before that? Coding is just a very non-linear and never-ending process.
- kube-system 4y ago
  You were 100% done. And then you discovered an opportunity for new work. I know many developers enjoy the art of software development and want to continually improve it, but that isn’t always the task you are being paid to do.
  - remkop22 4y ago
    This exactly. There are many ways to remodel a bathroom. Some more optimal than others. Now imagine your plumber tells you he discovered a better layout for the plumbing just after finishing his work, then he enthusiastically asks if he could tear everything out and start over (and pay him for it).
sdeframond 4y ago
An argument is that it is open-ended research by definition. Else we would just reuse something that already exists.
- hgsgm 4y ago
  Some devs do work that could be replaced by software, but management doesn't know and the dev likes a paycheck.
- yibg 4y ago
  That same argument can be applied to home renovations then. The carpenter has build many cabinets before, but perhaps not YOUR exact cabinet. So then no estimate is expected in that case?
  - yamtaddle 4y ago
    The carpenter rarely discovers a few days in that the screwdriver they have to use on this project only works every other week. Or that literally every measurement on every component is off by 20% because "that's how it's done" with whatever garbage you stuck them with. Vendors and even open-source libraries are often liars or just missing what seems like it ought to be obvious functionality. Sometimes tools are just broken. I once was assigned a Java AWS Lambda project, which, great, supported, right, says so right on the website? Except half the CLI tool functionality just didn't work, at the time, for Java projects, and I mean the official tools. It was alpha-tier supported at best. Usable, sorta, kinda, but you're gonna lose some time un-fucking the situation, and the whole thing would be slower to develop than it needed to be. You'd not know that unless you went and did a focused search on their issue tracker(s), which isn't really reasonable to do for all the stuff you might use in a typical project (some of which you might not even know you need until you've started work). "Great, so now you know that for estimating next time, if you get assigned a task exactly like that one" well, no, not really, because that was like four years ago and the situation's probably totally different now (maybe better, maybe worse, who knows?) That's why I think giving 4-8 weeks of development time with some basic t-shirt sizing or pointing for tasks and just seeing how it's going is better, before estimating. I think if you can't afford that, before getting the estimate, you can't afford a half-decent estimate at all and just need to deal with the fact you're going to get a terrible estimate with an absolutely huge range ("six to eighteen months"). Which, fine to ask for that up front then refine it after some dev time! It just needs to be clear and expected that those early estimates are going to have some wild variance—but they can definitely tell you "is this more a 1-year project, or more a 5-year project?" which does have some real value.
nostrademons 4y ago
If it's not you copy & modify a snippet from StackOverflow, or call a library. It's not strictly correct that most software is open-ended research. Most economically valuable software is open-ended research, because otherwise a solution already exists and you don't need to pay a software developer to write it. Software is a somewhat unique industry in having zero cost of replication. The only other industry like this is creative & artistic pursuits (writing, artwork, music, film, etc.). That industry is also notoriously difficult to estimate and tends to be an area where the the greatest works of art are done when they're done. (How long have people been waiting for George R. R. Martin to finish A Song of Ice and Fire?)

benjaminwootton 4y ago

Even if the job was incredibly small and predictable, my point is that he would likely not be prepared to sign off an open ended project with an uncapped budget.

hgsgm 4y ago
That's why he should sign off on a capped budget for an incremental milestone.

pydry 4y ago

I find it kind of funny how both sides take an "it's just not realistic" approach to each other's complaints and then the compromise is usually "You pretend you can make an estimate and I'll pretend to believe it".

ghaff 4y ago

>since that's the sort of repeatable job that can be estimated To some degree and depends on the job. Start opening up walls in an old house and tell me how cookie cutter it is. When I used to run shipyard jobs on offshore drilling rigs, I can tell you that every single job ran into all sorts of problems that were individually not predictable. It's also just nonsense to think that most software is this uniquely open-ended snowflake. Most engineering jobs require problem-solving that can be affected by all sorts of things in the physical world--plus you sometimes just have to build and try out designs and maybe they work, maybe they need to be refined a bit, and sometimes you have to toss them out and start again from scratch.

kayodelycaon 4y ago
I have an old house. More often than not, replacing a light fixture is a multi-day task.
- wlonkly 4y ago
  I think that's the parent comment's point -- there are rabbit holes and yak shaving in old houses, but trades still estimate work on them all the time (and sometimes take the risk of binding quotes).
vegetablepotpie 4y ago
You’re right, there is a high variability in the complexity in physical tasks just based on factors you cannot predict. The quality of things that impact physical work versus software is fundamentally different. I see people on here post construction projects as the poster child for things that can be estimated with traditional project management techniques. This is wrong because most construction projects come in over cost and over schedule. This can be because materials costs change, labor costs change, the soil at your site may not be what you expected, weather impacts, and stakeholders may demand something different after the project is estimated. Although these are unknown quantities, these factors existence are known. Whereas in software, you’re more likely to encounter unknown unknowns. These are factors that nobody thinks are even possibilities until you run into them because nobody has done anything similar before. An example from my experience is when I was working on implementing a marching cubes algorithm on a GPU, we did research to make sure that you could do it. But when it came time to implement, we found that the cube data was expressed as a set of faces, and not a set of vertexes and no efficient algorithm existed for that expression of the data that could be mapped to a single instruction multiple data paradigm. We could not preprocess the data to convert it to vertexes because it would not offer any speed up if we did. To implement the acceleration we wanted, you’d have to change how the data was stored in the application. Which is a very different project with very different timescales. We ended up abandoning the effort and moved to other work. This happened because we made a discovery that no one could have predicted, in the implementation, that had an unknown impact. In physical projects, you might find there are a lot of unknown things that can happen, that you may not predict. You can certainly reduce this by bringing in experts to a project, people who have seen much more than you. Certainly there is still potential for black swan events. But these are rare. Where as in software, the experts you may bring on may not necessarily know more than you, you are frequently your own expert. Black swan events in software projects are common.