So let’s talk about systemic racism in computer science, shall we? I was reading the The Pragmatic Programmer by Andrew Hunt and David Thomas. As a former software engineer and manager, I found myself nodding my head in agreement at much of what they said as I bounced around the tips listed in sections of the book.
Then I read section 1.2.
Section 1.2 is where they use the analogy of the “Broken Windows Theory” to describe software that contains a defect that is not fixed. This can contribute to “software rot” and neglect, as opposed to “clean, functional systems.” They continued the (inverse) analogy at the bottom of page 5 and onto page 6, with a story about how a fire department behaved in saving a “rich” house, so as “not to mess it up”. The summary just about broke my brain…
“One broken window — a badly designed piece of code, a poor management decision that a team must live with for the duration of the project — is all it takes to start the decline” … “it’s all too easy to slip into the mindset of “all this code is crap”” … “By the same token, if you find yourself on a team and a project where the code is pristinely beautiful — cleanly written, well designed, and elegant — you will likely take extra special care not to mess it up, just like the firefighters.”
I did a Google search for “broken window theory programming” and almost about every search result reeked of … bias, systemic racism, and toxicity. Page titles like “The Broken Window Theory — Coding Horror” and “Software Rot, Entropy and the Broken Window Theory …”. Worse was the picture on the header of Keeping Broken Windows Out Of Software — Lachlan Eagling (apparently an unattributed photo from Unsplash) which shows a roof top in Manhattan that is covered in graffiti.
Admittedly, I really do love a good analogy when teaching, particularly teaching computer science, but this infuriated me. Particularly when I started reading a little more about this theory and its implications. One article I found Loose Cigarettes Today, Civil Unrest Tomorrow The racist, classist origins of broken windows policing referenced Broken Windows Policing Doesn’t Work — It also may have killed Eric Garner.
My goal is NOT to argue whether the Broken Windows Theory is accurate or not — that is not the point of this post. However, I will point out the crux of Broken Windows Theory is the concept of using a negative emotion, fear, to justify keeping things “orderly” (i.e. one broken window and everything will fall apart).
My goal IS to argue that we, as computer scientists, computer science educators and publishers, need to think about how using this analogy or other similar negative analogies could negatively impact a person’s sense of belonging — particularly if that person is a student in a classroom. Who might this keep in your classroom? Or rather who might it keep out?
Imagine you are a student who grew up in a neighborhood with a lot of broken windows, or worse, in a home with broken windows. How would this particular analogy make you feel? Would it make you feel welcome in a classroom? What if, instead, you were awarded a “super hero” action figure if the code you wrote worked exceptionally well. Years ago I worked at a company that would do this, and, despite this super hero presumably being male (it was the Tick), it was a celebration when I earned that prize. This positive analogy was incredibly inclusive and effective. Moreover it was actively empowering.
So… what should be done?
- Manuel A. Pérez-Quiñones recently wrote an article What Can CS Departments Do? which had a number of salient recommendations including “4. Students are not like you (the professor)”, “7. Unconscious bias is real”, and “8. Rethink your curriculum”.
- Think critically about the analogies we use, and in some cases, what the exclusionary systems from which they emanated. In this example, what is the purpose of using the fear of a “broken window” to “keep” people from leaving a defect in a codebase when positive feedback could be just as effective.
- Please stop using this particular unnecessary analogy when discussing code quality.
