April 23, 2024

leehotti

Technology and Computer

5 Compelling Reasons Why Code Size Matters

The size of your software solutions matters. As a developer, you should always be conscious of the effects that size and complexity have on development and what it translates into. In past articles (see end of article for links) I have looked at the early warning signs of design pattern abuse, how to better choose design patterns that fit and ways to improve your software design by keeping it simple. In this article I explore why you should consciously think about what you code and provide solid benefits for why you should produce smaller code.

  1. Smaller software is easier to maintain
  2. Smaller programs are easier to maintain over longer periods of time. Why? They are often easier to understand and quicker for new developers to pick up and understand (there’s less to comprehend). Coding Horror has a nice metaphor for this; TL; DR (Too Long; Didn’t Read) syndrome (This is especially true when it comes to reading and comprehension). The larger and more complex anything is the quicker your brain switches into the TL; DR syndrome. Once there, it is much harder to reverse the effect. Think about how often you have gone to read something only to gloss over it because it was too long to quickly take in. Or when you attempted to learn or try something new but gave up before you really started. As humans we want to learn something, comprehend something, understand something, realise the benefits of something….. quickly. The more upfront effort you require somebody to invest in order to understand your program the more likely they are to fall into the TL;DR syndrome unless there is a compelling reason for them not to. Like most things, there needs to be some sort of reward for their time and effort. Tip: Pay careful attention to inheritance hierarchies and keep your relationships as simple as possible. Large inheritance hierarchies have a tendency to explode class numbers.

  3. Smaller software poses less risk
  4. 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)
  • Carries less unknowns

You don’t want code that is so large you have to avoid refactoring, or cannot poke around in it for fear of something collapsing. When code gets to this size, it either quickly begins to die because it is no longer manageable or it quickly loses support; the code is frozen in fear of it breaking.

  • Smaller software yields higher quality
  • Coding Horror advocates the relationship between lines of code and bugs is completely linear but I don’t know whether this relationship is necessarily true. Some code due its algorithmic complexity (Think Big O notation) [http://www.cs.wisc.edu/~hasti/cs367-common/notes/COMPLEXITY.html] is surely more likely to incur bugs than less complex code.

    However, as a general rule of thumb I think it would be safe to infer that the fewer the lines of code the fewer the bugs. Or with every extra line of code, you increase your likelihood of introducing bugs.

  • Smaller software yields performance benefits
  • Whilst it does depend exactly on what your software is doing and how computationally expensive the operations are, generally speaking, smaller is faster. The fewer lines of code required to perform a task the quicker it executes. This is especially true for small tasks that are repeated over and over again. Logically any savings you can make are also saved over and over again.

  • Smaller software is easier to test
  • The smaller your software is (with respect to classes and functions) the easier it is to test; 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 you software was quite large requiring considerably more test code.

    In summary, smaller software is…
    Keep your software small, keep it simple. Doing so will make your code easier to understand and easier to test (because there is less of it). You will end up with a product that has fewer defects, yields greater quality and improved performance by avoiding bloating or overly complicating things that need not be.