Sustainable Feedback

We are not giving developers "sustainable feedback."

One of the essential concepts in Agile Development the idea of sustainable pace. At the time Agile was first proposed, this was an indispensable alternative for death marches.

Death marches occur when we try to implement the very unreasonable "fixed scope, fixed delivery" methodology. This situation is a typical degeneration of the waterfall system, where we fix the scope at the beginning, and we estimate delivery dates. Since we assess most projects at a moment when the best available information is not enough to make accurate guesses, delivery dates often are pushed later and later as development progresses and a more precise picture of scope and effort required do emerge.

This is all "fun and games", until the delivery date gets pushed to an unacceptable point in time by business - no one wants to lose customers - and teams are forced to double shifts or work overtime in order to produce the effort necessary to complete the scope, and the release happens - late, broken and with a burned out team.

Unfortunately, death marches also occur within Agile teams that do not have a sustainable pace. For example, if teams treat their sprints as mini-waterfalls and end up trying to deliver everything in the last couple days of the sprint, having half done everything but completed nothing, and attempt crunching over the nights, weekend or even try to argue for postponing the end of sprint by a day or two.

The alternative to these horrible death marches is the concept known as "sustainable pace," where we value having the team move at a rate that is as fast as possible while being sustainable indefinitely. A sustainable pace is not only the antidote to death marches, but is a much more subtle and more fundamental principle than a simple "do not do death marches, ever." There is much more that stems from wanting to have an indefinitely sustainable pace. For example, teams need to have a low turnover to favor stability. There are many valuable consequences to the "sustainable" pace principle, but an interesting and, I believe, novel idea came to my mind in the past few weeks, and I would like to share it with you. This idea is "sustainable feedback."

Over the years we created many tools and rules to help developers build better code, or more precisely, to write less lousy code. We have automated tests, linters, strongly typed languages and compilers, languages that separate pure functions from I/O, etcetera. The more I think of it, the more I find that the most substantial part of these tools and rules, while they are often "right" and very reasonable, they are also, in fact, a form of negative feedback - they teach you what not to do, or they teach you what to do by telling you what not to do. It's like the chimes that go off in Singaporean taxis when they go over the speed limit. If that's all you have, you won't know the speed limit until you hit it - the feedback you hear is always "don't do this." In other words, we are building a gigantic "brake system" to prevent developers from adopting risky or otherwise undesirable practices.

Some examples are automated tests, which are way more reliable as indicators of failure than they are of correctness; linters can easily prevent me from committing a patch with lines 300 characters long because it's not readable but are clueless in determining if my otherwise compliant piece of code is readable at all. I could add more examples, but hopefully, the concept is clear - we are way more interested in preventing developers from making obvious mistakes than we are to encourage them to adopt the right behaviors.

A small digression: one might object that if we prevented a developer from committing a line of code 300 characters and told them to line break at line 72, we would be giving them positive guidance at all effects. We are indeed telling them how to fix their mistakes! The problem is that we are only providing advice to people once they commit errors. The other 99 developers in your company who have not yet made this particular mistake have learned nothing yet about keeping lines of code short.

In other words, we need an incentive system for developers which includes both negative and positive reinforcement.

Sustainable feedback is the only logical way to ensure that your team has not only some baseline, minimum standards - compliance to avoid negative feedback - but that it is also well aware of all the great things they are expected to achieve during their tenure. Companies deal with this in different ways: some employ only senior people whom they don't need to train; some advise team leads to dispense encouragement; others document all the great things in some wiki and expect everyone to read it; and so on.

The sad reality is that when we measure the amount of positive reinforcement that all developers receive against the avalanche of automatically generated negative feedback, the negative side dominates pretty much everywhere.

As a consequence of this we are effectively setting up incentives and encouraging developers towards caution and groupthink, and in general to avoid any behavior that might get them blamed. In some cases, developers effectively start treating "lack of negative feedback" as an incentive! A typical example is a programmer that works cyclically until all tests pass and then deploys - they are finished - forgetting to refactor, test manually, or otherwise pay down the tech debt they might have found. In my experience, this is very common, and I posit it is because they do not receive encouragement to do the rest.

In conclusion, hopefully, I've convinced you of the necessity of having "sustainable feedback" surrounding the developer community for it to thrive. The current practices are not sustainable as a whole. In the next post I am going to detail what I want to do about it, so keep tuned!

discuss on Hacker News