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