Clean Code is important for developers and managers.
Last week in our post about the difference between programmers and engineers, we made the argument that software engineers – not programmers – are what we need to deliver high quality software. We also said that Clean Code is a key quality differentiating the former from the latter. Today we’ll focus on three reasons why Clean Code is so important for both developers and management.
1. Clean Code delivers better software faster
“The only way to make the deadline – the only way to go fast – is to keep the code as clean as possible at all times.”
– Robert C. Martin: Clean Code
Quickly bringing product to market is often the only way a project can survive and remain relevant. Starting a project fast is rarely a problem; it’s finishing fast that’s hard. Clean Code is how we finish fast.
Software development is the art of managing change, which comes in one of two forms:
- Delivering new features
- Fixing bugs
Software changes are not so much dependent upon writing new code as understanding the code that already exists. In other words, we read code much more than we write it. If we misunderstand the code that already exists, then we are very likely to create more work for ourselves in the form of bugs that will need fixing later, or by adding unnecessary complexity.
Therefore, the faster we can read and understand the code we have, the faster we can affect change, and the faster we can deliver value. Clean Code’s primary focus on code readability leads us to delivering software faster not just at the start, but throughout a project’s life-cycle.
2. Clean Code costs less
“80% of what we do is maintenance”
– James O. Coplien
Limiting maintenance costs is the key to lowering the cost of a software project. A focus on speed without attention to maintenance leads us to a place where changes are difficult and introduce bugs. Clean Code treats maintenance as a key concern and helps us in two ways:
- It is readable
- It is testable
When we talked about Speed we discussed how readability allows us to affect change (e.g., fix bugs) faster. Time is money, so it’s no surprise it shows up here too.
Tests meanwhile are absolutely critical to reducing maintenance costs. Numerous studies (another example) meanwhile show the sooner we catch a bug the less it costs. Having a comprehensive test suite is one of the best ways of ensuring you catch bugs as soon as possible.
So how does Clean Code fit in with testing?
Clean Code emphasizes breaking an application down into as small of pieces as possible. With unit testing, we’re encouraged to test pieces individually. Smaller pieces mean each piece has less functionality to test. Less functionality typically leads to easier tests to write. Many developers don’t find writing tests to be a highlight of their duties. So the easier it is to write tests, the more likely it will actually happen.
3. Clean Code gives the team confidence
Too many teams live in fear of some portions of their application. None dare make any changes to it – due to the complexity (and typically lack of tests) in those portions. Often some unlucky developer is handed the role of maintainer for these portions with the intention of limiting the cost of maintaining that code. Such an approach is shortsighted and has severe ramifications for the project’s success.
The maintainer lacks confidence because no one can provide feedback on their work since no one actually understands this part of the application.
Management loses confidence because the schedule is held hostage by the availability of the maintainer. If the maintainer is sick or on vacation, entire features may slip; if the maintainer grows unhappy and decides to leave, the entire project could be in jeopardy.
With Clean Code, any engineer should be confident working with any part of the application.
I saw first hand how impactful this can be.
A former project had just hired a new software engineer to fill in for a departing teammate. Within the first week of joining, that engineer had made changes to the very core of the business logic powering our application. There was literally nothing more central to our application this engineer could have modified, and yet, both he and the team were confident.
Why?
- We stressed Clean Code practices in our hiring and onboarding process; we knew we were all on the same page.
- The engineer found he could understand the Clean Code he was modifying quickly.
- Clean Code drove us to have a comprehensive test suite such that we could catch problems right away before they hit the users.
- Clean Code meant the engineer could get feedback from anyone on the team.
The confidence Clean Code gave us led to a fun, flexible work environment that encouraged communication and contribution.
What next?
Today we’ve discussed why Clean Code is important for both developers and management. We hope you can relate to the motivations described above. Stay tuned next week where we will delve more into specific Clean Code practices you can put to use right away.
Read the Other Parts of the Clean Code Series:
- Part 1: The Difference Between Programmers and Software Engineers
- Part 2: Why Clean Code is Important for Developers and Management
- Part 3: 4 Clean Code Naming Principles Every Developer Needs to Know
- Part 4: What Every Software Engineer Ought to Know about Functions
- Part 5: Does Testing Really Make You Go Faster?
- Part 6: Teamwork Makes Clean Code Work