The size of your software solutions matters. As a developer, you should always be aware of the effects that size and complexity have on development and what it translates to. In previous articles (see end of article for links), I’ve discussed early warning signs of design pattern abuse, how to best choose design patterns that fit, and ways to improve your software design while keeping it simple. In this article, I explore why you should think consciously about what you code and provide robust benefits for why you should produce smaller code.

1. Smaller software is easier to maintain

Smaller programs are easier to maintain for longer periods of time. Because? They are often easier to understand and quicker for new developers to grasp (there’s less to understand). Coding Horror has a good metaphor for this; TL; DR (Too Long; Didn’t Read) Syndrome (This is especially true when it comes to reading and comprehension.) The bigger and more complex something is, the faster your brain switches to LT; DR-syndrome. Once there, it is much more difficult to reverse the effect. Think about how often you’ve gone to read something only to skip it because it was too long to take in quickly. Or when you tried to learn or try something new but gave up before you really started. As humans, we want to learn something, understand something, understand something, realize the benefits of something…quickly. The more initial effort it takes someone to put into understanding your program, the more likely they are to fall into TL syndrome; DR unless there is a compelling reason not to. Like most things, there should be some kind of reward for your time and effort.

Advice: Pay close attention to inheritance hierarchies and keep your relationships as simple as possible. Large inheritance hierarchies tend to exploit class numbers.

2. Smaller software poses less risk

Smaller programs inherently carry less risk. Smaller projects are often:

• easier to understand
• easier to define
• easier to explain
• easier to maintain
• Easier to predict (predictability is a big part of software risk)
• Take fewer unknowns

You don’t want code that’s so big that you have to avoid refactoring, or that you can’t dig through it for fear something will crash. When code reaches this size, it quickly begins to die because it is no longer manageable or rapidly loses support; the code is frozen for fear of breaking.

Coding Horror argues that the relationship between lines of code and bugs is completely linear, but I don’t know if this relationship is necessarily true. Some code due to its algorithmic complexity (Think Big O notation) [http://www.cs.wisc.edu/~hasti/cs367-common/notes/COMPLEXITY.html] Surely it’s more likely to incur errors than less complex code.

However, as a general rule of thumb, I think it would be safe to infer that the fewer lines of code there are, the fewer bugs. Or with each additional line of code, the probability of introducing bugs increases.

While it depends on exactly what your software is doing and how computationally expensive the operations are, in general smaller is faster. The fewer lines of code required to perform a task, the faster it will run. This is especially true for small tasks that are repeated over and over again. Of course, any savings you make are also saved over and over again.

The smaller your software is (with respect to classes and functions), the easier it is to test it; for the simple reason that there is less code that needs to be tested. The importance of this is that your test coverage is likely to be much higher than if your software were quite large and required considerably more test code.

In short, the smallest software is…

Keep your software small, keep it simple. Doing so will make your code easier to understand and easier to test (because there’s less). You’ll end up with a product that has fewer defects, produces higher quality, and improved performance by avoiding bloat or overcomplicating things that don’t have to be.