4 ms·

This is a pipe dream. And I say this as a developer, not a manager or business owner. In particular: > Estimates are to be avoided at all cost. How is an exe

This is a pipe dream. And I say this as a developer, not a manager or business owner. In particular: > Estimates are to be avoided at all cost. How is an executive supposed to decide what I should work on next if I don't provide estimates of the things that I could work on? Besides that, I wouldn't like it if I asked when I'd get my next paycheck and the response was, "You'll get it when you get it. Leave me alone."

parenthephobia 10y ago
> How is an executive supposed to decide what I should work on next if I don't provide estimates of the things that I could work on? I dunno. Maybe ask an executive at one of the many companies that have scientists or mathematicians on staff how they do it.
- mwcampbell 10y ago
  Those folks are probably working in a research lab, though, not in product development. And few companies these days have that luxury. My father has been an engineer (not in software) for decades. I haven't asked him about this yet, but I'm guessing he has to provide estimates for his projects.
  - dudul 10y ago
    There is a very big difference between a software "engineer" and a real engineer. I personally think that picking the word "engineer" to describe our profession does us more harm than good.
    - mwcampbell 10y ago
      There is indeed a difference, but I don't think it makes us software developers look very good. Shouldn't we at least aspire to the same level of professionalism and quality that good engineers have achieved?
      - dudul 10y ago
        > Shouldn't we at least aspire to the same level of professionalism and quality that good engineers have achieved? My point was that we cannot really, because we are not engineers. Nothing in what we do is even close to what civil engineers do for example. Neither our tools, nor our workflows, or our constraints, really nothing. I think the day we decided to call ourselves "engineers" we made a mistake, that's it.
      - pkolaczk 10y ago
        My father is a mechanical engineer and he says the amount of problems in the designs he reviews is very high, contrary to popular beliefs. There are often multiple rounds required to clean things up and some problems are discovered at build time. Buildings and bridges are not falling down because they are much less complex and more similar to each other than software projects.
      - deleted 10y ago
        [deleted]
- marcus_holmes 10y ago
  well, in the places that employ artists (same problem, different field), management tend to tell the creatives how long they've got to get it done. But it's a lot easier for a manager to conceptualise how long a piece of art will take to do than a piece of code.
  - parenthephobia 10y ago
    I dispute that it's the same problem. Graphic art-ing is quite different to programming. One significant difference is that you can just look at a drawing and know if it's okay or not. There's no test suite for graphic art. Drawing outside the lines is a stylistic choice. Compiler errors are not. The stuff a graphic artist will be fastest at, and for which estimating will be easiest, is stuff they've done thousands of times before. Most programmers aren't writing code they've written thousands of times before, unless they're not paying attention. Out of the creative arts field, I think programming is probably most like creative writing. The grander the program, the grander the equivalent narrative. Unlike a picture, you can't just look at a book and know if it's written properly, you have to read it through. Not only do you have to worry about grammar, you also have to be concerned that the narrative is internally consistent, and that it features the themes, characters, and dramatic situations specified in the brief. Of course, the analogy still isn't exact. A novel doesn't actually have to be internally consistent, and the book doesn't crash if there are spelling mistakes. In fact, many novels written without taking spending the time and money to edit it properly will have plot holes or grammatical errors. A reader can fuzz past it, but a computer can't. Ask a writer how long it will take to write a novel that is totally internally consistent, leaves no plot threads unresolved, and has no grammatical errors. They'll tell you it can't be done to schedule.
    - marcus_holmes 10y ago
      Think portrait painter or graphic artist. They have very specific briefs, and a set time to complete them in. But yes, creative writing works as well. And creative writers are given deadlines.
    - CJefferson 10y ago
daryl_antony 10y ago
No one likes uncertainty, but it turns out that time estimation the thing we get wrong the most. Perhaps try sizing via t-shirt sizes, S, M, L etc. and then build up some team historical data on how long it takes everyone to get something all the way to production. The both the business and development team can point to the historical data set as the best indicator of history repeating and we can leave hunches and guesses out of it.
- wlamartin 10y ago
  I'm not sure if this is ironic but to me it seems you are just describing how agile is supposed to work. In my team our features are fibonacci pointed but I've seen only two 5s in the history of the project. By far the vast majority are 1 and 2 with the occasional 3. This correlates with your S, M, L thoughts. The Product Manager can then prioritise based on these (i.e. these three single point stories deliver more value than that three pointer) and points are internally calibrated over time. I have to say though, that my team doesn't really have "deadline" releases and the PM releases any time we deliver something of value to our users, so it helps relieve some of the burdens about estimating i.e. When I point, I don't really care if the points don't end up reflecting time.
