Destroying Teams One Broken Window At A Time
Filed Under Human Factors
Even good teams are susceptible to degrading into undesciplined cowboy coders – and it all starts with a single broken window.
What I mean by a “single broken window” is in reference to the Broken Window Synodrome which states:
If a window in a building is broken and left unrepaired all the rest of the windows will soon be broken. . . . One unrepaired window is a signal that no one cares, so breaking more windows costs nothing. . . . Untended property becomes fair game for people out for fun or plunder.
If disorder goes unchecked, a vicious cycle begins. First, it kindles a fear of crime among residents, who respond by staying behind locked doors. Their involvement in the neighborhood declines…they cease to exercise social regulation over little things like litter on the street, loitering strangers, or truant schoolchildren. When law-abiding eyes stop watching the streets, the social order breaks down and criminals move in.
Understanding that such a vicious cycle exists is important in creating a higher level of discipline and ownership in your current projects. Teams who are not vigilant about immediately fixing broken unit tests or builds, are in a sense, creating a downward spiral within the project. Team members who witness a single blatant act of project vandalism will undoubtedly give into the lazy human nature and retaliate with the common quote, “Well if he isn’t going to do that, than neither am I…”. The sprial begins…
You can never execute and deliver like a disciplined team if you are not disciplined enough to immediately fix the glaring problems. Don’t live with broken windows as having the will power to keep your house in order is the easiest win in the disciplined team game. If you allow your windows to stay broken you may just lose the house and neighborhood.
5 Responses to “Destroying Teams One Broken Window At A Time”
[…] Destroying Teams One Broken Window at a Time (Max Pool) […]
This post is pretty vague. What’s a broken window vs a cracked or slightly smeared? Ok lets imaging my broken is = to your broken..Does this mean my team is playing with fire to leave this broken feature broken for months? I say neigh! Value, Return On Investment, Resources, Risk..These all play critical parts in deciding how a project is managed and how our precious developmental resources are allocated. All to often I run into coders who have no sense of the COST their development incurs. Not just their precious paychecks, but most importantly the risk/cost associated with pushing critical features further off into the future. I know all to well there are tons of stupid developers out there..but seriously..are you suggesting “project vandalism” is an epidemic? If a member of a team keeps making poor decisions or develops poorly..then they need to be replaced and not allowed to poison the rest of the project. So in all Broken Windows != The end of the world as we know it.
@Justin –
You are correct, different environments yield different levels of discipline and thus what is perceived as a “broken window”.
I won’t be dogmatic and tell everyone what I think they should consider broken windows, but here is my team’s list (in order of severity):
1) Checking in code w/o working unit tests
2) Broken build
3) Counting features complete when they are only partially done
For us, these are items that when they occur immediately get corrected so we don’t fall down a slippery slope.
I’ve been involved in exactly this situation, where there was a few of us that were putting in a big effort to encourage unit testing and continuous integration – but this was an uphill battle in an environment where people just didn’t care when the build broke – it would inevitably be left to fix for those who did care, which in the end destroyed the team culture.
Re: Quality and code coverage…
…