When you’re new to software development, it’s easy to fall into the trap of thinking that more code is good because a lot is getting done. However, that is not always the case because there are consequences with more code. It may not immediately show itself, but sooner or later it can start creeping into your project. So, this means less code might actually be better. In this post, I’ll share 4 reasons why sometimes having less code might be better.
1. Less Code Means Less to Maintain
Every line of code a project has will need to be tested and maintained. So, with every new line of code, you’ll be introducing uncertainty, which needs to be tested. It might not seem like much, but when you start adding one line of code at multiple places it starts to really add up. Not only does it increase the effort and time of testing, but it can also introduce bugs in the future. The only way to truly mitigate the issue is to write no code at all, which is unrealistic. So, you’ll have to settle with the next best option of writing as little code as possible.
2. Lower the Chance of Bugs
Every line of code is a chance for a bug to find its way into the software you’re building. Maybe not at the time that line of code was written, but in the future, that line of code may cause a bug. So, it is a good idea to remove code that is no longer necessary. Not only does it reduce the amount of code, but it also prevents those pieces of code to introduce bugs in the future. Also, most if not all software projects nowadays should be using version control, which means it’s not that difficult to get the deleted code back.
3. More Code Doesn’t Mean More Is Getting Done
It can be easy to fall into the illusion that more code means more is getting done. But that is not always the case. It can mean something is overengineered, which brings unnecessary complexity and chance for errors.
It is also easy to fall into the trap of rolling your own frameworks or libraries because existing ones don’t do exactly what you wanted. In such a case, it would exponentially increase the complexity, level of effort, maintenance, and the amount of code of the project. In the majority of cases, you can live without the features that you hoped the frameworks or libraries would provide. The tradeoff is that you can have an out-of-the-box solution, which does the majority of what you want versus building from the ground up something to do everything you want. The benefits would be minor in most cases for building your own framework or library, but the cost will be significant.
4. Less Code Tends to Be More Simple
Code is written for humans to read. What is something that humans love to read? Something that is simple and easy to understand. Although the machine is what would execute the code, the compiler will convert the code for the machine. So, in the majority of cases, you can consider that you’re exclusively writing code for humans to read and not the machine.
Now, how exactly does less code lead to simplicity? After all, a short academic paper is going to be way more complex than a long kid storybook. Here are some situations where less code can mean more simplicity:
- When the solution is over-engineered
- Overly complex abstractions for supporting potential features
When a solution is over-engineered the amount of code tends to bloat up. It is solving a simple problem, but the solution is extremely complex. It becomes the opposite of what you would want, which is a simple solution to a simple problem. When working with code of this nature it is really easy to make a mistake.
Overly complex abstractions to support potential features is something that at one point or another you might have been guilty of — or maybe it’s just me. While it’s good to plan ahead it is not always necessary to do that in code. The code you write should focus on solving the problem right now, but be extensible such that a new feature can be added easily. When you engineer a solution to accommodate for potential features, you’re bringing in unnecessary overhead and complexity to the project. Worst of all, you probably won’t even need it — this is called the YAGNI (You aren’t gonna need it) principle. So, all you ended up doing is creating an over-engineered solution to handle something that could have been done much simpler.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What is your experience with large and small codebases? Do you think less code is more sometimes?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.