November 23, 2005

...Learn TDD with Codemanship

Adaptive Tension & Organisational Dysfunction

What happens when we encourage the wrong kind of behaviour - if we ignore it when people do the wrong things, or worse still, reward them for it? Consider house-training a dog: should you give it a bone and a pat on the back when it does its business in your shoes, or only when it learns to do its business in the yard?

Take software quality as a good example: what happens if businesses allow unacceptably buggy and unmaintainable code to go into a release? One organisation put up a big sign congratulating the team on meeting the deadline (with a pile of rubbish), and threw them a lavish party. The bug database had more than 900 open defects in it, of which more than 100 were categorised as "severe". There were two severe bugs for every feature in the application, and it was virtually unusable as a result. But they hit the deadline, and heads didn't have to roll the day after - so they got champagne and a slap on the back.

Come time for the next scheduled release, and the team were really struggling by this point. Of course the bugs mattered! As soon as people starting trying to use the software the bug reports started flooding in - most of which were already known about. They had to be fixed, and that took up a big chunk - in fact most - of their time. The new features planned for the next release just weren't going to fit into the schedule. So, what did they do? They stopped fixing bugs and rushed in the new features. By the time of the second release, the number of open bugs was more than 1500, with over 170 known to be severe. But they hit the deadline again (with a few long nights and some sacrificed weekends). There was another, even bigger party, and some developers got promoted to lead their own teams.

Bolstered by the "success" of the first two releases, the managers started to get more ambitious. They scheduled even more new features for the third release, and shortened the schedule by a few weeks. And still the bug reports cam flooding in.

By the time it was nearing the deadline for the third release, it had become like wading through treacle. There were so many bugs, and the code was in such a sorry state, that it became extremely difficult to add anything new without breaking something else. For every bug they fixed, they introduced two more. They were rapidly sliding backwards. Some developers worked 90-hour weeks for 6-7 weeks in a row. I saw them in the morning as I strolled in after a relaxing evening or weekend. They were the walking dead...

Emergency meetings were held to see if a miracle could be performed? "We're not going to meet this deadline. There's too many bugs and too much new stuff, we just can't fit it all in. What should we do?" "Screw the bug fixes. Find a way to fit it all in!" came the reply. (This reminds me of a tale my brother told me about an interview he had. The project manager asked him "what would you do if there wasn't time to fit everything in before the deadline?", and my brother gave the only sensible answer he knew, which was "cut the least important stuff out of this release", to which the manager replied "no, that's not the answer I'm looking for. What would you do to fit it all in?" Some managers really think like that...) Anyway, a strategic decision was made to bury their heads in the sand and pretend everything was going to work out just as they had planned.

The deadline came, and they somehow managed to tick every box in the list of new features, but the bugs kept going up and up and the code continuted to rot. And there was another party, but many of the developers didn't attend. Sleep was their reward.

The 4th release never happened, and the users revolted, threw the - by now completely unusable - software out, and went back to doing things the old way (which appeared to work just fine).

The moral of this story?

If your developers shit in your shoes, don't give them a bone or a pat on the back

Now, I'm not a great believer in fear as a motivating force. I find that the carrot is far mightier than the stick in motivating people to go in the right direction. Choosing when to offer a carrot is critical to encouraging successful behaviour. A spoilt child is usually one that is rewarded no matter what they've done. They don't learn to associate good behaviour with getting candy. I despair when I see parents lavishing gifts willy-nilly on their children, and then resorting to shouting and smacking to discourage bad behaviour. Punishing children teaches them negative lessons: "don't do that!". Rewarding them teaches them positive lessons: "yes, do that!" We could spend an eternity teaching them about everything that's bad. It's far more economical to highlight the correct path than to try to fence off an infinite number of wrong paths. This is why some people who have had quite strict upbringings, with lots of early-to-bed-without-any-supper and the occasional smack on the legs, can be quite dysfunctional. They don't know what's right. They just know a whole bunch of stuff their parents told them was wrong.

It goes back to the question of how do you herd cats? Catfood works much more effectively than water pistols.

In software development, the fear of getting it wrong can have a negative effect on productivity. I see many people who are trying to avoid getting a smack, rather than attempting to do the right thing.

It's vital, therefore, to design positive performance metrics and to apply them in a positive way. If the developers fear the metrics then they'll go into damage-avoidance mode and all their energy will be spent covering their behinds rather than moving forward. Negative metrics don't provide direction, in much the same way that roadblocks only tell you where you can't go.
Posted 15 years, 2 months ago on November 23, 2005