More code is not the answer

Back in the day there were two lines of thought about software development. One group, I'll call them KLOCers, who follow the "if it ain't broke, don't fix it" method of development. This group was paid based on the number of lines of code (LOC) they generated, usually measured in the thousands (hence KLOC), which made sense to all of the financial geniuses who saw LOC's as a measurable indicator of productivity. Of course if LOC and remuneration are tied in a direct relationship the incentive is to create more code, which dovetails nicely with not fixing the 'not broken' parts.

Another group (that I'll call Hackers), on the other hand, made their goal to write the smallest, tightest, most efficient code possible. This group may prototype 3 different methods to see how each performs, promoting the champion and discarding those that didn't survive the brutal testing. Some members of this group would even make a game of rewriting another Hacker's code to see how much better they could make it as they squeezed every byte to make the code fit into (what would now be considered a tiny amount of) RAM and encouraged it to perform faster.

So, we have two opposite perspectives: create more code and create better code. Even though it may not appear so prima facie, these two views are as diametrically opposed as essentialism and existentialism. If my experience is any basis for judgement, and I believe it is, then more code is always going to be more difficult to maintain in the long term.

Smaller code means fewer things can break. Tighter code (better isolation/encapsulation) means breaks are easier to find and fix. Faster code means...well, we all know that faster code is better. In contrast to the smaller, tighter, faster mantra is the view that LOC's are the only reliable measure of productivity. Such a view, that LOC's are a measure of productivity, is another symptom of GSD Syndrome and, thankfully, (again based on my experience) one that is going the way of the dinosaur.

The view still persists, however. The difference between then and now is that now it's not the financial geniuses that push it as a measure of productivity, but rather KLOCers themselves who throw code at a problem (which generally breaks Robert's Rule #15 and Robert's Rule #20). Whereas some developers have the goal to put less code in production than was in the previous version, others seek only to solve their problem in the fastest way possible, which is a road that leads to ruin. Instead, seek first to understand the problem you are trying to solve. Ask yourself

• what factors have created an environment that gives rise to the problem
• what code is already in place to mitigate this type of situation
• can we make the code smaller, tighter, or faster to fix this problem

When you have answered those questions, you have begun your journey to finding the right solution.