top of page

How Have Developers Lives Changed In the Past Three Years?

Software has become more critical, failure is not an option.

I had the opportunity to catch up with Andi Grabner, DevOps Activist at Dynatrace during day two of Dynatrace Perform. I've know Andi for seven years and he's one of the people that has helped me understand DevOps since I began writing for DZone.

We covered several topics that I'll share in a series of posts.

How developers lives changed over the last three years and did it change their mindset in any way?

I think it has changed. And the reason why it has changed is because software has become so critical. If something fails, who is on call, who needs to fix it in the end? It's the engineers that developed it.

It's in the developer's self interest to think about how to build observability into software. Not only for their own knowledge but also in the event something breaks. As a developer, I want to get all the data I need to fix my problem as fast as possible, make my life easier.

That's what we're doing with Dynatrace. In the ideal state, the developer doesn't need to look at the data anymore. But the developer also works with the SRE team to say, if my software doesn't work within these parameters, I won't execute the workflow with the workflow engine. That is then bringing the system back to the desired state codifying what the developer would do if he will be put on call.

The developer knows how the system should behave. And if it doesn't behave like this, the developer typically knows what it will do, restart the service or redirect traffic to something else. They can codify remediation actions as well. The developer doesn't even have to look at this data anywhere and be woken. By providing a codified desired state, developers should not have to be awakened when the system does not perform as expected.

Observability-driven development is a good thing. I would also think about resilience to reverse engineering. In the end, we want to build software systems that are resilient. How do we know if software is resilient or not? We need to observe it. And if the observer, if the observation tells me something is wrong, then I need to take action on it. So the end goal is to build resilient software that performs as expected every time.

bottom of page