What are we thinking?

Okay. So now you have inherited someone else’s code. You typically review the automated tests (if any), available documentation (if any), and then the code itself. It is here that at lease one person in each development group will say, “What were they thinking? This code sucks.” It is at this point that I cringe. Yes, the code may not be the most elegant. But to just simply state, in your self-proclaimed superiority, that the previous programmers were stupid is both unprofessional and short sighted. Don’t misunderstand me. I am not saying that in the name of being nice to overlook and tolerate crappy code. My point here is that there is more than initially meets the eye.

What got me thinking about this was an article that I ran across by Dave Hunt and Andy Thomas entitled, Software Archaeology. In it the authors state:

Archaeologists generally don’t make wisecracks about how stupid a particular culture was (even if they did throw dead bodies into the only good drinking well). In our industry, we generally don’t show such restraint.

As stated above, it has been my experience that in the software development field, we are too quick to criticize. They then go on to write:

But it’s important when reading code to realize that apparently bone-headed decisions that appear to be straight out of a "Dilbert" cartoon seemed perfectly reasonable to the developers at the time. Understanding "what they were thinking" is critical to understanding how and why they wrote the code the way they did. If you discover they misunderstood something, you’ll likely find that mistake in more than one place. But rather than simply "flipping the bozo bit" on the original authors, try to evaluate their strengths as well as weaknesses. You might find lost treasure—buried domain expertise that’s been forgotten.

Therefore instead of just asking, "What were they thinking?” we need to consider “What and how are we thinking?" to get the most out of the code that we sometimes unearth and/or must excavate.