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.

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) 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 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 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.