As you probably guessed the title of this post is ironic.
I want to spend few words to show the logic behind a certain kind of behavior and its consequences.
The behavior I’m referring to as: Challenge Driven Development is one that some are tempted to use. This behavior is easily observable in persons who are accountable for tasks or projects while depending on others for the execution.
This is the case, sometimes, of Project Managers or Line Managers working with software development teams.
The originating dynamics is the manager perceiving progress being to slow. For some reason he believes that putting some pressure upon the development team will eventually gain more speed and productivity and he acts accordingly.
I tried to sketch a causal loop diagram to illustrate this belief and I stumbled upon a reinforcing loop, as shown below.
Reductio ad absurdum
Following the kind of reasoning called: reductio ad absurdum let’s make the hypothesis that pressure upon the team causes things to go faster. Let’s now observe the above causal loop diagram.
The logical consequence appears to be that, following the self-reinforcing loop, we will be able to obtain indefinitely increasing productivity simply by applying constant challenge and pressure to the team!!!!
Unfortunately in the real world this does not appear to be the case or, at least, not in this simplistic way.
What’s behind the quick task execution
Inspired by the much more analytical and sound reasoning about mental models illustrated by Craig Larman on Less website I tried to expand the links in the previous causal loop.
In the diagram I added a “little circle” close to some arrows. It represents an inverse relationship (the more of A –> the less of B).
With this second causal loop diagram I want to represent the fact that the most common way of speeding up a task is to lower the quality of the work.
This causes an apparent increase in velocity.
I say apparent because we neglect to consider that what actually explains this increase in velocity is the decreased number of things done (i.e.: quality). Eventually, on the medium to long term, this low quality work will impact all subsequent tasks.
This is represented by the external cycle in the diagram. Unfortunately both the loops reinforce the need to put more pressure on the team.
But we do not end up having a constant increase in performance since the negative impact on the time needed to complete a task (see external loop) is ever growing.
This causes a balancing effect on the medium term and eventually a pejorative effect in the long run.
What Quality is in software development
To cut a long story short when we decrease quality we leave behind us a messy piece of code if we are lucky, many bugs if we are not.
As I was mentioning in a previous post, it is unlikely that the decision to rewrite a messy piece of code is an unquestioned choice. The opposite is true, actually.
Usually the persons involved in such decisions are willing to evaluate pros and cons to take an informed decision.
But when Challenge Driven Development is in the air this calm reasoning is difficult to achieve.
Desperately Seeking Courage
When you rewrite an unknown piece of code is really likely that you will break things in unpredictable ways. Among the strategies you can adopt to reduce the probability and the impact are: iterative development, being competent in the field of software development, using xp practices like TDD and pair programming and others.
Developers using such approach usually can succeed in rewriting a piece of code and if they fail they will be quick to recover.
But psychological safety is really important when such decisions need to be taken.
We all agree that when a task is risky and tough the persons working on it need the level of mastery adequate to the challenge, need the analytical skills to assess the risks and to figure out the impacts.
But most of all they need to be able to act with a little bit of courage.
If as a manager you don’t praise courage you will get quite often a reaction driven by amigdala: the fly option in the Fight of Flight response. No-one will dare to take a risky decision. No-one will take the responsibility to work for medium to long term, difficult to assess, results.
Is Trust a Value or a conscious act?
There are several common behaviors whose outcome is to challenge acts of courage instead of encourage them:
- ask the developer a guarantee in the form of a cost-benefit analysis,
- ask her/him to estimate how sure she is about the outcome
- tell her that you will hold her responsible
- remind to the team the stake at hand and the risk they want to take and after these words leave the decision to them
- ….
All of these translate, in the minds of the team members in one of the following:
- Fear to fail and be blamed in case anything will go wrong…and it will;
- Rationalization of the facts to justify the decision not to act
The opposite is true if you abandon your challenge driven environment and build a safer one:
If you feel safe, trusted and supported. If you are competent. If the environment (in terms of tools and processes) is mature enough to make it easy to fail and to recover from your failures, then you will quickly fix what you broke and with almost no harm.
If any of the above is missing, the process will not work and you will fail catastrophically.
In my opinion all the things I cited above are under the responsibility of an organization’s management:
Safety, Trust, Support to people, Competence Growing, Functional and Efficient Environment are prerequisites for the good working of every organization.
When software development is part of the business (always?) these prerequisites become even more critical.
