This week, I have been reading Tipping Point by Malcolm Gladwell. It talks about how large social movements happen, breaking it down into three things: the people involved, the stickiness of the message, and the context. In discussing the context, he introduces the Broken Window Theory by James Q. Wilson and George L. Kelling, which explains how environment plays a big role in bringing about bad behaviour in individuals.
This is my simple understanding of it. In New York, in {{ some_date_range_before_1990 }}, there was a high crime rate. There was a policeman who had a bright idea. Instead of complex crime-fighting strategies, he decided to fix broken windows, remove graffiti from trains, and ensure that the environment was a nice environment. The rationale was that a nicer environment would bring about more responsible behaviour in individuals, because environment affects behaviour. * And it worked. Apparently.
Now there are many debates about whether this is true or not, and I am not smart enough to weigh in on those debates. But one thing I have seen in my short existence on this earth is that this rings true for an existing code base. You may be like me, an eager TDD wannabe zealot who wants to ensure that the project has 100% coverage; who wants to make sure the code has been refactored so that all the good principles bestowed by the judges of software development (or engineering, or programming, or science, or whatever) are adhered to. Then you get to a project where every one of those principles are broken.
You want to write tests, but you somehow lose the will to do so. Something deep inside of you wants to refactor, but there are no tests, and there is no will to write tests to ensure that the refactoring won’t break something. When writing new functionality, it is easier to say ‘just this once’ when doing something you’re not supposed to be doing because that’s how it has been done in the existing code base. And you don’t write tests for the new functionality, because hey, there aren’t tests here anyway.
Bad code can break good developers. And good developers can get into bad habits when working on bad code. Like writing more bad code. And increasing the chance of future good developers getting caught in this cycle. So how does one break the cycle?
- Write tests. How does one refactor to clean up the code if one can’t ensure that their refactoring won’t break something? By writing tests. What if the code is not testable? Then make it testable (which may possibly break something), then write tests. What if I don’t feel like writing tests? Then you are an EP a.k.a Enemy of Progress (if you don’t get that reference, then it wasn’t for you).
- Write Clean Code. ‘Just this one time’ is never this one time. There’s that boy scout rule that some smart guy mentioned which says ‘leave the playground better than you found it’. Being a good developer is a habit, not an event, or a ‘skill’ on your LinkedIn profile which you have been endorsed for (who came up with that idea anyway?)
- Incremental Improvements. Improve one small thing today. Then a small thing tomorrow. Then a small thing the day after that. Then in a {{ undefined_time_period }}, it will be looking so much better. And the world will be a happier place. Maybe. Kinda.
Do you have any stories working with old legacy code?
** This is an oversimplified explanation. Bing (or google, or duckduckgo) ‘Broken Window Theory’ for a better explanation.*
Patrick Kayongo 
