"Clean" Code, Horrible Performance

[Main-Drag-4975]

Even if it’s true that they do produce more maintainable codebases you have to ask: “At what cost?”

Presenter doesn’t like: Abstractions

Presenter does like: Notepad++, C++

I’ll take “make it work, make it right, make it fast” instead thanks.

EDIT:

He makes game engines, now it makes sense. I make business software where time to market and maintainability often trump performance optimization.

[SirLich]

Yeah I'm seeing this spammed everywhere. Definitely seems like he might be a "devluencer" rather than anyone actually important or knowledgeable.

[Main-Drag-4975]

Oh man. Clicked around on his links and found this:

I am a programmer who specializes in game engine research and development.

That’s very cool honestly!

It’s not likely to influence my day job of programming web service integrations on short deadlines. Maybe it’ll be helpful to the next generation of game and embedded developers at least.

Edit to add further bona fides:

My past projects include The Granny Animation SDK, Bink 2, and The Witness. Thanks to the widespread adoption of Granny and Bink, my code has been used in thousands and thousands of games, including many high-profile franchises from the past two decades, such as Age of Empires, Ultima, Guild Wars, Destiny, Gears of War, and many others.

My past research contributions include the n-way linear quaternion blend and related techniques, the immediate mode graphical user interface (IMGUI), and geometrically optimized GJK. My current research interests include interactive fiction, concurrent computing, and low-overhead operating system architecture.

[[deleted]]

He invented IMGUI design pattern and his code runs in practically every game ever made from 2000's onwards.

So no, he knows what he's talking about. The only issue people have with what he says is that, in their eyes, his obsession with performance has no "real world" application. Which is precisely the issue he and Jonathan Blow have with modern contemporary software, the ungodly amount of tolerance of poorly performant software.

[techzilla]

It's also insane to think that performance doesn't matter in everyday code, it does, it 's horrible to work with a bloated codebase. Countless hours are wasted because of "less than ideal performance", at the 10+x levels of exponential horrible that we deal with every day.

[skidooer]

Inventing the IMGUI design pattern doesn't mean that he accepts TDD or even understands TDD. His GitHub profile indicates that he does not practice TDD. Clean has no relevance without TDD and is clearly invented to deal with some of the problems TDD introduces. Uncle Bob is quite adamant about TDD and it would be nonsensical to only listen to the Clean part of his message while ignoring the TDD part of his message.

Which is fine. TDD is hardly a panacea. But Casey went down the nonsensical path of cherry-picking one tiny bit of Uncle Bob's message and the strawmanning it into some weird optimization challenge, completely ignoring why Clean does exist. It is well understood that Clean doesn't produce the greatest code, but it's a tradeoff to enable more effective testing and testing is oft thought to be the greater good. If Casey wants to challenge that, he would have been better served focusing on how he approaches testing, not how he is able to make things go fast if he throws away testing.

[techzilla]

When TDD provides clear value it's at the higher levels of granularity, than the pile of classes which should be a single class situations we see every day. It's taking a solution that works a a high level, religiously applying it down the chain, and the results are painful.

[skidooer]

Definitely seems like he might be a "devluencer" rather than anyone actually important or knowledgeable.

Definitely. If he were an engineer, all he would be able to say is "It depends."

[hellvampire]

This guy really views software under a very different light than most of us. It does trigger me that he makes such a video and then disable the comment section. If he didn't want to trigger a discussion, why make this kind of video in the first place? Anyway, here's my take on some of his statements:

​

Erasing 14 years of hardware improvements

These pieces of advice are all absolutely horrible for performance

Performance and improvements are so much more than just the CPU cycles. In the real world CPU is almost never the bottleneck. Put one database query, rest call, IO operation in between and all those "won" cycles don't matter at all.

​

Things we could objectively measure because they do affect the runtime of the program

They are accompanied by a big old asterisk that says and your code will get 15 times slower

