Monitoring Driven Development: Are you making money?

Test Driven Development vs. Monitoring Development

You may have heard about the concept of Test Driven Development (TDD); but do you know what Monitoring Driven Development (MDD) is? Where TDD gives feedback on code design, Monitoring Driven Development gives feedback on application business logic. MDD is about first defining and writing a monitor to check your new feature in a business context, and then developing the code for it. As such, it’s quite similar to the concept of test-driven development where you first define and write the test before developing the code, in order to test it in a technical context. Monitoring and testing are closely related, because you monitor in order to test the fulfillment of the requirements. You want to be notified and take (automated) action if any assumption or constraint is violated. This movement of testing and monitoring towards the earliest definition phase of the product development lifecycle is also called “shift left”.

“Where TDD gives feedback on code design, Monitoring Driven Development gives feedback on application business logic.”

However, the scope of Monitoring Driven Development is bigger than TDD. The following picture shows that MDD is driven by monitoring business requirements and TDD is driven by test accurateness. Here MDD is visualized as an expansion of TDD towards the left and the right:

Monitoring in Development and Testing in Production (shifting left and right)

As we discussed monitoring throughout the lifecycle, even in its earliest stages (shift left), I would also like to touch upon testing your monitor requirements in production (“shift right”). Testing in production may sound contradictory just like the earlier described Monitoring in Development. However, with the technology of today it takes a little effort to run automated tests against a production system. By ingesting the events from your production system in a copy (clone), you can spot problems early and test parts in isolation. With the so-called “Monkey Testing” approach to testing, you can even try to break your own code by extreme testing in a (near) production environment. This running of functional tests against the production environment ensures getting trustworthy results when it comes to quality, security and performance.

“By ingesting the events from your production system in a copy (clone), you can spot problems early and test parts in isolation.”

Are we making money?

With Monitoring Driven Development, you want to ask yourself which things are of value to the company, like “Are we making money?” and “Are customers happy?” rather than “Have the servers gone down?” and delivery time (time to market) rather than discovering that ‘request response time has reached its maximum value’. The main cause of not making money, or customers not being happy may be the technical fact that the servers are down. – But what does that mean? What are the implications and consequences from a business perspective? Revenue, Profit, Number of new customers per day and Customer happiness are examples of Key Performance Indicators (KPI’s) that matter to the Business. Ask yourself what Indicators contribute to these KPI’s, and what events you have to monitor to stay informed about these KPI’s. What combination of (complex) events may influence these KPI’s?

Defining your production monitoring before you implement features will help towards a better design. With the support of these early and well-defined KPI’s, next step is continue monitoring throughout the complete life cycle (definition, design, development, test, acceptance and production/operations). Both MDD and TDD continuously give direct Feedback throughout this life-cycle and build quality in from the beginning. However, Monitoring Driven Development goes further than that. It takes business value into account during design. Define KPI’s, then build for providing insight into these KPI’s.

“Monitoring Driven Development goes further than that. It takes business value into account during design.”

The fact that production systems are monitored continuously may be evident, but from my own experience I know this is not always the case. With MDD, you can make teams responsible for specific features from end-to-end. Developers become responsible for having their code monitored in production and will therefore make code more robust. With this you also make the organizational change towards a more agile way of working!