When Clean Code is Harmful; Live Stream Tomorrow, Book Club
No such thing as a Clean Code Project Stamp
4 more days to to join the CTT Book Club. We’ll be reading “The Fearless Organization” to cover the topics: Apply Psychological Safety learnings with your team, learn speed reading, have fun. Reply or DM me FEARLESS to join.
Controversial topic for today’s issue. Engineers often strive for clean, elegant code to improve maintainability and readability. But is there a flip side to this pursuit of perfection? Let's explore when an obsession with clean code might not always be beneficial and how to strike the right balance between cleanliness and practicality. Join me for a live stream tomorrow, and don't forget to bring your insights and questions for a lively discussion!
Purity From the Start Leads to Paralysis
Clean Code is generally considered a hallmark of good software development practices. However, it's essential to recognize that a dogmatic pursuit of cleanliness can lead to challenges. When following individual, rigid instructions from clean code principles, you may find your team spending excessive time refactoring code that doesn't directly impact functionality.
Sometimes it impacts functionality but not along critical, revenue-enabling features.
This can lead to missed deadlines and delayed project deliveries, affecting business goals. You don’t want your team’s focus to stray so easily.
Clean Code can also be harmful when it becomes a source of frustration for the development team. If team members feel pressured to adhere to rigid standards, they may become hesitant to experiment and innovate, stifling creativity.
Additionally, focusing solely on clean code metrics can create an environment of code shaming, where developers feel embarrassed to share their work openly. I recommend a more open approach and incorporate feedback into the system via automated reviews.
What makes standards rigid?
☒ Bad Examples
Enforcing strict 100% coverage mandates
Following silly, manual style guides rather than automatic it
Mandating SOLID and DRY principles without context
Taking away freedom from pairing and collaboration, spending too much time on isolated, pedantic code reviews
Enforcing pre-commit or pre-merge hooks
Refactoring after someone, usually following a merge you disagree with
☑️ Good Examples
Augmenting PRs with comments from code health tools like Codescene and Sonarqube
Using style and architecture linting tools
Communicating clearly which features are revenue-enabling or part of critical infrastructure, prioritising them for quality and refactoring
Refactoring as a team activity on ensembles or pairing
Software Design, Quality through Refactoring
I’m confident in the one area Clean Code shines is the Boy Scout rule—”Leave the campground cleaner than you found it.”
I wish engineering teams adopted this approach more generally. This should be taught in school for managing legacy code professionally.
It follows a simple procedure:
As you are about to change legacy code, determine where the change will be made
Clean up any code smells at the point of change before adding any new functionality
Refactor to accommodate any shifts in design
If necessary, adjust the refactored code with a new seam (e.g. abstraction, interface). This will make the new feature easy to add and test.
Lastly, add the new functionality
💬 Join the Conversation
I'm eager to hear your thoughts everything we discussed to far on CTT!
What are your experiences with clean code
Have you encountered situations where it became detrimental?
Have you found effective ways to maintain code quality without compromising productivity?
How is your team planning refactoring?
Are you gradually increasing quality on revenue-driving features?
Do your team and colleagues speak up candidly when the team makes a mistake?
Let's learn from each other and take our coding practices to new heights! Comment below with your thoughts, and I'll see you all in the live stream Thursday, Jul27th at 5pm CEST. 🚀👨💻
During this interactive session, I'll share real-life examples and experiences from my own career, and I encourage you all to contribute your insights and stories.
Let's engage in an open and honest discussion about the challenges and benefits of clean code. Come explore practical solutions to strike the right balance. Mark your calendars and invite your colleagues to join the conversation!