Hacker News Reader

Comment by Ididntdothis | Hacker News Reader

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.

View on HN

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.

Deploys is perhaps a good metric for engineers looking at managers, but not managers looking at engineers. (And definitely not managers looking at managers!)

“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.

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.

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.

Deploys can signal culture.

I worked at a company that deployed multiple times a day too. There were no automated tests and the QA process was terrible, so most of the deploys were bug fixes.

Deploys can signal culture, but not always in a good way.

It can also signal a lack of process and uncertainty about required features. A team that deploys a ton due to mistakes and unused features might end up less effective than a team that deploys more commonly used features with a more effective testing and verification harness.

This is why it’s hard to boil it down to a few simple metrics.

Good story on metrics:

https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

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.

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.

> 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.

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.

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.

> 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.)

“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.

What kind of “agile”? Officially I’ve only ever worked at agile shops, but the process has been radically different from company to company.

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/me...

Reply on news.ycombinator.com