“Clean” code, horrible performance

Fun fact. Software you routinely use, like Linux and Postgres, is written in the same "spaghetti" style. I guess the Clean Code people who implement CRUD features for a living are better programmers than the ones writing operating systems and databases.

> Most of us work in an environment where surprising - even astonishing - customer requirements are often discovered during development and maintenance.

Another fun fact. The author of the video works in an environment where rapid iteration is absolutely vital. I'd pay good money to see a TV show where his style of programming ("spaghetti", as you claim) run laps around your "Clean Code". Because it would. For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code (I assume they also have many Clean Code people, and that it would take them about 6 months to write a terminal emulator from scratch).

The reason why this video mentions performance is probably because 1) the author has a course on performance and 2) it's something you can objectively measure.

If it were me, I'd not even bring performance into discussion, I'd just say that "Clean Code" significantly hurts readability and editability (and thus maintenance). But then you jump in to say that the non-Clean Code version is "an unmaintainable mess", and then we go around in circles. Which is probably why performance is his main point.

I'd even go so far as to say that "clean" code is a requirement for performance optimization. For a loose definition of clean.

Code that is unreadable, tightly coupled, untestable or just messy is much, much harder to work in than code that is readable, loosely coupled, well-tested and clean. This has been proven often and is really a no-brainer. Performance-optimizing is finding the bottleneck, then rewriting that without changing the functional behaviour. For this you need resp. readability (to find bottlenecks you must be able to understand flow and code), ability to rewrite (tightly coupled code cannot be rewritten in isolation) and insurance the behaviour doesn't change (test coverage).

Ergo: a clean archictecture is a requirement to make code more performant in the first place. Even if that architecture is bad for performance in itself, it enables future improvements.

The author of the video is apparently referring to Uncle Bob’s first book (Clean code, 2009), which essentially says that “Clean” code is “understandable” code: created with care, thinking about the next reader.

So yeah, the book then goes on for a painful 450 page ramble, opinions, and admittedly arbitrary rules. But Martin was at least partially aware of this:

> “Clean code is not written by following a set of rules” — quote from the book!

So really, the person in the video failed to apply the Principle of Charity, which is fundamental in critical thinking. They end up not addressing the interesting claim, and openly attacking a Straw Man.

As for the deeper points implied in the video, they seem –ironically– less fresh:

- Software is slow these days - Performance matters - The way you write code impacts performance - Don't blindly follow rules and generic advice

Groundbreaking!

If anything, the video shows the failures of C++ as a language. Why aren't languages designed to promote maintainability without sacrificing performance? :Rust enters the room:

The more interesting claim that the video's author missed:

> “It is not enough for code to work.” ― quote from the book

Lynx on the C64 -- Is more nostalgia possible?

This is precisely the kind of situation where it's imperative to consider performance before starting to build a new system.

When you hit Amdahl's law, it's because you (or someone else) has made decisions about the high level design/patterns to use in a system. To remove such bottlenecks, you may have to scrap the entire project and start over.

For the inner loops, it's perfectly fine to leave most of the optimization for later. But for overall design, it needs to be right from the start.

Time and time again, I see devs stuck in some paradigm (often front-end devs or low volumen RESTful microservices) that makes it almost impossible to handle non-trival data volumes or traffic, causing new products to fail.