The hidden danger of accepting broken windows
By now we should all be aware of the "broken window effect", not least because there is now concrete evidence that it exists. As a reminder, the "broken window effect" is that subtle, damaging change in attitude that causes perfectly normal, law abiding, sane people to break social norms if they see others doing the same thing. People are more likely to litter an untidy, graffitied street than a clean one. They are more likely to damage a car that has already been damaged. And they are more likely to write badly structured code and cut corners in a codebase if there is evidence of others doing the same thing.
But I think there is an insidious, darker side to this. Accepting broken windows for too long desensitises and deskills your team.
What happens is this. The bad behaviours that happen due to being surrounded by the broken windows - broken builds, releasing untested code, mend-and-make-do workstations and so on - become the new social norms. People get used to them; they will become disinclined to fix them, and it becomes the accepted reality. "It's the way we do things here". But if they are now the accepted status quo, then the next thing that gets broken is on top of the existing problems. Since the culture has now become one of acceptance, the new problem doesn't get fixed either. And so on - the system degrades to the next level. And the next. The cycle spirals downwards.
Remember, these are sane, normal people being sucked into this. Suddenly there is a real danger that a perfectly good software team get so used to breaking the rules and living with the broken windows that they forget what the civilised rules are. They effectively forget what "good development" is. If you don't use the good practice patterns - green builds, continuous integration, TDD and so on - you do forget them. Your team actually begins to deskill, which in turn speeds up the descent into failure....
Fortunately the process is reversible, but depending how far it's gone and how much technical debt you have accumulated before accepting the situation, fixing it can be painful. So just bite the bullet, and fix those broken windows as soon as you see them. Demand better!
But I think there is an insidious, darker side to this. Accepting broken windows for too long desensitises and deskills your team.
What happens is this. The bad behaviours that happen due to being surrounded by the broken windows - broken builds, releasing untested code, mend-and-make-do workstations and so on - become the new social norms. People get used to them; they will become disinclined to fix them, and it becomes the accepted reality. "It's the way we do things here". But if they are now the accepted status quo, then the next thing that gets broken is on top of the existing problems. Since the culture has now become one of acceptance, the new problem doesn't get fixed either. And so on - the system degrades to the next level. And the next. The cycle spirals downwards.
Remember, these are sane, normal people being sucked into this. Suddenly there is a real danger that a perfectly good software team get so used to breaking the rules and living with the broken windows that they forget what the civilised rules are. They effectively forget what "good development" is. If you don't use the good practice patterns - green builds, continuous integration, TDD and so on - you do forget them. Your team actually begins to deskill, which in turn speeds up the descent into failure....
Fortunately the process is reversible, but depending how far it's gone and how much technical debt you have accumulated before accepting the situation, fixing it can be painful. So just bite the bullet, and fix those broken windows as soon as you see them. Demand better!
Comments
Post a Comment
Comments on this blog are moderated. Intelligent comments will be published, but anything spammy or vexatious will be ignored.