In an open letter to engineering leaders everywhere, Fin CTO Darragh Curran explains that AI isn't a magic wand but rather an amplifier—of the good and the bad—of your engineering practices. And engineering rigor is more important than ever.
The world is especially hard right now. The future of the software engineering profession looks more uncertain than ever. Execs are under heavy pressure to turn AI into magic results, and teams are fighting product competition and AI-induced burnout on one side, melting mental models and hellish oncall on the other side.
Observability was supposed to be a solved problem by now. But we heard over and over and over from staff+ engineers, managers, and executives that it continues to be one of the biggest pain points:
“We spent six months evaluating and choosing a tool, and got overruled behind our back.”
“It takes 15 minutes to recover from an outage if the principal engineer is on call, and 45 minutes if he isn’t. Nothing we seem to buy or do or try seems to change this.”
“I’m pretty sure the competitive research is all faked.”
We weren’t planning to write a whole book-within-a-book to speak to technical decision-makers from the top down, but that’s what happened. The first five parts of Observability Engineering are written for software engineers and the people who need to understand their code. The sixth is written for technical decision-makers.
We start with an open letter to CTOs, explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn. Then we cover software delivery and observability from a systems perspective—no technical terminology, just systems thinking. We then talk about how to quantify the case for observability as a cost center or an investment, how to drive change in your organization, how to make good buy-vs-build decisions, how to partner with vendors, and how to approach instrumentation and security from a top-down perspective.
Observabilité des processus
Trisha Gee
Observability as the key to performance tuning Software Delivery
The golden rule of application performance tuning: measure, don’t guess. Yet when it comes to developer productivity, too many teams still guess. Builds are slow, tests are flaky, CI feels overloaded—and the default response is to throw hardware at the problem or hope it goes away.
In this talk, we’ll apply the performance engineering mindset to developer experience, showing how observability data from Develocity can profile builds and tests just like applications. By measuring and optimizing build and test performance, teams directly improve the DORA metrics that matter: shorter lead time for changes, lower change failure rates, faster recovery, and higher deployment frequency.
Developer productivity is a performance problem. If you want faster delivery and happier developers, the path is the same as for applications in production: measure first, then optimize.