Embracing clean code involves delicately balancing these principles to the advantage of readability and scalability, without crippling yourself with obsessive adherence. With practice, striking that balance will become second nature.

I wish that paragraph started the article because there are several things I just can't agree with here.

Agreed that clean code, like all suggestions regarding "best practices" is contextual and your mileage may vary. Clearly creating a thousand classes that each have a few lines of code is not maintainable unless there is a compelling reason to break these functions into classes and not methods. Moreover, the problem of the proliferation of separate methods, functions and classes should be handled by an extensible documentation system that forces developers to document the purpose, signatures and use cases for that code. Without a map it's almost impossible to find anything when you've robotically followed the SRP.

In essence however, I disagree that the DRY principle leads to maintainability problems. In fact I think it enhances maintainability by isolating code that is used in multiple places to a single location that can be more easily monitored and changed if required. And here's another thing I have found writing software for over four decades.

There is no such thing as throw-away code.

Hyperbolic? Yes. But more true than false.

Unfortunately, cut 'n paste developers seem to be the industry standard these days as they copy pasta bugs into multiple hidden locations. Would you rather have a 100 landmines in your field or one single bomb?

And functions called just once, encapsulated in their own, well named unit of code is gold in my opinion (can we agree to simply ignore the developers that have swallowed the whole bottle of aspirin and write functions like addTwoNumbers()?).

I have too often in my career encountered the "hairy ball of wax", especially in legacy code . In all of those situations the issues of maintainability turn out to be more of an organization problem than anything else. The hardest part of deciphering this mess is usually not the code itself. The code is often easily understood, enhanced and patched. The problem is finding the offending class, method or function that needs to be changed. These "hairy balls of wax" are characterized by scant documentation of methods and classes, redundant code because of a lack of documentation, lack of any telemetry and a bulk of code that makes finding where something is done becomes nearly impossible. It is often the case that a fix to legacy code is a one or two line change preceded by a day of hunting down the offending lines.

If developers started first by creating a roadmap and updating that map religiously, maintaining legacy code would be much easier.

Clean code principles are only part of the story - we need better ways of documenting the organizational structure of the software implementation not just the design or architecture of the system. At minimum to create a maintainable application you need three categories of documentation. An application design document, an application implementation roadmap and an infrastructure implementation diagram.

Identification of (and perhaps documentation of) methods and functions is required before you can create an implementation map.

"Clean code extends to not leaving behind comments. Every code analyzer will advocate documenting your classes, methods, and fields, but ironically, the clean code principle suggests otherwise. This conflict within the ideology is problematic."

Documenting lines of code is different from documenting signatures, purpose and possible exceptions. Lines of code typically document themselves because much of the code written is manipulating data in expected ways using common idioms and techniques. You don't need to tell someone you are performing these things...but you do need to document why sometimes.

Good article for creating a discussion, however I disagree with some of the perceived objections to writing clean code. I would have liked to have seem more ways to mitigate problems that were identified.