One example of a keystone measurement is the temperature of the body. When you feel ill, one of the first things you do is take your temperature because it is indicative of health. When your temperature is high, it flags that something is wrong and needs to be further inspected and fixed. Stress and more bugs

After thirty minutes of being drilled by his boss, Dan, who served as the CTO, wanted to throw his computer across the room. His team had not been able to push all of the new features that he promised they would push before this meeting, and the ones they did push had bugs! Dan sat there seething. He couldn't help but wonder where he went wrong. His team had worked hard, long hours. They pushed many lines of code and closed heaps of tickets. How had the result turned out so grossly short of their ambitions and promises? As he reflected further, he remembered his team ignoring the overload of monitoring alerts which caused them to miss the crucial ones. Their builds were taking what felt like forever so they couldn’t waste time updating minor bugs. They just kept moving forward, piling complication on top of complication in hopes of reaching the deadline. So where did Dan go wrong? What could he have paid attention to that would have saved him the frustration and embarrassment of that morning's meeting?
Ideally, he would be able to look at one keystone measurement that would have been indicative of the overall health of their software development.

So, for a custom development company, what is the keystone measurement for health?

We measure build time for three primary reasons:

We measure build time for three primary reasons:

1. Speed: One of our core values allowing us to operate at maximum efficiency.
2. Performance: If the build time is taking more than a handful of minutes it may reveal that we are using an old library and, instead of building on top of it, we need to update it so that we can drive build time down and performance up.
3. Developer Delight: If a build is taking 30 minutes and a developer has to push it three times in a day, they have now wasted an hour and a half of their time for a process that could have taken less than 10 minutes.

To achieve this at Premio.AI, we have a full continuous integration suite where software is constantly being compiled in a containerized fashion with a variety of tests that are run against it. After the tests pass, it is deployed in a way that allows for zero downtime in the system. This even allows for things like feature flags so that you can deploy to only 10% of the traffic before deciding to deploy to the full load.