Pressure in Software Development

by Jens Coldewey, Senior Consultant, Agile Project Management Practice

Everything has been said and written about the role of pressure in software development; there's no need to reiterate that all over again. At least, that's what I thought until recently, when an executive called me in for one of those "let's talk frankly" chats. She had hired me to help her deal with the organization's disastrous bug rate, which had started to threaten its market position. After some friendly chatting, she began to reveal her idea: "Well, I know all this stuff about errors in programming and so on. Afterall, these guys (she was referring to the development team) are paid to write features, not bugs. Can't we just reduce their salary if they write bad code?" My first reflex was to consider quitting my engagement immediately due to the obvious futility of any consulting, but I decided instead to relate to her a tale of Till Eulenspiegel, a famous jester who had roamed through Germany, probably in the 13th century.

Till once went into the town of Nürnberg and advertised himself as a magic healer. The director of the well-filled local hospital approached him and said, "I will give you 200 Taler" -- a fortune at that time -- "if you heal all of our patients." Till thought for a moment, and then demanded that he be allowed to give a speech to all the patients at once in one room but without any witnesses.

The director agreed, and so Till talked to the sick: "I can heal you all," he promised, "except the one who is the sickest in here, because I have to make a magic potion out of this person. I can tell who the sickest person here is, because he or she will be the last person to leave this hospital when I'm done with my speech."

The legend says that all patients, even those who hadn't left their beds for years, immediately started to run, and when Till left the room, the hospital was empty. Till got the 200 Taler and left town as soon as he could, because he knew quite well what would happen: the next day, the patients returned even sicker than before.

So what is the relation between a legend about a medieval jester and modern management? For me, this little story is a perfect example of how pressure works: Till had put enormous pressure on the patients by threatening to kill one of them. It seemed as if he had reached the goal to heal the patients because he had directed the pressure on the only metrics the hospital director knew: he lowered the number of patients in the hospital to zero. So was he a successful manager? As little as he was a magic healer! Over time, it turned out that he produced more problems than he solved.

Even if you think that pressure makes your numbers look friendlier, chances are good that it makes things worse. However, wanting to apply pressure is not a sin for a manager if you pursue the right consequences. Rather than following your first idea, I recommend you take this as a sign: if you haven't found a working solution for your problem by now, you probably haven't understood the real cause of the problem. Apply one of the virtues of Lean Management instead and ask yourself seven times, "why?" Why are your customers dissatisfied? Because the defect rate is high. Why is the defect rate high? Because the architecture is bad, because you don't have automated tests, because the developers lack skills, because the pressure on the team is high (here, at least, you should notice that additional pressure would exacerbate the problem). Why is the pressure high? Because the customers are dissatisfied and they are trying to increase their value by putting more pressure on you (alas, a vicious cycle!). Why don't you have automated tests? Because you didn't know this technique and because you didn't want to invest the money. Why? Because you didn't invest in education and you did not wanted to invest money if the return on investment was beyond the quarterly reports.

I don't want to finish this game here, but you can easily see that this exercise uncovers both unsuitable solutions (those that enforce a vicious cycle) and root causes that may help to solve the problem. This is where you should start to heal your organization rather then putting pressure on developers so they start to run for their lives.

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at comments@cutter.com.

-- Jens Coldewey, Senior Consultant, Cutter Consortium