I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

XP Values: Feedback

07.22.2013
| 2112 views |
  • submit to reddit

Control theory classes open up with this simple problem:

  • there is a room at the current temperature of 10°.
  • There is a source of heat that is connected to the room that can raise this temperature to a more acceptable level (but also overshoots).
  • A model can in principle be built to describe how the room loses heat towards outside: for example, the higher the temperature difference the higher the heat transferred.
  • The problem: regulate heat so that the temperature reaches 20° and stays constant.

This control model is called feed-forward, and consist of precisely anticipate the inputs of a system (when to turn on a heater) to target a constant output (the temperature). However, in reality solving that problem with this model is very complicated or even impossible.

First of all, this is a really difficult model to build: consider all heat sources and sinks, their differences in temperature. Some differential equations to solve are mathematically difficult and they do not have a closed form solution, so you must resort to numerical approximations or simulations.

Moreover, this model is really sensitive to initial conditions: minimum differences in the initial measurement result in divergent final conditions after enough time. If you measure 10.01° and your predefined input for the heater assumes 10.00°, after some time the output will distance itself from the desired one in an arbitrary way.

Not only initial conditions disturb the model, but also any other parameter not included in it: if the sun perturbs the heat flow between the room and the environment, the control system is not able to respond by turning off the heater.

In fact, in the real world models based on feedback are the form of control implemented in these cases:

  • there is a room at a temperature below 20° (doesn't really matter precisely how much).
  • There is a source of heat that can raise the temperature.
  • The room loses heat towards outside: it doesn't matter how fast as long as it stays below a certain maximum.
  • The problem: regulate heat so that the temperature reaches 20° and stays constant.

Feedback from a temperature sensor activates and deactivates the power source, as a function of the difference between the desired temperature and the current one (and of its sign). Without considering hysteresis and stability, the rule can be as simpler as 1) if the temperature is lower, activate and 2) if the temperature is higher, deactivate it.

Not only thermostats

Feedback is the acknowledgement of the outputs of a system to modify its inputs, for any reason. Here are some of the forms feedback takes during the daily work of a software developer:

  • TDD: test tells you in milliseconds (or seconds if high-level) if some code works. Even before being run, they tell you if the API produced until now it's easy to use (short and clear tests), or a pain to work with; it tells you if objects allow decoupling between them (unit tests can be written) or if there is global state going around (the need to reset global instances).
  • Static analysis metrics: is the number of lines of duplicated code going up or down?
  • Time tracking: tells you how many Pomodoros have passed since you started working, the total time cost of a feature, if relative estimates were correct (5 points took really about half of 10 story points).
  • Retrospective meetings: collect good, bad and sad (or other categories) of feedback from the team itself that can be the reentered in the system to improve the way you work.

Acting on feedback

Being feedback positive (TDD is working well) or negative (this feature is taking too long), acting on it is a challenge when there is the pressure of deadlines and conflicting priorities. However, who does not take the time to learn to go faster will find his speed decreasing in the future: (Jurgen Appelo and the Red Queen say ) it takes all the running you can just to stay in the same place.

I suggest to attach next to your Information Radiators the actions of the last retrospective, to link them to the current user stories and ensure their execution stays in the iteration (or in a reasonable time period for Kanban boards). Some, such as setup of new tools in CI servers, need to be taken care of while departing from the user stories; some others can be bundled with them by augmenting their cost, as it is the case for many refactorings. For example, a user story on a new OAuth redirect can be the excuse to adjust the other rounds of similar redirects spread in the application; a new piece of the UI can be the excuse to improve the backend to produce an output easier to use in the interface environment.

Perils of feebdack

Feedback is not a panacea, and control theory experts know this.
In the real world, hysteresis is necessary to regulate how much quickly we respond to feedback. Thermostats don't start the heater at 19.99° and stop at 20.00°, as this will ruin your system due to the continuous oscillation, with strain and stress.

There is instead an hysteresis zone: start if below 19.5°C, stop at 20.5°C. While inside, do not change the current control decision.

We have to accept natural variations along the desired optimum. Models which are too rigid for this variation will break (like a too rigid steel bar may break instead of bending and returning in place.) You will never have exactly 13 story points from an iteration without some form of slack.

And so as for temperature and thermostats, one of the perils of feedback is when it manifests itself too fast, leading the system to instability: for example, it's nice to allow the reprioritization of user stories as some commercial feedback tell us some of them become more important.

However, this cannot be done inside the current sprint or on the started stories, but just in the backlog. An iteration's length is the maximum rate at which feedback for selected stories can be communicated to a Scrum team, to avoid driving the developers mad by making them totally context switch every day.

In the same way, helding a retrospective every day isn't going to provide a big return, but rather expose and problems and worries that would go away by themselves in many cases. Only focused forms of feedback like Delta Plus are acceptable, timeboxed to a few minutes to not introduce overhead.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)