Feedback Loops

So it has been a long while to since I have posted to this blog. I will try to more occasionally post to this blog mainly for my own benefit. If anyone else in the world finds this interesting that would be great as well. Other than that it's just another tech blog. 

Recently I have had the opportunity to reflect on the effect the feedback loop between writing a line of code and seeing the result has on my development. The primary language used at my work is ColdFusion. This language allows a developer to experience the dichotomy of fast feedback and slow feedback. When making a change to most of the code there is an instantaneous feedback, as fast as you can refresh the page or run the test the is as fast as you can see the result. Whereas we have custom tags (basically a poor man’s web component) that requires a restart of the server to see the result. This restart can take 4-5 minutes at times. So what effect does this have on a developer.  Well as you can imagine, a tighter feedback loop leads to more frequent testing. I find myself making one line changes, testing, editing the previous line or adding a new line, testing repeating this cycle until I’m done. This cycle can be < 10 seconds at times.  I find myself writing “riskier” code, using printlining as my debugger, and generally a lighter feeling about my development. Contrast this to the long feedback loop where the risk is larger if a mistake has been made.  Being a dynamic, loosely-typed language there is nothing worse than going through the long restart process just to see there was a syntax error.  Code is more thought out, mental debugging is used more extensively, and there is a much “heavier” feeling about the development. The fun thing is, there have been numerous times where from start to end of fixing a bug the fast feedback loop has taken just as long as the slow feedback loop. This is because of the more intense focus and level that the slow feedback loop is held to vs the fast feedback code. Therefore, if I would have treated the fast feedback code with the same care as the slow feedback code, I could have finished much earlier with that issue. 

So where does this put us? What is the takeaway from this? I’ll be honest, I’m not sure what to take from this other than a continued desire to reflect on how I develop under certain conditions. Fast feedback vs slow feedback. Business application vs pet project. Statically-typed language vs dynamically-typed language. I believe there is much to learn in understanding how we change our development cycle under all of these conditions. The more we understand of these difference the more we can leverage them in deciding what tools to use and applying the lessons learned when using one form when using another.