“We wouldn’t even know how to measure what healthy looks like. When we have a problem, we just know it’s resources.”
A Developer, Collaborating a slow application issue.
I immediately perked up at the man’s comment. It’s one any seasoned IT pro with server and storage background can identify with. And it annoys today no different than when I heard it years ago.
The relationship between development and infrastructure teams have historically been… professionally difficult. Nevertheless, in the age of DevOps, agile, and automation, this problem of developers vs. infrastructure still exists at some levels. And, in my experience, the root cause is typically the same: a lack of understanding how and what to measure.
Let’s take a common sample: An in house developed business application begins to get slow after load. The application works well under artifical testing workload. Passes quality and security testing. It’s released into production, but as the business grew, the application’s workload exponentionally grew despite no changes to the application.
Through the lens of the five stages of grief:
| Level | The Business Says… | Developers Say… | IT Says… |
|---|---|---|---|
| “1” Denial | The business is growing. Keep the application healthy as we grow. | Nothing wrong with the application. Application just needs more resources. | Somthing is wrong. Resources are finite and can’t infinitely scale. As demand goes up, soft argue requests. |
| “2” Anger | Clients impacted randomly, jeopardizes revenue. “This is unacceptable!” Sales and Executive team anger palatable. | “Just give it more resources!” demands development. IT is at fault because they are slow to react, although recognize applications limits and technical debt growth. Will fix one day… | “Iceberg ahead!” Technical debt grows. Business and development are at fault because they don’t understand workload vs. timing of resource vs. limits vs. financial realities. |
| “3” Bargaining | If only the technical teams worked better together. Blame development and IT leadership for failures. Deny technical debt reality, priortize features over scale. | If only the business recognized earlier the technical debt so developers could improve the application to scale. If only IT would be more supportative so development didn’t have to perform support. | If only leaders would recongize the effort IT is trying to keep the application working, which is turning into a support nightmare. Morale low. People leaving. |
| “4” Depression | Impacts on top of slow sales cycle lead to short tempers and broad opinions based on perception / feelings. Not data. | Developers take a beating as primary causes for failure. Morale low. Talented developers begin to leave. Technical debt begins to be worked, slowly. | Culture isn’t sustainable as we grow. People and process ignored as blame and fingerpointing ensure. Nothing based on data. |
| “5” Acceptance | Option 1. Things Stay The Same. Culture, processes, and people remain unrecongizable or admitted problem areas. Status quo. | Option 2. Things must change. Recongition to change, but how to change? Confusion and lack of alignment ensues. | Option 3. Things do change. Leaders commit to mission and vision, collectively. Measuring and alignment replace confused culture. |
The point here is managing things, including developed applications, based on perception and/or reaction is not managing. It’s guessing. And when it works out where the thing is not a problem — the guess paid off — everyone enjoys feeling good. The “avoided bullet”.
But what about when it doesn’t work out? Take the quote at the top: “We wouldn’t even know how to measure what healthy looks like.” That is a serious flag on the field. If you don’t measure health, you can’t manage the patients’ health care. As we all know, unmanaged health care means shorter lifespans. Despite ownership.
Calls to action are:
#3. Every single piece of technology deployed must be (1) measurable, (2) being measured, and (3) react “able”. What does healthy and unhealthy look like.
#2. Every development project must have requirements outlining measurements of health, particularly what success and failure looks like. Evaluate peridoically to adjust to business climate and workload change.
#1. Leaders must commit to the culture of quantification by measuring business performance. Start with key performance indicators (KPIs) tied to business mission, goals, and initiaitves. Start with departments that don’t (won’t) measure will be instantly assumed to be failing.
\\ JMM