Broken windows

In my previous post, I told you that I encountered some non-optimal code. (Yes, really!) You might wonder what I did about that. Well, I fixed it, of course.

Should I have left it alone? After all, I was in the process of implementing this super-critical feature that this super-important client needed super-urgently. Did I waste time on something not-so-important?

Well, yes and no. Yes in the short term, for sure. But I like to think no in the long term. And I’m in for the long haul. I work on a software product, not a project, so I can actually afford to take a long term view.

I’m not alone on this one. The excellent book The Pragmatic Programmer talks about this as well. The authors call it fixing broken windows after a landmark sociology study:

Consider a building with a few broken windows. If the windows are not repaired, the tendency
is for vandals to break a few more windows. Eventually, they may even break into the building,
and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually,
people even start leaving bags of trash from take-out restaurants there or breaking into cars.

But fixing the one broken window prevents other windows from getting broken, claim the authors.

There has been considerable criticism on the broken window hypothesis by other sociologists. And I know of no scientific evidence for the effects of fixing broken windows in software. But the hypothesis makes intuitive sense to me. And so I keep fixing broken windows whenever I encounter them as much as possible.

By the way, if you haven’t read The Pragmatic Programmer yet, then stop wasting your time reading silly blogs, and go buy this book. You will want to keep it along with other classics such as Design Patterns, Refactoring, and The Mythical Man-Month.

The Power of Convention

I ran into some code the other day that wasn’t obvious to me right away. Why? Because it didn’t follow conventions. Let me explain.

In our system, we have what we call ‘binding objects’. These are objects that are persisted in our XML database and that we can use through Java interfaces. The code needed to access them is mostly boiler plate, so we generate it. Since the system was build on Java 1.4, we couldn’t use annotations for this. So, being an XML company, we naturally decided to describe the binding objects in XML and use XSLT to generate both the interface and the boiler plate implementation. We then add functionality by extending both of them.

Now, an often used convention in Java is to have the implementation for interface Xxx be named XxxImpl. We follow this convention often in our code, but for some reason did something else here. This cause me to look around wondering why I couldn’t find the implementation right away.

At this point, I’m sure someone will ask ‘So what?’. That’s always a good question 😉 For instance, in Eclipse, you would just select the interface and press either F4 to show the Type Hierarchy view, or Ctrl-T for a popup listing the same.

That’s true. But it requires a conscious action. Instead, if we had followed the convention, we would get this information for free. For instance, if both the interface and the implementation were in the same package, Eclipse’s Package Explorer would show them above each other. And even if they were in different packages, searching for the interface using Ctrl-Shift-T would also find the implementation. This free-riding is called a ‘widgetless feature‘. It is a Big Thing™ in user interface design.

Granted, it is a minor advantage. But this is just one example. Multiply by all the other places you can use conventions to reduce information overload, and you’ll find you’ll be more productive.

If you’re still not convinced, take advice from someone else. For instance, look at Maven: one of its central tenets is ‘convention over configuration‘.