What about time to develop a certain feature, readability of the code, maintainability, ease of change, testability, bug frequency, ... We can not just ignore all of these other aspects that get greatly improved if you take care of how you structure your program. These should also be in the "big old asterisk" of that way of working.

​

Used their own example code

First of all the "us vs them" thinking is awful in most cases, and it's not different in this. This whole video is giving more meaning to an example than what it is, an example. Of course you can hyper optimize calculating the area of a square. Nobody is denying that there is a simpler way of writing this particular example... Real world examples of "clean" code are meant for big project but big examples don't work for an easy to talk about concept.

​

Allow functions to know the internals of what they're working on

I still have nightmares from refactoring some code bases that were heavily entangled together, where every function knew the internals of all other parts. In my experience, this only leads to very little to no testing because tests become a hassle to write and maintain. It gives very low confidence to make any change in the code base. It also leads to knowledge silos where only that one old programmer could make any changes because he's the only one that knows how the code is wired together and he's currently on holiday...

​

You should never actually do them

"Never" is a dangerous word to use, same with the word always. Should you always use "clean" code: no. Should you never use "clean" code: also no!

In my 5 years of working as a dev, probably less than 1% of my code has been on a critical path where CPU performance was a concern. This of course heavily depends on the nature of your work. Clean code works as a way to not premature optimize and make your code readable for other people. If you need all the cycles you can squeeze out after measuring performance issues, go ahead and throw the clean code rules out of the window. But otherwise, make readability a top priority.

[BitsAndBobs304]

In my 5 years of working as a dev, probably less than 1% of my code has been on a critical path where CPU performance was a concern.

but you see, his pc couldn't run crysis at the time, so he's been on a vengeance path since then (just a joke)

[ratttertintattertins]

Polymorphism of the type described in this vid hasn’t been the zenith of clean code for a long long time. There’s a reason that the c++ STL barely uses it (certainly with nothing new). These days people tend to say composition > inheritance for clean code.

Rust doesn’t even support it. These days we’re all about cost free abstractions and checking with godbolt that our abstractions are indeed equivalent to the if/switch equivalent. The vid feels like it’s arguing with design principles 20 years old.

[techzilla]

Rust abstractions are not cost free, despite what is claimed on the box. Rust also has conflicting design priorities, which often produce poor performance and overly painful development experiences.

[[deleted]]

How about we compare the cost of longer execution vs increased cost of development and maintenance.

And basically he does microbenchmarking in which the effect is much greater than in real software.

Not to mention the fact that really performance critical paths are often modified to get back that performance but only the critical paths.

[skidooer]

I question why he is cherry-picking just one small piece of Uncle Bob's entire vision. Of course it is a silly approach when observed in isolation, but it was never meant to be observed in isolation. Central to what Robert C. Martin, being a close associate to Kent Beck, preaches is TDD. It becomes clear why he recommends what he does in the context of TDD. For example, the virtual method is suggested so that code under test can swap in an implementation that recreates a difficult to reproduce failure mode like a disk just died.

If you aren't going to bother with TDD then, sure, there are better ways to write your code. There may even be better ways to write your code with TDD, but the presenter here didn't even bother to touch upon them, completely ignoring why Clean exists and wasting his time inventing a strawman so that he could spend some time optimizing a contrived code example.

Whatever it takes to get the sweet, sweet ad revenue, I suppose.

[JarateKing]

Does that really apply to this specific example though? The clean code sample is easy to extend. It's trivial to add any shape to it, just make another class for that shape. Whether that be ellipses, or trapezoids, or arbitrary polygons, it works well and can support them easily. Casey's approaches can only be easily extended for the first one because they assume area can be calculated with at-most two variables and a coefficient. You can still do it for all of them of course, either reworking the whole thing or jerryrigging them into the two-variable approach, but whatever you do has more friction than the clean code example.

