[sdesol]

Disclaimer: I'm a competitor of Okay along with others in the software development metrics space.

I just want to comment on

> We also learned that the discussion about engineering metrics always falls into a false dichotomy: don’t measure anything because engineering is creative work (it is!) or measure engineers in intrusive ways along meaningless dimensions like lines of code.

I think with close to 50 years of doing things wrong with software development metrics, we've left a very bitter taste in the mouths of developers and it is fully understandable that developers would be weary and skeptical of software development metrics. It is certainly one sided and I do agree this false dichotomy needs to be addressed.

When it is all over, if software development metrics is done right (with the emphasis on done right), developers should be the ones advocating for it, since it means:

- They can work more efficiently since software metrics can help them better understand how a piece of code came to be

- Better sell themselves for promotions and raises. For example, they can use it to highlight impact and what it means if they leave. Their manager may know they are a top contributor but if their manager can't sell them, it won't help. With software metrics, manager's should be able to highlight how their developer is having an impact when the raise/promotion pool is divided up.

- And so forth

I honestly think the best way to get everybody onboard with metrics, is to clearly show that it takes effort to generate meaningful insights. And this is why I'm not so much focused on providing canned reports, but rather, I want to provide business intelligence for the software development lifecycle.

The goal (which it sounds like Okay is working towards as well) is to connect all the dots in the software development lifecycle and provide users with the necessary data to make informed decisions. In the business world, we have "business intelligence specialist" because nobody takes for granted how difficult it is to get business insights. And it is truly baffling how we don't have "software development specialist" to help us interpret efficiency and productivity as context matters and not everybody is qualified to interpret development metrics.

[Johnie]

The way to get engineers to adopt it is to demonstrate how it can be useful for them. Engineering quality of life can be derived from a lot of these metrics.

Take for example, XKCD 303: https://xkcd.com/303/. Engineers spend so much time waiting on compile, build, and deployment time. It is such a waste of time and resources. These are things that engineers tend to absorb resulting in engineers getting blamed for low velocity.

The other area is on call metrics. Healthy oncall metrics significantly increases engineering QOL.

[sdesol]

> The way to get engineers to adopt it is to demonstrate how it can be useful for them

Agreed. My goal is produce a connected efforts graph that can accurately connect code with effort and time spent (meetings, code reviews, waiting for builds, etc.)

This is why I refer to this as business intelligence for the software development lifecycle. Insights come from data and you can't use traditional BI tools to analyze software development data. If you want to understand effort, you need to be able to slice and dice coding activity which GitHub and traditional BI tools can't do easily or at all.

Take the following for example, if you want to quickly understand the significance of three commits, you can do something like this:

https://public-001.gitsense.com/insights/github/repos?q=comm...

which will stitch together the commits in real-time for analysis. And this is what I ultimately mean by being able to slice and dice software development activity. And how I see thing is, BI for software development activity is both useful for developers and leaders.

[rutthenut]

> Engineers spend so much time waiting on compile, build, and deployment time

Slowness in this processes can certainly frustrate and extend overall timeframes, but surely engineers must be capable of multi-tasking to some degree, and able to do something useful with those minutes between commit and deploy? ;)

[nevinera]

That capability varies a lot. Long build times create a situation where the ability to swap tasks efficiently is the main criterion for being effective.

I'm considered "extremely high output" in my current position, and I don't really deserve it - I ought to be called "unusually good at coping with our problems" instead.