At the “London Tester Gathering Workshops 2015” (also see #LTGWorkshops on Twitter) I offer a workshop “Fast Feedback Loops & Fun with Ruby”. For this, I wanted to give attendees a handout, to make applying the stuff covered easier and it was planned to be a list of brief recipes.
Suffice to say that the handout grew (and it’s entirely possible that this is ‘feature creep’ in action). In fact, it grew to the point that I decided to turn it into an ebook. The book is not done yet, there’s some copy editing to do.
My workshop at the London Tester Gathering Workshops 2015 is announced now! They’re offering an early bird rate until the 18th February, by the way. Find the abstract on the conference page or just read ahead. 🙂
Fast Feedback Loops & Fun with Ruby
Ruby is “a Programmer’s best friend”. Let’s use Ruby to get feedback – including getting feedback automatically – when working on projects. Whether it’s about transforming source code into test results (a.k.a. running automated tests) or generating image files from raw data, Ruby can be used to automate these tasks. Furthermore, it can also be used to automate actually running these tasks, e.g. upon saving a file to disk. Does that sound like a good idea? This session is for you.
I regularly bump into tasks that are…
tedious, if done manually
not done often enough, unless automated
still not done often enough, unless running them is automated, too.
In the workshop we’ll combine some Ruby tools to remedy this situation. In particular the workshop will cover:
Writing a simple Ruby program that does something useful, e.g. turn a markdown file into HTML
Wrapping that in a Rake task
Automate running the task
Knowing how to do this is useful, not only for projects using Ruby as their primary language, but can be handy in all projects.
What is expected:
Some Ruby knowledge; you don’t have to be an expert or anything like that.
A notebook (or tablet) with an internet connection & Ruby installed.
Cool if you’re using RVM, rbenv, chruby or similar
Mac OS X, BSD; Linux & friends are fine, Windows may be a bit problematic.
In his keynote ‘Fast Feedback Teams’ OlaEllnestam (at the Agile Testing Days 2012) talked about the importance of fast feedback and how to shorten the cycle durations. To me, there seems to be a trend in focussing on getting feedback in shorter and shorter cycles.
While I completely agree that in many cases it takes too long to notice the effect of a change made earlier, I am also a little bit worried that we (as software developing teams and companies) might forget about slow feedback cycles. Let me explain.
Let’s look at aspects of feedback loops. There is an actor to change the system operation as well as a sensor that reads some information. In order to actually be a feedback loop, the sensor is driving the actor.
Note that most systems allow data to be read at any time and (essentially) any frequency. However systems usually also do not immediately respond to changed input. Here’s an example: You could read a thermometer in your room as often as you like. And you can also turn the control of the heater up or down pretty often and yet the room temperature will not change immediately.
Usually there is no point in acting a whole lot faster than the system can react. If it takes ½ an hour for the room temperature to adapt to a newly set value, reading the thermometer and changing the control every minute doesn’t make much sense.
Some waste and some risk
Now, with the focus on short time scales and a high frequency of the measurements (no matter wether they are qualitative or quantitative), I can imagine two undesirable outcomes:
In a situation where the system reacts slowly to changing parameters, measuring often is waste. This is because the system couldn’t possibly yield another outcome (yet).
If we only measure with a rather coarse-grained way (e.g. only the values red, yellow, green), we might miss a slow trend. (I guess this is the reason we often suddenly must buy winter tires, even though we clearly noticed that the temperatures decreased over the past weeks and we’re wearing our long sleeved shirts and anoraks too.)
That said, if the system reacts fast on a change and we can get the feedback quickly, it’s very likely a good idea to actually get that feedback. A good example for this case: Having fast unit tests in programming. 🙂