Writing less code helps developers build clean, functional software that’s easy to maintain over time.
Ask any industry expert what makes a good developer and they’ll offer a variety of answers.
Broad technical experience, good communication skills, and excellent time management head the list. Those are all useful characteristics.
However, there is one trait that usually gets overlooked, something that has an enormous impact on both the development process and final quality: the ability to write lean, concise code.
The best developers know how to get more mileage from less code.
It’s an especially important skill in this era of reusable code, when the availability of ready-made components provides so many shortcuts for busy developers.
Those components represent a huge step forward by cutting the amount of tedious programming required in the early stages of a project.
The downside is that these development tools make it easy for inexperienced developers to write bulky code.
By flipping the script - focusing on writing less code instead of faster code - developers can build reliable software with low technical debt.
What Do Developers Do (Really)?
Developers are subject matter experts with the technical skills to build and maintain software.
hey work to understand technology in order to create technology-based solutions for real world problems.
Nowhere in that description does it say, “write code”.
Code is obviously how the technology gets built, but it should be seen as a means to an end rather than the whole job description.
Developers need to combine business sense, problem-solving skills, and technical knowledge if they want to deliver the best value to their clients.
Too often, developers forget their true purpose.
They write code according to habit, personal style, or excitement over a new tool they’ve been hoping to use instead of prioritizing ease of maintenance and scalability.
The result is software with a huge code base and a shortened usable life.
The Code Economy Advantage
When it comes to code, more is actually less. The odds of project failure go up as the code size increases.
After all, more code translates into more chances for something to go wrong.
One area of concern is bugs that make it into the final software. The industry average ranges from 15-50 errors per 1000 lines of code delivered.
Projects with sizable code bases are going to have more flaws as a flat statistical reality.
Denser code is less likely to be read thoroughly, too, which means the ratio of errors to code will fall towards the higher end of that scale.
Having more lines of code also leads to higher technical debt.
Future maintainers (and anyone trying to update the software) must navigate that code to fix bugs, add features, and integrate the software with future systems.
Software development is a place where labor is a significant expense. When time spent on development and maintenance rises with a program’s size, it spurs an equal rise in IT spending.
There’s another increase in developer overhead from additional meetings and longer on-boarding processes when new team members are added.
Considering all of this, there are clear advantages to emphasizing concise code, both in cost and quality.
Code written efficiently and directly is:
Developers should work to write as much code as they need to get the job done correctly- and no more.
Why Developers Get “Code Happy”
If writing less code has such a powerful effect, why do developers continue to write far more code than is actually needed?
There are a few typical motivations:
Desire for Productivity
In some agencies, lines of code is used as a measure of productivity. The thinking goes that more lines of code - often abbreviated to LoC - equals more work done.
This is particularly common when running distributed teams who typically work without in-person direction.
The problem is that measuring productivity by LoC completed leads to sloppy writing and a focus on quantity over quality.
It’s like measuring a hotel’s success by how many towels they use; the fact has some bearing on success but can be very misleading.
Software development always involves trade-offs: simplicity versus feature richness, security versus performance, speed over space.
Sometimes the value of writing less code gets lost in the shuffle.
There’s no unimportant component of development.
Every project has different demands that require a tailored approach.
However, brevity is important enough that it should always be a high priority.
Developers tend to be “code geeks”. They like to write a bunch of software and try new things purely for the sake of trying new things.
It’s a great quality when they’re learning or experimenting.
However, it’s not the best idea when working on enterprise software. The approach usually results in four times as many lines of code as needed for a task.
Developers need to direct their talent towards building software that meets the product owner’s goals even when that conflicts with their personal preferences.
Lack of Skill
Writing clean, concise code takes skill and practice.
Often less-experienced developers don’t know how to reduce LoC without cutting features or impacting performance.
Almost everyone does this in the beginning, but getting past it is part of honing developer skills.
Developers all learned their trade somewhere.
Every school of thought and development philosophy imposes certain ideas about how to make code more readable.
The issue arises when holding to convention comes at the expense of code economy.
As much as 54% of LoC are inspired by convention as opposed to utility.
Creating whitespace, intentionally skipping lines, and linguistic keywords are examples.
There are ways to improve readability without conventions that pad out the code base.
How to Write Less Code?
Making something complex look simple is hard, but it’s very easy to complicate simple things. Code economy is like that.
These are a few straightforward guidelines that can help developers get past complexity and write less code.
Build on an Existing Foundation
There’s no reason to reinvent the wheel. Use libraries instead of recreating what others have done well countless times.
Innovation should be saved for problems that don’t already have good solutions.
The Right Black Boxes are Good
Choose tools that enable code efficiency.
Be Careful Selecting Dependencies & Frameworks
Anything used should be mature, well-supported, and preferably have already proven its worth in practice.
It’s also important to consider the size of the community and strength of company backing so future developers will have an easier time working with the code.
Reframe “LoC written” as “LoC spent”
Break down the connection between LoC and assumed productivity by changing the way it’s measured.
Instead of counting how many lines a developer was able to write, measure how many they needed to get the job done.
Compare it to a golf score: the fewer LoC that can be written while still delivering a good product and meeting sprint deadlines, the better.
Spend some time during the planning phase to brainstorm how less code can be written.
Planning ahead instead of charging in allows more opportunities for code economy.
The Code Economy Mindset
A huge part of writing less code is maintaining a direct, economical mindset.
Optimize code for correctness, simplicity, and brevity.
Don’t depend on assumptions that aren’t contained in the code, and never use three lines where one is just as readable and effective.
Make consistent style choices that are easy to understand. Avoid “run on coding sentences” by breaking different thoughts and concepts into separate LoC.
Only add code that will be used now, too.
There’s a tendency to try and prepare for the future by guessing what might be needed and adding in the foundations of those tools.
It seems like a smart approach, but in practice it causes problems, mainly:
Abstracting is another practice that should only be done according to present need. Do not abstract for the future.
Along these same lines, don’t add in comments or TODOs.
This messy habit encourages sloppy code that can’t be understood on its own.
Comments are more easily accessed when placed where everyone can read them using inline documentation.
Reusable code is a major asset, but make sure it’s fully understood instead of blindly copying and pasting to save time.
Try to choose options that follow good code economy guidelines.
Finally, don’t rush through development with the idea of refactoring later on.
The assumption that refactoring is “inevitable” leads to software that already needs work at launch.
It is possible to create a solid product with low technical debt by writing clean, concise code up front.
Keep A Hand on The Reins
Most importantly, don’t go too far by trying to use the absolute minimum LoC over more practical concerns.
As discussed earlier, a developer’s job is to solve problems.
When minimalist code is forced to override other needs, it becomes part of the problem instead of a solution.
Writing less code helps our developers create technology-based enterprise solutions with a long shelf life.
Set up a free consultation to find out how we can solve your company’s most urgent business problems!