dosethree 10y ago
Executes should have some rough sizing of large undertakings for making high level business decisions - I don't think that's what the author is referring to.

parenthephobia 10y ago

> How is an executive supposed to decide what I should work on next if I don't provide estimates of the things that I could work on? I dunno. Maybe ask an executive at one of the many companies that have scientists or mathematicians on staff how they do it.

mwcampbell 10y ago
Those folks are probably working in a research lab, though, not in product development. And few companies these days have that luxury. My father has been an engineer (not in software) for decades. I haven't asked him about this yet, but I'm guessing he has to provide estimates for his projects.
- dudul 10y ago
  There is a very big difference between a software "engineer" and a real engineer. I personally think that picking the word "engineer" to describe our profession does us more harm than good.
  - mwcampbell 10y ago
    There is indeed a difference, but I don't think it makes us software developers look very good. Shouldn't we at least aspire to the same level of professionalism and quality that good engineers have achieved?
    - dudul 10y ago
      > Shouldn't we at least aspire to the same level of professionalism and quality that good engineers have achieved? My point was that we cannot really, because we are not engineers. Nothing in what we do is even close to what civil engineers do for example. Neither our tools, nor our workflows, or our constraints, really nothing. I think the day we decided to call ourselves "engineers" we made a mistake, that's it.
    - pkolaczk 10y ago
      My father is a mechanical engineer and he says the amount of problems in the designs he reviews is very high, contrary to popular beliefs. There are often multiple rounds required to clean things up and some problems are discovered at build time. Buildings and bridges are not falling down because they are much less complex and more similar to each other than software projects.
    - deleted 10y ago
      [deleted]
marcus_holmes 10y ago
well, in the places that employ artists (same problem, different field), management tend to tell the creatives how long they've got to get it done. But it's a lot easier for a manager to conceptualise how long a piece of art will take to do than a piece of code.
- parenthephobia 10y ago
  I dispute that it's the same problem. Graphic art-ing is quite different to programming. One significant difference is that you can just look at a drawing and know if it's okay or not. There's no test suite for graphic art. Drawing outside the lines is a stylistic choice. Compiler errors are not. The stuff a graphic artist will be fastest at, and for which estimating will be easiest, is stuff they've done thousands of times before. Most programmers aren't writing code they've written thousands of times before, unless they're not paying attention. Out of the creative arts field, I think programming is probably most like creative writing. The grander the program, the grander the equivalent narrative. Unlike a picture, you can't just look at a book and know if it's written properly, you have to read it through. Not only do you have to worry about grammar, you also have to be concerned that the narrative is internally consistent, and that it features the themes, characters, and dramatic situations specified in the brief. Of course, the analogy still isn't exact. A novel doesn't actually have to be internally consistent, and the book doesn't crash if there are spelling mistakes. In fact, many novels written without taking spending the time and money to edit it properly will have plot holes or grammatical errors. A reader can fuzz past it, but a computer can't. Ask a writer how long it will take to write a novel that is totally internally consistent, leaves no plot threads unresolved, and has no grammatical errors. They'll tell you it can't be done to schedule.
  - marcus_holmes 10y ago
    Think portrait painter or graphic artist. They have very specific briefs, and a set time to complete them in. But yes, creative writing works as well. And creative writers are given deadlines.
  - CJefferson 10y ago

daryl_antony 10y ago

No one likes uncertainty, but it turns out that time estimation the thing we get wrong the most. Perhaps try sizing via t-shirt sizes, S, M, L etc. and then build up some team historical data on how long it takes everyone to get something all the way to production. The both the business and development team can point to the historical data set as the best indicator of history repeating and we can leave hunches and guesses out of it.

wlamartin 10y ago
I'm not sure if this is ironic but to me it seems you are just describing how agile is supposed to work. In my team our features are fibonacci pointed but I've seen only two 5s in the history of the project. By far the vast majority are 1 and 2 with the occasional 3. This correlates with your S, M, L thoughts. The Product Manager can then prioritise based on these (i.e. these three single point stories deliver more value than that three pointer) and points are internally calibrated over time. I have to say though, that my team doesn't really have "deadline" releases and the PM releases any time we deliver something of value to our users, so it helps relieve some of the burdens about estimating i.e. When I point, I don't really care if the points don't end up reflecting time.

dosethree 10y ago

Executes should have some rough sizing of large undertakings for making high level business decisions - I don't think that's what the author is referring to.