Why a large code base is a liability
Solving problems using software is the ultimate goal of software engineers. However, few people completely realize that just writing code is not the solution for all problems we will encounter. In many cases, the solution for code organization is to write less code, instead of more.
A common mistake that software developers do is to think that the solution for each new problem in a system can be found by writing another method and/or class. While this works most of the time, it usually renders the system even more complicated to understand and modify. Therefore, adding new features by means of more code hinders additional progress in the application, instead of helping.
The best solution to this situation is to take a step back, instead of adding more code. Think: how can the architecture of this system be improved so that adding this feature would be easier? When doing this, it is a frequent result that some code will be rendered useless, while more generic code will be added to hande a large number of cases. Thus, even when some software previously written needs to be removed, we are in fact making progress because the system will be able to handle more cases than before.
Although this approach is more painful in the short run, it is nonetheless the best way to develop a system in the long run.
Some Reasons to Avoid Code Inflation
I frequently try to think of ways of solving a problem using less code. When this happens, it is like finding a beautiful solution for a complicated problem — the same feeling that we have when creating beautiful mathematics. Here is a list of reasons why you should strive to write less code:
- Software accumulates features as it grows. Although these are useful when created, most side features become useless as time passes.
- The more features a piece of code has, the less apt it is to change. Thus, it becomes harder to react to new environments.
- Adding features is sometimes inevitable. Specially in a commercial application, adding features is a by-product of accommodating new users. In a big commercial application such as MS Office, it is just necessary. However, having a huge code-base is also a liability. You have to pay to maintain all this software that is not essential to the functionality of the application.
- When a new programming paradigm arrives, it is usually the smaller code base that has the advantage. That is why software is such a good material for start ups: a new product needs only a handful of core features to become usable.
- A corollary of this is that you shouldn’t try to compete with established players by just replicating their features. Try to move your application to a new paradigm that was not initially foreseen by the established player — and that would make it very hard for your competitors to adapt. For example, that is what is happening in the area of web-based software vs. Microsoft.
- Usually, the smaller code base that can handle the core of a problem is the best — simply because it is the easiest to extend.
Do you have other reasons why a large code base is a liability? Let me know what you think.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
