3 ms·

I find naive and pretentious the suggestion that the average programmer's work is in any way akin to Einstein's search for the truth about our universe. My crit

by maxaf 10y ago

I find naive and pretentious the suggestion that the average programmer's work is in any way akin to Einstein's search for the truth about our universe. My criticism might seem nitpicky until it's time to measure this article's message against the possible reaction of an engineering or business manager. Launching into a systematic dismantling of the pervasive estimates culture is best done with humble, verifiable assertions and helpful suggestions in tow. Attempting to recruit the long-dead Einstein is unhelpful and hand-wavy. There must be a better way to package the no-estimates message, and it's not this.

ktRolster 10y ago
I find naive and pretentious the suggestion that the average programmer's work is in any way akin to Einstein's search for the truth about our universe. Indeed, most projects are remarkably (and sadly) similar to other projects we've done before.
- markbnj 10y ago
  It doesn't much matter how "similar" they are. Unless you can copy and paste the code you're building new stuff and running the risk of encountering all the issues inherent in building new stuff.
woodchuck64 10y ago
How about: the reliability of software estimates are inversely proportional to creativity requirements, with a unified theory of physics establishing an upper bound on creativity with a corresponding 0 for the estimate reliability.
manyxcxi 10y ago
The thing is that for many companies no estimates isn't possible. You have to be able to tell a client roughly how much they are going to get charged or how long it will take on order for them to even be able to with the options. Saying no estimates is akin to saying "this is hard, we suck at it so we quit." The problem isn't solved, you still have no way of measuring how complete you are and when you'll be able to turn new things on. We use a combination of story points and historical reference where we can during our estimating phase. So if we are talking about adding a new feature and wet estimate it out we go look at the actuals from a similar change that we did before to see how is base we might be. We also like story points because they are a ballpark and help us judge if we are estimating reasonably well. If we are continually having things signed low points that take data to finish, we can address that. Fast feedback and lots of iterations. The thing teams fail to do is to measure properly. If you measure too much no one fills out their stuff accurately and then you've just got garbage. Measure the wrong things and you're blind. Measure nothing (no estimates) and you're just giving yo. We don't try to measure to the minute or hour. Things are basically 'quick' 1hr or less, 2hrs, 1/2 day, 1 day, or a 1/2 week for a task we know is big and hairy that has a lot of sub tasks that we don't really want to dive into the minutiae of it because what's relevant is that X does A and B, not that X requires T, U, and V to be done first. That's the hard part for us, enough detail that its meaningful without spending all your time planning to plan.
composer 10y ago
Or how about: ReRe's Law of Repetition and Redundancy [1] A programmer can accurately estimate the schedule only for the repeated and the redundant. Yet, A programmer's job is to automate the repeated and the redundant. Thus, A programmer delivering to an estimated or predictable schedule is... Not doing their job (or is redundant). [1] https://news.ycombinator.com/item?id=11576683 https://news.ycombinator.com/item?id=11576683

by maxaf 10y ago

ktRolster 10y ago

I find naive and pretentious the suggestion that the average programmer's work is in any way akin to Einstein's search for the truth about our universe. Indeed, most projects are remarkably (and sadly) similar to other projects we've done before.

markbnj 10y ago
It doesn't much matter how "similar" they are. Unless you can copy and paste the code you're building new stuff and running the risk of encountering all the issues inherent in building new stuff.

woodchuck64 10y ago

How about: the reliability of software estimates are inversely proportional to creativity requirements, with a unified theory of physics establishing an upper bound on creativity with a corresponding 0 for the estimate reliability.

manyxcxi 10y ago

The thing is that for many companies no estimates isn't possible. You have to be able to tell a client roughly how much they are going to get charged or how long it will take on order for them to even be able to with the options. Saying no estimates is akin to saying "this is hard, we suck at it so we quit." The problem isn't solved, you still have no way of measuring how complete you are and when you'll be able to turn new things on. We use a combination of story points and historical reference where we can during our estimating phase. So if we are talking about adding a new feature and wet estimate it out we go look at the actuals from a similar change that we did before to see how is base we might be. We also like story points because they are a ballpark and help us judge if we are estimating reasonably well. If we are continually having things signed low points that take data to finish, we can address that. Fast feedback and lots of iterations. The thing teams fail to do is to measure properly. If you measure too much no one fills out their stuff accurately and then you've just got garbage. Measure the wrong things and you're blind. Measure nothing (no estimates) and you're just giving yo. We don't try to measure to the minute or hour. Things are basically 'quick' 1hr or less, 2hrs, 1/2 day, 1 day, or a 1/2 week for a task we know is big and hairy that has a lot of sub tasks that we don't really want to dive into the minutiae of it because what's relevant is that X does A and B, not that X requires T, U, and V to be done first. That's the hard part for us, enough detail that its meaningful without spending all your time planning to plan.

composer 10y ago

Or how about: ReRe's Law of Repetition and Redundancy [1] A programmer can accurately estimate the schedule only for the repeated and the redundant. Yet, A programmer's job is to automate the repeated and the redundant. Thus, A programmer delivering to an estimated or predictable schedule is... Not doing their job (or is redundant). [1] https://news.ycombinator.com/item?id=11576683 https://news.ycombinator.com/item?id=11576683