Changing Developer Behaviour, Part II

In Part I of this series, we took a realistic look at what usually happens when we initiate change. We also took a look at the initial steps of effective change: defining a metric and getting people to accept it as a goal. In this second and final part, we’ll introduce two additional steps and also highlight the point at which it becomes clear that change has taken effect.

Step 3: Make Progress Visible

When progress toward achieving a goal is highly visible, it can’t be ignored:

It keeps the goal fresh in everyone’s mind and helps to prevent regressive behaviors.

It communicates progress to all stakeholders, especially those who may not understand the details of the work.

It provides an opportunity for many small celebrations for a team on the way to achieving its goal.

There’s a direct relationship between what developers do and changes to the visible “progress meter,” providing a source of pride and “bragging rights” for individuals.

Regression can be easily identified, right down to the work done (the commit) and the “guilty” (the committer).

We can make progress visible by publishing both the raw metric and a burn down chart which computes the estimated date of completion based on the rate of progress.

This makes it easier to answer the obvious question, “When is it going to be done?” It also provides a fact-based response should there be a need to push back on demands, e.g., “you need to get this done by X date.”

The continuous build status page is very well suited to this. With every build, the change metric can be computed and published automatically. The continuous build status page will then show a current chart of progress over time.

Going back to our example, we can use Testability Explorer to compute an overall cost number. Let’s say that our project scores a cost of 500, and we make it our goal to lower the cost to 50 or below. As part of our continuous build we can produce a graph of the testability cost over time. We can project this graph in a highly visible location (on the wall, on the ceiling) so that it is on everyone’s mind all the time. We can also easily identify people who are improving the situation with the code they commit. By calling out their contribution to the team, we get additional buy-in from the team.

Before long, there will be an anxious manager running around asking, “why is the graph is not falling fast enough?” When that happens, the change process is self-running and will complete itself. By keeping the graph current and visible even after the goal is reached, the change will be durable.

Step 4: Make it Required

By and large, developers care only about checking-in code. They are content to continue bad habits if those habits enable them to check in work sooner. When the priority is to get code checked-in, all those fancy graphs will simply show the team getting further away from its stated goal.

If this happens, no amount of meetings and discussion will make a difference, but one thing will: create a unit test that makes sure that any code change can only move the metric in a positive direction. This way any changes to the source code that take the team further from the goal fail the build. Once the build goes into a “red” or broken state, it needs to be fixed. This means that every developer will have to deal with the test to get the build to pass. Fixing the code to pass the build brings the team closer to its goal. A specific code change made to resolve a broken build makes the “what has to change” very clear to every person on the team.

Expect a lot of uproar, and that each developer will require individual attention to help them re-factor their code so that it passes the unit test. The screaming will stop as soon as each person has received individual attention to learn how to code correctly. This won’t move the needle on the chart, but the numbers won’t get any worse.

This suggests that early on, it will need to be someone’s job to re-factor code. Only then will the chart move in the desired direction. Very likely, this is the only way the team will make any progress initially. This is because developers will know how to write new code, but they won’t know how (or won’t be motivated) to re-factor the old code to conform to new standard. Additionally, they will not yet have experienced any benefits from this new way of doing things. This typically takes a few months. While this is taking root, you will need to be patient to make slow but steady progress refactoring the existing code until developers catch up.

The Tipping Point

At some point, developers themselves will start refactoring old code and the rate of progress will accelerate. The interesting thing is that even if you - the agent of change - leave a project at this point, the goal will eventually be reached. The visibility of the charts clearly show where the team is and how much remains to achieve the goal, and this becomes ingrained into the everyday life of both developers and management. People will see the estimated date of completion and start counting the days to it. Each person will also keep the team focused on the goal. Because the estimated time of completion is based on past progress, the projected date of completion will slip if the rate of refactoring slows down. When this happens, people will ask why the date slipped. This brings attention back to the effort and reignites it. This feedback loop will exist even without a full-time change agent.

Every change has its opponents. At some point the most vociferous opponents become the most vocal champions because they experience the benefits of it first-hand. At the same time, all “passengers” in a project team find they’re doing something for so long that they can’t imagine working any other way. The team achieves its goal either by strong desire or because it has developed new “muscle memory.”

Behaviour Changes when Goals are Visible and Reinforced

To successfully make change, it isn’t enough to get consensus to try something new. You need a means by which to quantify a goal, objectively measure progress, and constantly remind people of how well they’re doing toward achieving that goal. If these things aren’t done, developers will find reasons and excuses not to change. This creates a downward spiral: by carrying on with business as usual, skills stagnate and technical debt accumulates. The irony is that precicely when a team most neads to make change, its own behaviors work against it. A high degree of visibility, and immediate, constant feedback, can overcome even the most difficult team situations.

I like this idea a lot. I’ve been trying to figure out how to get people in my group to write more (in some cases any at all) unit tests in our code base. I think tracking code coverage of the tests over time could help with this. Though there’s one thing I would worry about:
“The screaming will stop as soon as each person has received individual attention to learn how to code correctly. ”

Some resistance has been very ego driven. I hear statements like “I’ve been programming for X years just fine. I know what I’m doing.” to justify not testing. Essentially, proposed process changes are taken as a personal accustations against their abilities. My first thought was that some people would claim that they already know how to “code correctly” and be come even more resistant.

I like this idea of making it more *tangible*. Often not the managers but a sub-group of developers are so dead-set in their ways that ingenious ways are made how to make little, no, or almost useless tests (code first, test waaay later, test means nothing)

By measuring, although somewhat contrived, the progress you make or not make puts the focal point on the developers and non-progress will be uncomfortable. It will help in “feeling the pain” of not doing it right.

Which should, I hope increase progress and lead to better design/system etc in the end.