crosdn.blogg.se - Pay it down software

Pay it down software software#
Pay it down software code#

Pay it down software code#

Even in our ~1-year-old code base with three microservices, it took an extremely senior engineer a week to hunt down the dependencies across multiple languages. If you’re using something like Datadog APM, it can look like all you need to do is include a library, BUT this may often involve updating other dependencies.

Setting up monitoring and observability requires knowledge of the underlying system.

Monitoring a system requires a nontrivial amount of knowledge about both the system under monitoring and how that system should be monitored using the tools. Today, there are a few reasons it’s easier than ever for teams to quickly and build towards monitoring bankruptcy. Why it’s easier than ever to build towards monitoring bankruptcy Often, the reasons teams decide to take on monitoring debt-not enough expertise not enough time-cause them to fall deeper and deeper into debt. What’s worse, paying back monitoring debt is often harder than paying off technical debt, since it requires both intimate knowledge of the code (what kind of behavior is normal what are the highest-priority events to monitor for), as well as facility with the monitoring tools (how to find and fix the issues of interests given what the tools support?). This means that customers could be waiting for up to hours or days for their issues to get resolved.

The team has chosen to give up at least partial ability to quickly localize issues when they arise, meaning they are less likely to be able to fix issues quickly.

This may work for some tools, but may wear on the patience of paying customers.

The team needs to accept limited ability to catch issues ahead of customers, meaning the customer is the monitoring plan.

When a team chooses to ship code without thorough monitoring, here are the the immediate costs: The costs of monitoring debt are even more insidious. And this is assuming the same developer is around to pay back the debt! It costs more to clean up later and requires intimate knowledge of a system that a developer may have context-switched out of. From a technical perspective, monitoring debt behaves similarly to tech debt.

In some ways, monitoring debt is analogous to tech debt: teams can choose to underinvest in monitoring at the time of shipping code at the cost of having to go back and invest in monitoring later.

Tech debt, like financial debt, can be taken judiciously and paid off responsibly.

People typically talk about tech debt in terms of how the cost of refactoring, redesigning, or rewriting tomorrow allows a team to ship faster today.

Pay it down software software#

Most software engineers are familiar with the concept of technical debt, a metaphor for understanding how technical tradeoffs have long-term consequences. In this article, I’ll talk about what monitoring debt is, why it’s easier than ever for teams to build towards monitoring bankruptcy, and what there is to do about it. What’s happening is that teams are falling into monitoring debt more quickly than they are able to pay it back. So why is there such a gap between monitoring ideals and monitoring reality? We’re also seeing more collective understanding about monitoring and observability best practice across the industry. There are more monitoring and observability tools available than ever before. Today, it’s easier than ever for a team to monitor software in production. To those who still struggle with the monitoring basics: you are in good company. I’ve seen many startups go surprisingly far with almost no monitoring at all. Most teams I’ve encountered have told me they do not have the monitoring coverage they would like across the surface area of their app. Teams get alerted about potential issues before they hit customers-and are able to pull up crime-show-worthy dashboards to find and fix their issues.įrom everything I’ve seen these last few years, few software organizations have achieved this level of monitoring. If we are to believe the stories we hear, software teams across the industry have modern monitoring and observability practices.