4 ms·

I really wish people would stop trying to reduce software development to simple metrics. Number of deploys is as meaningless as lines of code or number of story

I really wish people would stop trying to reduce software development to simple metrics. Number of deploys is as meaningless as lines of code or number of story points as a metric for judging people's performance.

CameronNemo 6y ago
Management is always looking for shortcuts and ways too avoid the difficult job of evaluating people's performance in an objective manner. They see scoreboards, and due dates, and activity streams as important tools for observability. But what they miss out on is the end performance of the actual product, and how individuals played a role in improving or worsening that performance.
- Ididntdothis 6y ago
  It seems all these short term metrics lead to people picking the simplest tasks and processing them at high volume. I could easily up my story point output by 10x if I picked the simplest bugs and stories from the backlog. Instead I take the most difficult ones where there often is no output for several weeks or longer. Thank god my manger sees the value in that. I would hate an environment where my output is measured in day or hour increments.
  - Swizec 6y ago
    > I could easily up my story point output by 10x if I picked the simplest bugs and stories from the backlog shouldn't those have comparably fewer points assigned? Completing 10 easy features/fixes should be roughly equal to completing 1 big one.
    - Ididntdothis 6y ago
      There are things on the backlog where nobody knows how long it will take. For example trying out something new or chasing down an elusive bug. It may take a few hours or it can take weeks or months.
    - OJFord 6y ago
      Time != Complexity; higher complexity makes time harder to estimate; complexity is easily underestimated or just completely unknown prior to at least some investigation. Obscure seeming bugs can be trivially fixed, or days of work to have any idea what's going on, let alone fixed.
mcny 6y ago
> I really wish people would stop trying to reduce software development to simple metrics. Number of deploys is as meaningless as lines of code or number of story points as a metric for judging people's performance. I mostly agree. I for one am a big fan of "painless" deploys. To me it means we should be able to deploy pretty much when we want to... My manager (also a programmer in previous life) once explained to me (privately) is we are neither waterfall nor agile or anything like that. We need to first have a repeatable process before we can even think about those things. (Officially, we were "agile" but that's beyond our pay grade.)
- Ididntdothis 6y ago
  “I mostly agree. I for one am a big fan of "painless" deploys. To me it means we should be able to deploy pretty much when we want to...” That’s a good goal.
- ashtonkem 6y ago
  What kind of “agile”? Officially I’ve only ever worked at agile shops, but the process has been radically different from company to company.
not_a_moth 6y ago
It does indicate a culture where there aren't massive barriers to getting changes in. I worked at one startup on the AI team, and we were allowed to deploy at will, we iterated constantly, pushed multi times a day, and had a flat hierarchy. We weren't under the political umbrella of the engineering and product groups. It was definitely risky but no major issues ever came from it and we gained the trust of DevOps team and our CTO. The back end team, different managers, was very hierarchical, had to schedule deploys well in advance and inside certain time windows, and non technical engineering managers would monitor and send summary emails to everyone after each deploy. Guess what, that back end team sucked. Their timelines for features were embarrassingly long, they watched the clock, their managers loved to booze, they overcomplicated the architecture and never produced anything innovative for the company. Deploys can signal culture.
- rcfox 6y ago
  Deploys is perhaps a good metric for engineers looking at managers, but not managers looking at engineers. (And definitely not managers looking at managers!)
- Ididntdothis 6y ago
  “Deploys can signal culture.“ They can signal culture maybe. But if you tell your back end team that you think their culture is bad because of not enough deploys they will crank up the number of deploys without fixing any of the deeper issues. All metrics like number of deploys , tickets closed , story points, number of commits are interesting data points but you should never try to optimize for them. Doing so signals lazy management that likes to beat around the bushes.
- majormajor 6y ago
  Numbers tell you what is happening, not why it is happening. If you see interesting numbers, you need to figure out the why, before just trying to move the numbers.
- darkerside 6y ago
  Just a bit of devil's advocate here, but is it possible that the problems they were solving were much more complicated than those on the AI team? Obviously I have little insight into the actual work, but there are some hints. Long timelines indicate difficulty interesting features into an already complex codebase. Leaving the office early can indicate that low quality hours had a higher downside risk of introducing problems into a complex situation. Pure speculation here, but I know that architecture can look overcomplicated when it's actually just solving a complicated problem.
m463 6y ago
Good story on metrics: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
austincheney 6y ago
More to the point: the statement itself is meaningless. It is a reductio ad absurdum summary of Rene Descartes 6 Meditations (On First Philosophy). Descartes did not actually state that line or anything directly resembling that line though it is a close approximation. A more precise summary would be something like: If I can doubt I can doubt away everything but doubting itself which is a base thinking machine. https://www.marxists.org/reference/archive/descartes/1639/meditations.htm https://www.marxists.org/reference/archive/descartes/1639/me...

