There are various statistics related to the average defect density (i.e. how many defects one can expect to find in a code base); suffice to say, the numbers point to unhip ranges like

20 to 30 bugs for every 1,000 lines of code

and even

100–250 defects per thousand lines of code

Given this amazingly horrible data, what is one to do about it? There are a few possible answers, including:

• Write a lot of tests
• Write better code
• Write less code

The first choice is rather noble; however, it turns out to be a Herculean effort (to say the least) and therefore, few teams actually do it. Writing more hip code is a great idea– there are tons of resources related to writing better code (Robert C. Martin’s “Clean Code: A Handbook of Agile Software Craftsmanship” comes to mind) and I highly recommend teams strive to embrace the craft of coding. In spite of that, I have an alternate suggestion: write fewer lines of code.

If the average application has anywhere from 2 to 25 bugs per 100 lines (oh my goodness that’s an enormous number!) doesn’t make sense to write fewer lines of code? Of course! The question then becomes, how do you write less code? As it turns out, the answer is simple: you borrow code.

Borrowing code is certainly not new, yet I’m continually astonished to find corporations maintaining their own logging frameworks, web frameworks, UI frameworks, the list goes on and on. Why would you write your own logging framework in this day and age? Why not use log4j? Why write a web framework when you can borrow any number of wildly successful ones, such as Rails?

Of course, these frameworks have code in them too– but the beauty is that you end up leveraging the The Wisdom of Crowds; that is, you end up leveraging a community of focused smart people with varying backgrounds maintaining the code and usually a wealth a users providing feedback in multiple environments and situations– making the code more stable.

Aside from borrowing open source libraries to handle commodity issues (i.e. logging, ORM, web frameworks, etc) there are other techniques too. If you write Java code day in and day out, languages like Groovy offer manifold opportunities to lessen your lines of code.

For instance, need to read the contents of a file? If you write this requirement in Java, you could write something like this:

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;

public class ReadFile {
 public static void main(String[] args) throws Exception {
  BufferedReader reader = new BufferedReader(
     new FileReader(new File("/Users/aglover/temp/myfile.txt")));
  String output;
  while ((output = reader.readLine()) != null) {
   System.out.println(output);
  }
 }
}

Note, the above Java code isn’t perfect nor am I trying to bash Java! But, it took 12 lines of code to print the contents of a file.

In a language like Groovy, for instance, I can achieve the goal with one line of code.

println new File("/Users/aglover/temp/myfile.txt").getText()

The above code isn’t magic– in fact, it is using essentially the same code from earlier (it’s all Java!). It’s just that someone else wrote it and scores of people are using it and making sure it works day in and day out. Ergo, using 1 line of code means I have 11 fewer lines of code to maintain (smarter people than me are maintaining those other 11 lines, baby!).

If it’s your bag to write better code, man, then I suggest you try writing less of it. Instead, focus on writing the minimal amount of code that serves a business need and borrow everything else. Can you dig it, man?