5 ms·

It is generally the truth, though. I can't tell you how long it will take, because I don't know, because I've never done it before. If I've done it before, or

It is generally the truth, though. I can't tell you how long it will take, because I don't know, because I've never done it before. If I've done it before, or something enough like it that I actually could tell you how long it would take, then you are wasting your money and my time by asking me to repeat the work. If you hired me because you wanted me to do the same thing for you that I once did for someone else, and you therefore expect me to be able to tell you how long it is going to take, then I will start polishing up my resume, because I made a mistake when I accepted your offer.

tyingq 11y ago
That's fairly personal, down to the "you" level. What I'm saying is that it doesn't matter if it's a software project, construction project, etc. If the potential amount is non-trivial, it's bad business to commit to a completely unknown amount of spend. If you can't say that the spend < benefit, you really shouldn't do the work. It's basically speculative investment at that point. That may be something you personally aren't on the hook for. But, in most cases, there's some option to get an idea. Bids from outside software development shops, calls to companies you partner with, small scale prototype, agreement to spend a fixed amount and re-evaluate, etc.
- marssaxman 11y ago
  It very much does matter if it's a software project or a construction project, because the essence of a software project is that it involves an exploration into the unknown. If it were a routine process which could be estimated accurately, we'd have automated it already, and we wouldn't need to estimate it because we'd simply delegate it to a machine. Software is nothing like construction. We don't build bridges, we draw blueprints for bridges, which our construction robots then build overnight; if it's a good bridge, millions of other construction robots go build millions more bridges just like it. If the bridge doesn't work, we have the construction robots tear it apart, and we try again with another one the next day. When we get good enough at designing bridges that we start to see the patterns involved, we build a robot that draws bridge blueprints, and we have the blueprint robot tell the construction robots what to do while we sit around and think about urban design theory. When we get good enough at thinking about where bridges ought to be placed and what attributes they ought to have, we build ourselves a highway-design robot that orders around the bridge-blueprint robot that orders around the construction robots, and then we move on and start thinking about something more interesting. Software is basically speculative investment. That is why we make the big bucks when our projects succeed.
  - tyingq 11y ago
    some software is speculative investment. edit: fwiw, construction projects often touch on "exploration into the unknown". Also, you are arguing against "accurate estimation". I'm arguing against the premise of the article. "No kind of estimation is possible" Edit. Nobody is asking for made up numbers. They are typically asking that engineers participate in a reasonable discussion to try and get some criteria to make a decision. "I couldn't even say 1 week vs 10 years" is just as silly as "I want an exact number".
    - marssaxman 11y ago
      Sure, and to the degree that they do, they can't be accurately estimated either. ... Even if the words people are saying sound like "We want to build this; how long will it take?", the process which actually happens is "We have this much money/time, and we want to solve this problem; what can we build in the time available?" To the degree that people believe they are operating in the former mode, sadness happens, because software engineering is actually about the latter.
    - marssaxman 11y ago
      Well, okay, sure, if you want me to make some numbers up, I can do that. Just understand that you're not actually asking me to estimate the time a process will take, you're asking me to make some numbers up so that you can convince yourself to feel good about the speculative investment you're making! Edit: we've apparently had different experiences around the word "estimate"; for me that's always been a term used by managers who want something they can slot into a Gantt chart or its equivalent, and trying to play along with that game has always led to frustration. The people in my experience who have been looking for "some criteria to make a decision" haven't generally called the information they're looking for an "estimate". The processes which have actually worked, in my experience, don't start with tasks and try to generate a schedule which fits: instead, the process starts with a schedule, and the engineer's job is to figure out what can be done in the time available and how most effectively to make progress within that framework.
  - the_why_of_y 11y ago
    Even more so, there is an analogy to construction in software, and it has been possible to fully automate it since decades with tools like make, ant, etc.

tyingq 11y ago

That's fairly personal, down to the "you" level. What I'm saying is that it doesn't matter if it's a software project, construction project, etc. If the potential amount is non-trivial, it's bad business to commit to a completely unknown amount of spend. If you can't say that the spend < benefit, you really shouldn't do the work. It's basically speculative investment at that point. That may be something you personally aren't on the hook for. But, in most cases, there's some option to get an idea. Bids from outside software development shops, calls to companies you partner with, small scale prototype, agreement to spend a fixed amount and re-evaluate, etc.

marssaxman 11y ago
It very much does matter if it's a software project or a construction project, because the essence of a software project is that it involves an exploration into the unknown. If it were a routine process which could be estimated accurately, we'd have automated it already, and we wouldn't need to estimate it because we'd simply delegate it to a machine. Software is nothing like construction. We don't build bridges, we draw blueprints for bridges, which our construction robots then build overnight; if it's a good bridge, millions of other construction robots go build millions more bridges just like it. If the bridge doesn't work, we have the construction robots tear it apart, and we try again with another one the next day. When we get good enough at designing bridges that we start to see the patterns involved, we build a robot that draws bridge blueprints, and we have the blueprint robot tell the construction robots what to do while we sit around and think about urban design theory. When we get good enough at thinking about where bridges ought to be placed and what attributes they ought to have, we build ourselves a highway-design robot that orders around the bridge-blueprint robot that orders around the construction robots, and then we move on and start thinking about something more interesting. Software is basically speculative investment. That is why we make the big bucks when our projects succeed.
- tyingq 11y ago
  some software is speculative investment. edit: fwiw, construction projects often touch on "exploration into the unknown". Also, you are arguing against "accurate estimation". I'm arguing against the premise of the article. "No kind of estimation is possible" Edit. Nobody is asking for made up numbers. They are typically asking that engineers participate in a reasonable discussion to try and get some criteria to make a decision. "I couldn't even say 1 week vs 10 years" is just as silly as "I want an exact number".
  - marssaxman 11y ago
    Sure, and to the degree that they do, they can't be accurately estimated either. ... Even if the words people are saying sound like "We want to build this; how long will it take?", the process which actually happens is "We have this much money/time, and we want to solve this problem; what can we build in the time available?" To the degree that people believe they are operating in the former mode, sadness happens, because software engineering is actually about the latter.
  - marssaxman 11y ago
    Well, okay, sure, if you want me to make some numbers up, I can do that. Just understand that you're not actually asking me to estimate the time a process will take, you're asking me to make some numbers up so that you can convince yourself to feel good about the speculative investment you're making! Edit: we've apparently had different experiences around the word "estimate"; for me that's always been a term used by managers who want something they can slot into a Gantt chart or its equivalent, and trying to play along with that game has always led to frustration. The people in my experience who have been looking for "some criteria to make a decision" haven't generally called the information they're looking for an "estimate". The processes which have actually worked, in my experience, don't start with tasks and try to generate a schedule which fits: instead, the process starts with a schedule, and the engineer's job is to figure out what can be done in the time available and how most effectively to make progress within that framework.
- the_why_of_y 11y ago
  Even more so, there is an analogy to construction in software, and it has been possible to fully automate it since decades with tools like make, ant, etc.