Code Has No Morals

One of the most interesting conversations that anyone will hear from a development team is the conversation surrounding the quality of the codebase. If you haven’t been around a team of developers lately, let’s review how this conversation often flows.

Developer A: “This code is terrible, whoever wrote this is an idiot.  This is some of the worst code written!”

Developer B: “I agree, let me check the changelog to see who wrote this.”

Developer A: “Don’t bother, I wrote it – last week!”

Sometimes the conversation is a little more colorful, but the premise is the same.  Every line of code written; every application shipped with carries a perception that is normally not based on facts. It is safe to say that anyone redoing a task, could probably do it better.  It’s often said, hindsight is 20-20.

Therefore, there are only two metrics that can be factually measured about an application or line of code. These are so simple yet encapsulate everything about a codebase.  It works. It’s easy to change.

It works. It doesn’t work. It’s binary. It’s simple. It fits into 2 categories. It compiles and deploys. It meets our market needs.

It’s easy to change. It’s not. This can be measured by a stopwatch and the number of surprises after a deployment.  It’s all subjective. Fast isn’t always best and perfect isn’t always best.  This metric is based upon how much risk and time the organization can tolerate.
Code has no morals. It’s not pretty. It’s not good. It’s not ugly. It’s not bad. It’s not too much. It’s not too little. It only works. It can be changed. Try to measure a code base starting by these quadrants.