During my last semester at college, I had a few companies in mind that I wanted to work for (perhaps surprisingly, Google wasn’t on the list). Several weeks and 2,164 interviews later, one company finally told me they were “close to making a decision” and just wanted me to do one more “quick” phone interview with the software engineering manager.
While I don’t remember all the questions he asked during that phone interview, I do remember him pausing at one point, right after I explained that at one of my jobs I had rewritten a particular application from scratch. He asked me: “so, approximately how many total lines of code were in that app?”
I honestly did not know.
So I tried to explain that the actual number didn’t matter. In the end, however, he continued to press me until I finally just gave an educated guess. That seemed to satisfy him, and we moved on with the interview. It seems that he was trying to figure out whether I had ever worked on any large projects before. Unfortunately, I would argue, he was using the wrong metric.
Since that interview, I’ve experienced and read much to make me distrust software engineering metrics. The truth is, most metrics are used incorrectly. And there are some that shouldn’t be used at all.
Let’s take lines of code as an example. The problem with trying to equate large amounts of code to productivity, quality, or talent, is that a great hacker actually writes a lot less code than a mediocre programmer, not more. Why? Great hackers deeply understand and religiously follow proven principles, such as DRY. In addition, good programmers tend to favor terse programming languages.
So, you might think you can just start looking for people who have apps made up of only a few lines of code, right? Wrong. Depending on the tools and frameworks you use, you can end up with thousands of lines of boilerplate code just to set up an application that doesn’t do anything yet. (This type of code is usually written by code generators). Then you start adding things like a static OR/M and suddenly you’re a coding genius! Look at all the code you’ve written!
OK, wait a minute. I thought we were trying to write less code? Well you are, but you aren’t. Are you starting to see the issue?
Here’s the rub: If you want to measure how significant a project is, or whether someone has any talent, stop using incidental metrics and get to the heart of the issue. It’s simple. Just ask yourself, “how useful is 
this piece of code?” If software isn’t useful (heck, even games are useful in their own way), then what’s the point? Who cares if a piece of software was written in only one week and contains 2.4 million lines of code? If the result is a buggy, hard-to-maintain, unusable pile of steaming rubbish, the programmer has no talent. Period.
Counting lines of code isn’t the only metric getting more attention than it deserves. <insert Sarah Palin joke here>
As another example, take the way experience is measured. Pointy-haired bosses seem to love counting years of experience. And yet time and time again, I have seen young, less-experienced hackers code circles around senior industry veterans. They write better apps in less time with fewer people and sell them on better-looking websites, all while having more fun.
The problem with counting years of experience is that you miss the qualitative analysis. Yes, Joe Engineer has 25 years of experience, but doing what? Did you just do it for the day job, or did you also work on side projects at home? How much effort have you put into self-evaluation and educating yourself on best practices? Are your communication skills any good or do you have silo-syndrome?
Software engineering is still a relatively young field, compared to other disciplines. And, as with any other new field, things change fast. Insanely fast. To excel, you simply can’t do things the same way you did them last year. Needless to say, if you aren’t plugged in to the latest practices, frameworks, and platforms, you will soon become obsolete. While the basic principles of good software development do not change, people, tools, and opportunities do.
Consider what would happen if your doctor decided to stop reading medicine journals and give up educating himself on new procedures. He’s a good doctor. Knows how the body works, right? And besides, it’s a pain to keep up on all the new stuff. Change is hard. He simply doesn’t have the time to keep up on all the latest developments in his field, the way the insurance companies have him over a barrel these days.
Now, flash forward two years: The Cancer Research Institute announces they have a cure for cancer! Hooray! The doctor may hear about it from a friend or on All things Considered during his drive home. But he doesn’t really know how it works. In fact, it relies on several other cutting-edge skills he hasn’t taken the time to learn. If you got cancer and are looking for a physician, who would be you first pick? Why?
Past experience is simply not a good measure of someone’s ability to meet present-day challenges. Someone can have 25 years of experience, and still be a terrible programmer. Only those who are constantly learning, growing, and have a solid aptitude for writing code are going to be any good at what they do. People like Scott Hanselman do it. So can you.
At the end of the day, it’s the portfolio that matters. Stop measuring things indirectly. Instead, get to a place where a great product is being developed. Then, if you really must measure lines of code, at least reward people for creating the same great product more efficiently, with less time, code, and experience. Not more.
We’ve created a level playing field where experience doesn’t matter. The only thing that matters is your work…. Good designers do very well in this model because, very simply, they are good designers.
New! See our recommended reading list for principle-based engineering.
