Software engineers don't need to read "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" to know what "spaghetti code" means. But what does it have to do with broken windows?
Enough has been written on the topic of the Broken Windows Theory and its relation to software development so there is no reason for me to repeat this yet again. If this is your first introduction to the topic, just Google "Broken Windows Software" and you'll get plenty of background information and opinions on the topic.
I started thinking about the connection between the Broken Windows Theory and spaghetti code some time after hearing former New York mayor Rudy Giuliani talk about the cleaning up of NYC's streets. I was a software team leader at the time, and I formed my private theory based on empirical observations I made on my team and others around the company. I could see the spaghetti start cooking whenever we loosened our standards of practice, either because of pressure to deliver or just plain sloth. It takes discipline, time, and energy to fix every broken piece of code, design, or document and this is never easy. Methodologies are easier to follow if you start from a place of conviction, and so I began sharing and discussing my "theory" with the team. Not everyone bought into the story, but years after I still believe (and practice) constant refactoring of the code-base is essential in order to prevent "chaos creep" and eventual spaghetti code. However, it is interesting to note that today there are many who believe Giuliani was wrong and that Broken Windows had nothing to do with the reduction of the crime rate in NYC during the '90s.
It is the engineer's job to fix broken windows, but who's responsibility is it to make sure that broken windows are fixed? If you're a manager, then it's your responsibility. In everything you do: how you prioritize tasks, how you treat documentation, how you treat your own broken windows; and not least of which, how you reward engineers with a knack for clean shiny windows - you determine what kind of code base you end up with. Having guidelines, coding standards, designs and architectures to follow is essential to discern broken from fixed, but this is not sufficient.
And as you move higher up you are in the management ladder, your values, your attitude and your actions will have broader consequences - on everything your engineers do; and that includes fixing broken windows. So I try to follow these guidelines:
- Tell the team that a clean code-base is important to me. Again. And again. And again. In fact, most messages to your team need to be repeated over and again; and this is especially true when you want to change team behavior patterns until they form new habits.
- Show my team that a clean code-base is important to me by rewarding engineers who exhibit extra care for the code base. "Rewarding" has many manifestations, but if this is done in a "public" manner I increase the impact of my message because the entire team is made aware. Backing my code-base "gate keepers" against internal and external "sources of entropy" is very important as it solidifies trust and mutual respect.
- Point out broken windows as I review code, git commit messages, documentation, presentations and designs.
Many times when a broken window is brought to my attention as a manager, I cannot afford to halt development to immediately attend to the fix. There are customers waiting at the end of the rainbow and they have schedules and priorities. But ignoring or dismissing a broken window brought to my attention will have consequences on how the development team perceives my values, so I try to:
- Never ignore an engineer who reports a broken window. I either add it to the team's task burn-down list or file a bug report, as a minimum first stage of showing intention. It is important to make the engineers part of the discussion of how and when to do the fix, since ultimately I want them to be accountable for the quality of the code base (shifting accountability from the team leader to the team members deserves its own post which I hope to write some time).
- Schedule a percentage of the team's time to specifically handle broken windows. Adding this to the work plan helps fight the temptation to cave under the daily work pressure. This also shows the engineers that broken windows are not buried and ignored in some list or database and gives credibility to the act of deferring fixes to a later stage.
Of course, not all code bases are alike and if your code base is short lived because you are in an exploratory phase, a start-up in its seed phase, or producing a one-time demo, then your energy should be focused elsewhere. This is where the saying "First things first, second things never" is most applicable. But when building long-lasting code-bases these "second things" can bring havoc if ignored for too long. Fixing every small issue that threatens the integrity of your code is hard work for your engineers, but it starts, and continues, from hard work that you - the manager - puts in.
