4 ms·

The only quasi-interesting property this has is that it can change over time. Nothing you said changes the main problem: gold stars are weeks and we all know i

The only quasi-interesting property this has is that it can change over time. Nothing you said changes the main problem: gold stars are weeks and we all know it. Next year they are two weeks, fine.

bluefirebrand 3y ago
"You said it would take a week" "No I said it was 12 jellybeans" "but we all know that 12 jellybeans is a week!!" "No, we all know that 12 jellybeans is explicitly not a week. It just happens that 12 jellybeans has taken 'around a week' in the past. An estimate of 12 jellybeans is still not a promise that it will only take a week."
- chasd00 3y ago
  then "ok, well i'm not paying you until what i asked for is in production".
  - bluefirebrand 3y ago
    Withholding salaries is a crime, so... I strongly doubt it.
Izkata 3y ago
This mapping falls apart when the individual devs have different levels of experience. A gold star is a different unit of time per individual; Dev A might be able to complete 1 gold star in 1 week, but Dev B with less experience takes 2 weeks. The right thing to do isn't to estimate the average 1.5 weeks, since the case might not actually be done for another month, and it might end up actually being done by Dev C who just joined the team, for who 1 gold star is currently 3 or 4 weeks.
- konschubert 3y ago
  A team has an average.
  - willcipriano 3y ago
    If you took all the winning lottery numbers you could probably find a average as well.
    - konschubert 3y ago
      This is a nonsensical response. An absolute non sequitur
ohthehugemanate 3y ago
No, they are not weeks, and the minute "we all know it" you are fucked. Engineers are not concerned with time. They are concerned with feature completeness and quality. They do not care how long a task takes, only that it is done Right. When the PM asks how hard it is, that's their only consideration. The PM only cares about time to make accurate predictions for the rest of the business. A given task takes as long as it takes to be done Right. If the business wants it on a different timeline, the business has to redefine the task, or redefine Right (ie skipping tests or doco). Research bears it out: human brains suck at estimating time, and are much better as soon as you talk in terms of effort. BUT if you want to insist on brute forcing through our cognitive biases, I have good news: you can do almost as well by tracking the relationship between "developer time" and "real time". You're still dealing in abstracted units, of course, but you can still pretend you aren't, which is the important thing.
- SanderNL 3y ago
  I get the sentiment, but ultimately business is time-bound. Everything is about time. But now we have a bunch of “engineers” (that somehow are fundamentally incapable of structured planning and execution) that are “not concerned with time”. I found your characterization of engineers and PMs not useful and a bit childish. This is not how money is made. Let’s just agree I don’t understand this. You sound well-informed and I’m just a simpleton.

The only quasi-interesting property this has is that it can change over time. Nothing you said changes the main problem: gold stars are weeks and we all know it. Next year they are two weeks, fine.

bluefirebrand 3y ago

"You said it would take a week" "No I said it was 12 jellybeans" "but we all know that 12 jellybeans is a week!!" "No, we all know that 12 jellybeans is explicitly not a week. It just happens that 12 jellybeans has taken 'around a week' in the past. An estimate of 12 jellybeans is still not a promise that it will only take a week."

chasd00 3y ago
then "ok, well i'm not paying you until what i asked for is in production".
- bluefirebrand 3y ago
  Withholding salaries is a crime, so... I strongly doubt it.

Izkata 3y ago

This mapping falls apart when the individual devs have different levels of experience. A gold star is a different unit of time per individual; Dev A might be able to complete 1 gold star in 1 week, but Dev B with less experience takes 2 weeks. The right thing to do isn't to estimate the average 1.5 weeks, since the case might not actually be done for another month, and it might end up actually being done by Dev C who just joined the team, for who 1 gold star is currently 3 or 4 weeks.

konschubert 3y ago
A team has an average.
- willcipriano 3y ago
  If you took all the winning lottery numbers you could probably find a average as well.
  - konschubert 3y ago
    This is a nonsensical response. An absolute non sequitur

ohthehugemanate 3y ago

No, they are not weeks, and the minute "we all know it" you are fucked. Engineers are not concerned with time. They are concerned with feature completeness and quality. They do not care how long a task takes, only that it is done Right. When the PM asks how hard it is, that's their only consideration. The PM only cares about time to make accurate predictions for the rest of the business. A given task takes as long as it takes to be done Right. If the business wants it on a different timeline, the business has to redefine the task, or redefine Right (ie skipping tests or doco). Research bears it out: human brains suck at estimating time, and are much better as soon as you talk in terms of effort. BUT if you want to insist on brute forcing through our cognitive biases, I have good news: you can do almost as well by tracking the relationship between "developer time" and "real time". You're still dealing in abstracted units, of course, but you can still pretend you aren't, which is the important thing.

SanderNL 3y ago
I get the sentiment, but ultimately business is time-bound. Everything is about time. But now we have a bunch of “engineers” (that somehow are fundamentally incapable of structured planning and execution) that are “not concerned with time”. I found your characterization of engineers and PMs not useful and a bit childish. This is not how money is made. Let’s just agree I don’t understand this. You sound well-informed and I’m just a simpleton.