DEV Community

Cover image for A brief introduction to Observability Driven-Development
Francisco Javier Sánchez Fuentes
Francisco Javier Sánchez Fuentes

Posted on • Edited on

A brief introduction to Observability Driven-Development

Hi Everyone!

Let's talk about the Observability Driven-Development and how it works.

Why software development needs a "methodologies driven development"?

First of all, I took advantage of this instance to share answers from another user to discuss with a short explanation of why software development "Driven-development" or "Driven-design" are needed.

how come we don't have -Driven Development in other engineering disciplines, only in software? It's because other branches of engineering are faced with much lower levels of uncertainty. When engineering physical objects/systems. it is much cleared what are we building and what are the actual physical constraints (for example, when building a bridge). discuss source here

Ok, you just keep in mind that "the software development process has uncertainty" because we have the human factor in a transversal way throughout the process.

Observability Driven-Development

Now, Observability Driven-Development applies when you monitor your process before, during, and after the development process. The goal is to detect user experience issues or bugs that have not yet been reported. So at best, you can run into problems through observability.

What the mean "Observability"?

The concept of "Observability" doesn't have its origin in computer science and is applied to software engineering, it originated in systems theory issues where it was about "understanding a system through observation". So, this methodology aims to understand and improve a system by observing at startup or when it is mainly operational (production). The reason for observing a system in those processes is because when a system is running it is exposed to other unexpected actions by users.

What about it with other Driven development methodologies?

The authors say that the methodology doesn't conflict with other methodologies such as TDD or BDD. Then, it is a complementary methodology in which DevOps, SRE, QA, Developers, and Product Owner participate where a monitoring system is used to understand where they can debug to find a problem or where they can improve a system.

Conclusions

ODD doesn't say where the problems are, but it's useful to find them by observation.

Thanks for reading :)

I hope helpful this brief introduction.

More info about it in infoq.com

Top comments (0)