Why is there so much unnecessary code?
How To Write Less Code and Get More Done.
The less code there is, the less there is to break, justify, or maintain
Legendary author Jules Verne rightly said,
A well-used minimum suffices for everything.
And in today’s era, the well-used minimum also applies to code. It is sad but true: In our modern world, there is just too much code. More precisely, too much unnecessary code floating around choking the good code around them.
That said, unnecessary code is inherently bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take, the longer it takes a new employee to make sense of your system.
Adding to all this hullaballoo, code is produced by engineers. To make more code requires more engineers. The more engineers, the more the communication costs, which further adds to the ever-increasing basketful of code maintenance and development costs.
And the one solution to all these problems is writing less code.
There are many benefits of less code:
- Less code to develop = lower development cost.
- Less code to develop = lower maintenance cost.
- Less code to develop = fewer bugs in code.
- Less code to develop = more efficient testing.
And the biggest benefit: The less code there is to read, the higher the odds are that someone will actually read it.
Here are some ways to write less code.
You Aren’t Gonna Need It
YouArentGonnaNeedIt (often abbreviated YAGNI) is an extreme programming practice, which states:
“Always implement things when you actually need them, never when you just foresee that you need them.”
Even if you are totally, totally, totally sure that you will need a feature later on, do not implement it now.
There are two main reasons to practice YAGNI:
- You save time because you avoid writing code that is not required.
- Your code is better because you avoid polluting it with guesses that turn out to be more or less wrong but stick around anyway.
The YAGNI concept is sensible no matter what project management methodology you use. Superior design requires a thoughtful balance of features. Bad design stuffs in too many features, which creates an unwieldy, “nightmare to maintain” code.
The rule of thumb is, stay focused on things that are clearly needed and not on what is likely to happen.
Do Not Write Bulletproof Code
A bulletproof code is a perfect code, a code that will work with any input or unexpected condition.
The idea has a lot of emotional appeal, especially to hotshot developers who consider it a personal failure should their code fail some scenario. That said, writing or attempting to write bulletproof code is unrealistic and unnecessary as every object in this world, including software, has limitations.
Attempting to implement a perfect module will involve writing extra conditions, which will make the code more complicated, obliterating the very purpose for which the code was written. The module, in due course, becomes larger, costlier, and a potential candidate for poor maintenance.
That is why the rule of thumb to write less code should be to code the simplest thing that could possibly work.
Extreme programming mentions two golden rules to write simple code:
- First, implement a new capability in the simplest way you can think of that could possibly work. Don’t build a lot of amazing superstructures, don’t do anything fancy; just put it in to make it work. Make the code pass the unit tests for the new feature (and all features, as always).
- Second, and this is critical to the rule, refactor the system to be the simplest possible code including all the features it now has. Follow the rule of OnceAndOnlyOnce and the other code quality rules to make the system as clean as it can possibly be.
Always remember, we are not looking for the quickest way; we are looking for the simplest result. Therefore, we first break the existing method into pieces. That leaves the existing test cases running. Then we modify (simply, now) one of the little methods to handle the next test case and so on.
Always remember the ultimate elegance is simplicity. Controlling and eliminating complexity is the essence of great programming.
Never Make Your Code Worse
This is the Hippocratic Oath for developers. As developers, we are often advised not to cut corners and take shortcuts that degrade the code and make it worse.
Software engineering procedures, like medical procedures, can be intrusive and destructive. Likewise, the tools and techniques that we use can be new and untested (or barely tested). Moreover, we don’t have the equivalent of medical licensing boards or the U.S. Food and Drug Administration (FDA) to regulate the practice of software engineering and the tools that we adopt. Thus, we sometimes subject our “patient”—the software—to unnecessarily risky procedures, without really understanding the risks.
In the course of fixing a problem, we sometimes do more harm than good. In his software engineering classic, “Code Complete,” Steve McConnell says that if you aren’t fixing the underlying source of a problem but just the symptom, you’re doing more harm than good in that you’re deceiving yourself into thinking the problem has gone away.
Sometimes this is difficult, however. It may be that legacy code makes it very difficult to add functionality properly without harming your code. To be realistic, we restate “Never make your code worse” to “Only degrade your code intentionally.”
Yes. If you cannot figure out how to make the change without degrading the code, inform other team members before making the change. The point is that you are intentionally degrading the code.
This is, of course, not going to prevent bad code, but it gives you some time to think and reflect. Experience shows that a person will stop just short of a good solution because they’re willing to do the first thing that comes to mind. Note that we are not requiring getting permission or even getting a better result.
Another advantage is that it prevents unpleasant surprises at wrong times and makes everybody in the team aware of the problems that can be expected. The team then truly works as a team to get it sorted.
Avoid Needless Concurrency
Concurrency is a double-edged sword. It should only be used when needed.
When source code is executed sequentially, the code is easier to understand and debug. When concurrency is used, code may get executed in parallel or in some irregular order. This difference in execution makes it really difficult to debug issues in code. Needless to say, it complicates program design and implementation in more ways than one. Some issues that may occur due to badly implemented concurrency can be:
- Race conditions: Operations occur unpredictably.
- Deadlocks: Tables get locked waiting for simultaneous operations to complete.
- Resource starvation: An operation is perpetually denied access to a resource it is waiting for.
One of the world’s most infamous software disasters was caused by a badly implemented concurrent condition. A programming error in the Therac-25 radiation therapy device resulted in the deaths of four people.
That said, all modern programming languages and frameworks provide many concurrency tools. But finally, it all depends on the developer, who needs to decide on how, when, and where to implement them to get the best results.
Finally, Don’t Be A Code Hoarder
Compulsive hoarding, also known as hoarding disorder, is a behavioral pattern characterized by excessive acquisition of and an inability or unwillingness to discard large quantities of objects that cover the living areas of the home and cause significant distress or impairment.
And when developers become hoarders, they cling to code even when it is buggy or obsolete. Such developers never delete any code and resist code removal generally. When confronted, you may get answers like “we may need this code someday” or “I need this code to execute activity X” and so on.
Have you ever been a code hoarder? Have you given up on any effort of cleaning because you know that you don’t have the time to clean up the mess? If you have, you are a code hoarder, and your work life is a deep and overwhelming mess.
Hoarding is irrational behavior. If you think the code’s existence can be justified but you are not sure, tag it appropriately for revisiting later so that it remains in your radar. Finally, code that serves no purpose and is not required has to be deleted. Period.
A good programmer makes their code better and better every day. The quality of their code improves with time. The legacy code left by good programmers will always be cleaner than the older code. Good programmers do not leave a mess. They leave a reputation embedded in code to be remembered forever.
As Robert Martin has rightly said,
“Truth can only be found in one place: the code.”