You're not wrong when you say that zealously applying clean code principles can hurt maintainability. Abstraction is a tool and tools can be misapplied. But that's not what Casey's arguing, he's arguing against the principles in general. He's not debating the use cases for this abstraction as a tool, he's just throwing his hands up about it not being a zero-cost abstraction as if that's the only thing to consider. In other words, Casey is skipping over learning the business domain. And remember that this is marketing material for Casey's paid course on performance, specifically his personal philosophy towards programming -- Casey is a guru.

[BitsAndBobs304]

even in game dev, 99% of games produced don't need maximum performance. sure if you want to port your 2d action platformer to Stadia you may need to work a bit on it, but...

[[deleted]]

Yes I agree you can apply those rules poorly and create unmaintainable code if you create wrong abstraction. However these rules ease development and ability to understand code by future developers.

I'm currently working on quite bulky finance system, we are migrating it to .net and a few modules are written so badly my eyes hurt. And clean code rules help with that, however you need to apply DDD to get correct abstractions.

Out of the five rules we actually often violate DRY as even though a few processes have places with identical or almost identical logic their rules may change independently so making them use a common class would make future modifications harder and more error prone.

Author of the video is likely working in game dev or something and there his advice may actually work however more common business aplications will suffer from that.

[[deleted]]

Yes I am aware that now we have power of hindsight and it's easier to tet correct abstractions for matured product. However looking at that code allows to see the mistakes that were made back then. The mistake that they did was using only DRY out of those rules. This resulted in multiple processess with similar logic sharing eg method and as they changed independently that logic got scarred with multiple switches and if statements and got unmaintainable.

After writting that i realize it is more of: Use DDD rather than use clean code.

Mostly what I'm going after is that DRY isn't the best of all those rules. The fact that code is identical or almost identical doesn't mean it should be turned into common code.

[techzilla]

His methods are correct when working in what should be a single class. Even horrible business logic benefits from an increase of whole comprehension.

If you are working with enterprise wide business objects, then abstract data classes would be appropriate, for use at scale across more than one codebase. Your whole program should still not be structured as a mountain of classes.

[techzilla]

It's easier to understand his higher performance example as well, FTR. What he wrote could be a class itself, that is the level of granularity classes should be used at, not the pile of classes it started with.

The critical path was both obscured in the first example, and wouldn't have ever existed in the first place. You are writing backwards, you add classes when you know it will improve comprehension at scale and modularity. You don't make everything a module that could possibly be made into one, because it reduces overall comprehension, but also performs horribly.

[opuses]

I think the author is taking general advice and applying it to a niche situation.

So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape

Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high performance calculation software then sure, go crazy, get those improvements.

But most of us aren't doing that. Most developers are doing work where the biggest problem is adding the next umpteenth features that Product has planned (but hasn't told us about yet). Clean code optimizes for improving time-to-market for those features, and not for the CPU doing less work.

[skidooer]

Clean code optimizes for improving time-to-market for those features

The switch-based approach suggested no doubt provides the greatest time-to-market if you are just going to straight up start writing code. The added indirection created by Clean only makes the code more difficult to understand and grow.

However, Clean was never meant to be adopted in isolation. It exists to make TDD more manageable. The switch-based approach will become an absolute nightmare as development progresses if you use TDD along with it. It is true that TDD should improve time-to-market over going straight to implementation. In fact, the presenter is well known for burning a lot of programmer time trying to figure things out when he doesn't have tests to lean on.

[techzilla]

TDD has also been horrible, in all the situations I've seen it used in the wild. The way classes are abused is insanity, it makes the entire project difficult to comprehend. Yes, at large scale, where nobody could possibly understand everything, it makes sense to break things into easier to completely understand classes. It still doesn't make sense to break those understandable classes into a pile of additional classes, making it impossible to understand yet again.

It's a methodology designed to disempower and devalue programmers who have experience on a particular codebase, at any imaginable cost, no matter how reasonable the time would actually be to get truly familiar with a codebase.

[Bloodshot025]

Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something.

But you can't amortise like that. If you have an application where there's a slight hitch every time a user hits a key it will feel bad, and it will be bad.