The very first day of my very first programming job I was told that “Our code is crap because the people who built it had no clue what they were doing.” At the time, I believed it. But as I worked more on the code, it didn’t seem so bad. Sure, there were things I would have done differently, but the code worked, was understandable and was modular.

But this wasn’t the only time I heard this. Oh no! Over my decades I’ve heard this and similar gripes thousands of times. So often, in fact, that I coined Troy’s Law.

Troy’s Law is that many programmers believe that the original architect and all subsequent coders were bumbling around without a good plan or skills. An earlier, less kind version was, “All programmers think the previous programmers were idiots.” In my experience, this also holds true  for  new managers coming into a department. Any department, not just software development.

My feeling is that it is almost never the case that the previous people were inept. Rather, I ascribe it to something different.

I think the problem is definitional.  You may have heard the idea that the vast majority of drivers consider themselves to be above average at driving. There have been all sorts of explanations for this, but the most common explanation is overconfidence.

I disagree, I think the biggest explanation is differing standards. Simply put, what I consider to be good driving, you may not. For instance, I dislike cautious hesitant drivers. I think they waste too much time being worried. But I’m sure these people believe that this same trait makes them great drivers. It’s subjective, but they certainly have a strong case.

Similarly, I think coders tend to see their preferred way of coding as the “right” way and others as substandard. For instance, I once knew a brilliant coder named Brian who crowded as much code as possible onto each screen. He would use very short variable names, no spacing, etc.. Most coders would say that this is a terrible way to code as it is not readable by others. For Brian, however, this method worked much better. How you feel about it depends on your perspective.

As with most things, I see this everywhere, not just with code. In fact, practically every new manager tells me that they can’t believe they stepped into “such as mess.” I hear this even about departments I know are well run.

 I think another large part of it is oversimplification. Managers and programmers often think things are much simpler than they really are. When they start to see how complex the system really is, be it a department or a piece of code, they externalize the issue. In short, instead of admitting that they oversimplified it, they jump to the assumption that other people overcomplicated it. Thus, in their mind, it’s not their fault that they don’t fully understand the system; it’s the previous people’s fault for making it so complex.

One problem this creates is that it makes it much more difficult to know when code really is crap. It’s the “Boy who cried wolf” issue. If everything is being called crap, then knowing what actually needs attention is difficult.

The bigger problem is that it hurts confidence and morale. The people who built the code or who work in the department usually have a better idea of why things work the way they do and are immediately put on the defensive because of the presumption of guilt upon them.  

The next time you walk into a new management position or are put in charge of a new piece of code, take more time before you make judgements. Keep in mind, the decisions you made, which were based on careful consideration and sound reasoning, is likely being met with some skepticism by the new person stepping into your role.

Instead, take on an attitude of curiosity about why things are the way they are. Assume it was done right and well. Sure, maybe it needs to change because the environment has changed, but that doesn’t mean it wasn’t right when it was built.