Blog post: Feedback Loops
Tags: perl, feedbackloops, development, software
Published: 2018-10-19 09:56:15

---
title: Blog post: Feedback Loops
published: true
description: an example depiction of the feedback loops for a SW development process
tags: perl, feedbackloops, development, software
---

I very often hear that feedback loops are the _most valuable thing_ when developing software and therefor also incredibly essential to what we do every day as software professionals (or busy hobbyists).

This got me thinking

> What are **my** feedback loops actually?

And here I was thinking about work.

Instead of decided to do a pilot on the feedback loops for the coding I do in my spare time and I decided to map my feedback loops out in a drawing - this is where you have to bear with me, since I am no artist. I come from a very artistic family, but I am the least artistic. Instead I am _better_ than the other members of my family when it comes to _systematic thinking_.

Since I had never outlined feedback loops before I decided to start with something I know quite well, even though it still fails sometimes, making it interesting to see whether the it the feedback loops are efficient and sufficient or whether it all boils down to `Error 40`, meaning the consumer of the feedback loops, the user - me :-)

Anyway applying systematic thinking and my limited graphical skills I have come up with this _rough_ draft, It is not perfect and it does not convey the version control system part completely, but since this is not significant (_for now_) I hope you can abstract from that.

The diagram depicts the development process for one of my **Perl** distributions, but it should be somewhat applicable to other programming languages and it is process that is interesting to begin with, tools second, I do however have yet to evaluate the process for other toolchains, but for now at least you will get the picture.

As stated, this is **MY** feedback loop and any resemblance to yours or other feedback loops is purely coincidental and any harm resulting from, or loss of code or hours of sleep by using the same feedback loop on at your own risk. Well feedback loops are feedback loops - simply events, the worst thing that can happen is that you ignore them an suffer the consequences.

![my Perl development feedback loop](https://thepracticaldev.s3.amazonaws.com/i/tytekzgazua52i0zeh8q.png)

The process starts in start in the top left corner, where we also end. Since this is a process that keeps repeating itself.

1. I create a branch from my editor and I start to _code_. This is sometimes done in the terminal or I pick up an existing branch.

2. My compilation step is my first feedback, I might get squiggly lines in my editor or my compiler or interpreter emits error messages or warnings, depending on how I execute this step again this varies, but the feedback loop is there - the more regularly and reliably this part of the toolchain is used is essential.

3. Next feedback look is my unit-tests, this might also be triggered from the editor or similar or if you have monitoring of your project running so you get your feedback continuously. The latter has proven to me to be the best approach, since forgetting to run unit-tests is something I often do - you all know: _it compiles - ship it!_, which is something we want to avoid. For **Perl** I use `provewatcher` (see: [MetaCPAN](https://metacpan.org/pod/distribution/App-Prove-Watch/bin/provewatcher)) and I know other languages and frameworks have similar tools and it is something I have started to look for when I begin development outside my **Perl** toolchain. At the same time I have had huge success with doing this step via **Docker**.

4. When I am done, I stage and commit my branch. You might have hooks here providing you with feedback based on linters etc. executing via pre-commit hooks or similar. I am still experimenting with this so I did not want to depict it here since it is not something I do for all my projects.

5. I then push to **GitHub** and this trigger the continuous integration (CI) which is my next feedback loop. **Travis** might be able to tell me if my code works outside my machine - again, it let's me address: _it works on my machine!?_. **Travis** offers a limited set of different Perl interpreter versions and even operating systems, but here I limit myself to the **Perl** versions I have decided I aim to support and on the operation system side I just stick to a single one, more on this later.

6. If I find the result satisfying and everything passes, I repeat this step, merging towards the master branch and Travis picks this up and provides me with a feedback loop once more. Often I do not wait for the feedback from **Travis**, this has bitten me quite a few times and I would wish I could block myself or muster the patience to wait for the **Travis** job to finish. Limiting the job configuration of operating systems and interpreter versions of course speeds things up.

7. I Then I tag and push - this will result in yet another **Travis** job being run, but you get the picture it is not essential to the overall process.

8. Next up is packaging, this step is interesting in **Perl** context, since depending on your toolbox, this step might provide a serious feedback loop. I use [Dist::Zilla's](http://dzil.org/) `dzil`, which can run smoke-tests, check documentation coverage, code and documentation linting and dependency checks (_to the extent possible_), much of this is part of my unit-tests (see earlier step), but if `dzil` is configured correctly I can make sure that it is done here and the integrity of my package is ensured.

9. I then upload my newly packaged distribution to CPAN (PAUSE) and after a few minutes I get feedback whether the indexing of the package went well. I have observed issues at this step, due to some issues with namespaces and meta-data, but not something destructive, but it does require a new release.

10. Finally if I am lucky the marvelous [CPAN-testers](http://www.cpantesters.org/) might pick up my contribution and do some smoke-testing, meaning that my distribution might be tested on even more operating systems not available to myself or **Travis** and with other **Perl** interpreter versions than the ones I have available in the above steps.

Plenty of feedback loops are established for this process - next step for me would be to map out the development process at work, to see if we have any holes or obvious issues, which can be addressed easily.

Please comment if you have feedback, improvements or questions - and try to outline your own feedback loop, I find it kind of stimulating to take a step back and try to see things a little from above.