CameronNemo 6y ago

Management is always looking for shortcuts and ways too avoid the difficult job of evaluating people's performance in an objective manner. They see scoreboards, and due dates, and activity streams as important tools for observability. But what they miss out on is the end performance of the actual product, and how individuals played a role in improving or worsening that performance.

Ididntdothis 6y ago
It seems all these short term metrics lead to people picking the simplest tasks and processing them at high volume. I could easily up my story point output by 10x if I picked the simplest bugs and stories from the backlog. Instead I take the most difficult ones where there often is no output for several weeks or longer. Thank god my manger sees the value in that. I would hate an environment where my output is measured in day or hour increments.
- Swizec 6y ago
  > I could easily up my story point output by 10x if I picked the simplest bugs and stories from the backlog shouldn't those have comparably fewer points assigned? Completing 10 easy features/fixes should be roughly equal to completing 1 big one.
  - Ididntdothis 6y ago
    There are things on the backlog where nobody knows how long it will take. For example trying out something new or chasing down an elusive bug. It may take a few hours or it can take weeks or months.
  - OJFord 6y ago
    Time != Complexity; higher complexity makes time harder to estimate; complexity is easily underestimated or just completely unknown prior to at least some investigation. Obscure seeming bugs can be trivially fixed, or days of work to have any idea what's going on, let alone fixed.

mcny 6y ago

> I really wish people would stop trying to reduce software development to simple metrics. Number of deploys is as meaningless as lines of code or number of story points as a metric for judging people's performance. I mostly agree. I for one am a big fan of "painless" deploys. To me it means we should be able to deploy pretty much when we want to... My manager (also a programmer in previous life) once explained to me (privately) is we are neither waterfall nor agile or anything like that. We need to first have a repeatable process before we can even think about those things. (Officially, we were "agile" but that's beyond our pay grade.)

Ididntdothis 6y ago
“I mostly agree. I for one am a big fan of "painless" deploys. To me it means we should be able to deploy pretty much when we want to...” That’s a good goal.
ashtonkem 6y ago
What kind of “agile”? Officially I’ve only ever worked at agile shops, but the process has been radically different from company to company.

not_a_moth 6y ago

It does indicate a culture where there aren't massive barriers to getting changes in. I worked at one startup on the AI team, and we were allowed to deploy at will, we iterated constantly, pushed multi times a day, and had a flat hierarchy. We weren't under the political umbrella of the engineering and product groups. It was definitely risky but no major issues ever came from it and we gained the trust of DevOps team and our CTO. The back end team, different managers, was very hierarchical, had to schedule deploys well in advance and inside certain time windows, and non technical engineering managers would monitor and send summary emails to everyone after each deploy. Guess what, that back end team sucked. Their timelines for features were embarrassingly long, they watched the clock, their managers loved to booze, they overcomplicated the architecture and never produced anything innovative for the company. Deploys can signal culture.

rcfox 6y ago
Deploys is perhaps a good metric for engineers looking at managers, but not managers looking at engineers. (And definitely not managers looking at managers!)
Ididntdothis 6y ago
“Deploys can signal culture.“ They can signal culture maybe. But if you tell your back end team that you think their culture is bad because of not enough deploys they will crank up the number of deploys without fixing any of the deeper issues. All metrics like number of deploys , tickets closed , story points, number of commits are interesting data points but you should never try to optimize for them. Doing so signals lazy management that likes to beat around the bushes.
majormajor 6y ago
Numbers tell you what is happening, not why it is happening. If you see interesting numbers, you need to figure out the why, before just trying to move the numbers.
darkerside 6y ago
Just a bit of devil's advocate here, but is it possible that the problems they were solving were much more complicated than those on the AI team? Obviously I have little insight into the actual work, but there are some hints. Long timelines indicate difficulty interesting features into an already complex codebase. Leaving the office early can indicate that low quality hours had a higher downside risk of introducing problems into a complex situation. Pure speculation here, but I know that architecture can look overcomplicated when it's actually just solving a complicated problem.

m463 6y ago

Good story on metrics: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

austincheney 6y ago

More to the point: the statement itself is meaningless. It is a reductio ad absurdum summary of Rene Descartes 6 Meditations (On First Philosophy). Descartes did not actually state that line or anything directly resembling that line though it is a close approximation. A more precise summary would be something like: If I can doubt I can doubt away everything but doubting itself which is a base thinking machine. https://www.marxists.org/reference/archive/descartes/1639/meditations.htm https://www.marxists.org/reference/archive/descartes/1639/me...