No one can be told what The Metrics is. You’ll have to see it for yourself.

Wake Up Neo…

You think you’re paid to write code, design a feature or manage a team? Wrong! You’re paid to deliver business value.

The work you do is only valuable to your company when it creates success.

But what does that mean?

You take the blue pill — you believe whatever you want to believe. 
You take the red pill — and I show you how deep the rabbit hole goes. Remember: all I’m offering is the truth. Nothing more.

It’s easy to get caught up in the code we produce and the product we release without really understanding the impact that our work has on our company and on us. We may be lucky enough to be creating a successful product that pleases our customers and generates profits for our employer. But do we know why?

Not only is it important to understand how much business value our team delivers, we should also understand what it is that creates that business value — and what we can do to improve it. We should know what to focus on, in order to become more efficient at delivering that value.

We can all make informed assumptions about what our systems are doing, but we don’t know for sure. Our perceptions are almost certainly not reality. Not until we start measuring and validating our assumptions.

Image : http://gph.is/XNpkui
Neo: Why do my eyes hurt?
Morpheus: You’ve never used them before.

By enabling our systems to publish information detailing exactly what they are doing we don’t need to rely on our perceptions. We can see exactly how the system behaves — not just for us, but for every user.

Application Metrics allow us to count, time and measure the activity happening across all of our systems in real time. They give us a historical view to help us recognise changes over time. And they allow us to notice sudden changes and react to issues quickly.

Agent Smith: Never send a human to do a machine’s job.

By building measurements into our code, we can configure our systems to gather all of the data that matters to us automatically. We can use that data to inform us of exactly what is happening. And we can setup systems to highlight the important numbers— so that we don’t have to interpret what we see.

Not only can we then measure and monitor the value our systems deliver. We can now understand how to improve them — in order to increase business value.


Trinity: What’s he doing?
Morpheus: He’s beginning to believe.

Instrumenting our code to publish metrics generally isn’t that difficult. There’s a whole host of libraries out there (Prometheus being my favorite). The hard part is knowing what to measure. And in order to understand which metrics feed into business value, you will most probably need to speak to someone who can help to define the business value.

The process of understanding what your business value metrics actually are may be challenging. They will be different for every business, and every system.

Direct measures of value such as number of sales, transaction value or click through rates may be the most obvious to identify and these sorts of metrics should be the primary focus — in particular measured against feature releases. But there will be plenty of other contributing factors behind those numbers.

For example, page load times may matter. Maybe multiple services contribute to the load time and a sluggish service will slow down the page load. Maybe an endpoint is returning zero results too often and could be due to a bug. Maybe measuring error rates will help you to identify faulty code quickly — and fix it faster.

Additionally, if you can measure the usage of features in your system, you can decide which ones are important to focus on and which should be deprioritised or even deprecated. Remember, building features that nobody needs is waste (negative business value).

Neo: What are you trying to tell me? That I can dodge bullets?
Morpheus: No, Neo. I’m trying to tell you that when you’re ready, you won’t have to.

This all feeds into our ability to make better decisions, faster. Understanding our systems means we’re no longer guessing at requirements based on our own observations. (Or even the opinions of just a few customers).

By measuring the effects we have on our system each time we make a release, we can validate the work we have done, whether it had a positive (or negative) impact and whether we should continue.

Faster decision times lead to quicker wins, less bugs, more useful functionality and less time spent working on the things that don’t really matter.

Metrics allow us to focus on business value. And by using them to drive our decisions, we can be far more confident that our efforts are likely to deliver real value to the business.

Morpheus: I’m trying to free your mind, Neo. But I can only show you the door. You’re the one that has to walk through it.

Its far too often that development teams build features that product asked for, release it and leave it at that. After all the effort and hypothesis that has gone into our work, we should all be far more interested in measuring the success and value that our work creates — or whether it made any difference at all!

Identifying exactly what we should measure and encouraging the rest of the business to subscribe to this way of working it what we may find most challenging. But we’re fortunate enough that adding code to measure metrics is not that complex. So, as developers, this is one area where we can lead by example — maybe even influence product decisions and what we work on next.


Metrics will open your eyes to a whole new view on the work you do and the systems you maintain. If you’re not already measuring, then maybe now is the time to start.