The Agile Manifesto opens with “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Everybody would agree this is something hard to accomplish without feedback loops: getting positive or negative input back to the development process, as soon as possible.
DevOps culture offers us some guidance: working in small batches will shorten our feedback loops. However, this is easier said than done.
Step by step then. Let’s define each stage of the development process from the point of view of feedback loops:
Testing my implementation is a feedback loop with myself. Is my code doing what I meant it to do? No need to go into details here, I am sure all of us write tests, right? 😉
Continuous integration is a feedback loop with my team. Is my code, merged with my colleagues' code, working as we expect it to? We can speed up this loop doing trunk-based development or at least creating code branches that will be merged within the same day.
Continuous delivery is a feedback loop with other teams and systems. Is my code working as expected in production-like environments? DevOps culture and its continuous delivery practices comes to the rescue again!
Continuous deployment is a feedback loop with my customers.
Is my code delivering the features my customers want? This question can be easily answered if you are working on a matured software product in which adding a new feature can be done fast and painlessly. It is much more complicated, though, if you are working with legacy code (for obvious reasons) or if you are starting a brand new product and, caught up in the excitement of adding more and more features, you fail to identify the ones that would close this feedback loop sooner.
In software development there are other aspects to consider, of course. But it might be worth taking a moment every now and then and ask yourself how you can shorten the feedback loop you are in.
Maybe this way you will not leave writing tests for later; you will not have a code branch opened for a week; you will not do a full rewrite to improve some software; or you will realize that reducing the scope of this new service you are working on will speed up delivery a lot. Been there 😉
Top comments (1)
I really like the feedback loop what you have explained. Strongly agree on everything.