16 ms·

“Clean Code, Horrible Performance” Discussion

223 points by rinesh 4y ago

geenew 4y ago
"constrained problem within a resource constrained environment" is a good phrasing
kamikaz1k 4y ago
this was a very amicable and fruitful discussion it's been chaffing me a lot last couple of years that it is so hard to learn about making performant code. It was nice of Julia Evans to write that very approachable strace zine [1]. I wished there was more of that kind of stuff. So I am happy Casey is doing a whole course on this stuff [2]. [1] https://wizardzines.com/zines/strace/ https://wizardzines.com/zines/strace/ [2] https://www.computerenhance.com/p/performance-aware-programming-series https://www.computerenhance.com/p/performance-aware-programm...
- blt 4y ago
  Check out Mike Acton's work also.
taneq 4y ago
Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.
- nayuki 4y ago
  It's true. It's easier to make mathematical connections with algebra, combinatorics, etc. when you're reading short formulas and not being not knee-deep in hand-written SSE asm.
- thethirdone 4y ago
  From: https://www.computerenhance.com/p/clean-code-horrible-performance https://www.computerenhance.com/p/clean-code-horrible-perfor... > The speed differences range from 20-25x — and of course, none of the AVX-optimized code uses anything remotely like “clean” code principles. If clean code limits your default performance to 20 times worse, those high level optimizations might not even be worth it.
  - microtherion 4y ago
    The point is, without a reasonably clean starting point, you'll never get to apply those 20-25x optimizations in code bases beyond a certain size, because they've become a wasteland of mediocre micro-optimizations before you even get started. So the sensible thing to do is to identify a component of manageable size, fence it off with suitable abstraction boundaries, and then apply optimizations WITHIN the confines of that component only.
  - taneq 4y ago
    If your performance-critical code is 25x slower than it could be, while using the same algorithm, it’s not “clean”, it’s just bad.
wokwokwok 4y ago
Some gems from the discussion… > Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.” > You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is probably for the same reason that your video was solely focussed on the amplification of performance to the strident denigration of every other concern. To a performance hammer, everything looks like a nail. ;-) Overall a very amicable and interesting read. It’s so easy to preach high level architecture without specifics, but also so very easy to cherry-pick a specific example where generic advice doesn’t apply. I think it’s interesting that there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” …and I’m absolutely 100% with Uncle Bob that bounded contexts for complex code is the solution. This is the approach rust takes with unsafe code and it has proved to be an extremely effective principle.
- slavik81 4y ago
  > there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” In my experience, poor performance is often because the code is needlessly complex and does unnecessary work. In that case, there's no trade-off. You can both improve performance and readability by simplifying. There may be trade-offs required to optimize for the absolute maximum performance, but you can get most of the way there without sacrificing anything. The vast majority of programs are nowhere near the pareto frontier between performance and readability.
burlesona 4y ago
I’m surprised that such a thoughtful and civil conversation came out of this after the precipitating screed against Clean Code. Kudos to both sides for engaging constructively!
Barrin92 4y ago
The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so much of his advice from his experience on game engines, which are an incredibly forgiving domain in many ways. You can have some bugs, you can drop some things over the network, it doesn't matter much. But you can't really do that in many other applications. If you had a big codebase for an application that is safety critical, going at it with his style of low-level programming you might make some very costly mistakes really quickly.
- kamikaz1k 4y ago
  Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code. (I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)
  - Barrin92 4y ago
    No need to make assumptions given that they dug into that issue and the problem was algorithmic. As Bob points out that's orthogonal to clean code ideas. If you chose the wrong datastructure or algorithm and have quadratic complexity all the micro-optimizations in the world aren't going to help you. The only strawman honestly is to pick someone at github writing shoddy code and then using that to argue against system architecture? It's pretty obvious that a text editor lagging on a paragraph of text isn't the consequnce of having wrapped something in a function. If you've written code slower than a human you don't have clean code, you just have bad code.
- oreally 4y ago
  I wouldn't go down that line. There is code that makes you -think- it's safer but all it really does is add more needless complexity. It's one of those things where the 'safety' result hasn't really been given a good measurement.
pkolaczk 4y ago
It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears. IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed. And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.
- Apocryphon 4y ago
  Clean Code led to the development of the VIPER framework, which is a crime it must answer for.
  - fulafel 4y ago
    I thought about https://github.com/viper-framework/viper https://github.com/viper-framework/viper first, but I guess you mean https://github.com/topics/viper-architecture https://github.com/topics/viper-architecture
  - FlyingSnake 4y ago
    True. VIPER was the craziest thing I had to deal with when I developed iOS.
- robalni 4y ago
  I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.
nayuki 4y ago
At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem. As an addendum to Casey's video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD/vectorization. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.
- brtkdotse 4y ago
  > At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I fully agree that human comprehension should be a prime objective for code. Alas, following the tenets of “Clean Code” produces anything but that.
  - xjay 4y ago
    I know that the original "MVC guy" and "Bob's nemesis" :^) have been looking into making human comprehension the main goal of a new programming language, "trygve", named after Trygve Reenskaug (MVC). https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction
- thethirdone 4y ago
  I don't think Casey would object to "optimizing for human comprehension". If you are willing to give up an order of magnitude of performance, you can probably just do it without much care. I agree that "optimizing for human comprehension" is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don't think that guidelines like "clean code" actually are particularly effective at making understandable code. My personal guideline is to prefer code which is "simple" for both humans and computers. > So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it. I hold the controversial opinion that Knuth's advice is not relevant to most modern programmers. Most modern programmers have never done the "optimization" that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won't be significant hotspots. Everything will be lukewarm.
dang 4y ago
Recent and related: “Clean” code, horrible performance - https://news.ycombinator.com/item?id=34966137 https://news.ycombinator.com/item?id=34966137 - Feb 2023 (906 comments)
the_gipsy 4y ago
> preferring inheritance hierarchies to if/switch statements, And then he goes on touting readability right after that. Bold.
noisy_boy 4y ago
This exchange was more enjoyable than I anticipated it to be. > I created this with vi and used 1,$s/ /:/g > Because, I really am an old C hacker at heart. %s/ /:/g would have been shorter.
kilgnad 4y ago
Here's another controversial opinion: It's the genius programmers who write the shittiest code. In my experience clean code tends to be a waste of time for geniuses because shitty code isn't really a problem for smarter people. The further away you are from genius the greater the tendency for you to write cleaner code because you need it in order to deal with the complexity. What's common among HN readers is that they think they're smart. So you may be reading this and thinking "Wait a minute, this isn't true! I'm smart and I like clean code!". Well, I hate to break it to you. The truth hurts because most likely one of those two attributes probably doesn't actually describe you. Also as a side mention, I'm a clean code Nazi. My code is really clean.
- anchochilis 4y ago
  This was funny. But I've seen too much clean code written by people smarter than me to agree. I actually think how "clean" your code is depends on lots of factors. Eg. (a) Do you care if your coworkers find it easy to modify your code? (b) Do you feel a sense of ownership over the code you're touching? (c) Does your organization reward delivery speed without any checks for code quality? (eg. no culture of code review) (d) Is the code a proof-of-concept that needs validation from users before further investment?
  - kilgnad 4y ago
    You're not dealing with the geniuses. You're likely just dealing with people smarter than you. I can assure you geniuses are rare, and people of the same intelligence level tend to gather so you can go through a career completely missing them depending on where you work. There's enough noise such that among these groups you won't notice the correlation. Tbh the geniuses don't view their own code as shitty, to them it's quality. It's only viewed as shitty externally.
- dsego 4y ago
  I've come to the same conclusion, really smart people who write compilers, name their variables one single letter and the like (the extreme variant) etc., they can actually see the matrix beyond the funny characters on the screen, they have the capacity and attention to understand the messy bits without having to make it neat, those three nested for-loops inside multiple conditionals don't bother them, they can quickly visually parse difficult code without refactoring and sectioning it off. On the opposite side, there some like me who are deficient in that regard, so I spend my time pimping my code to look nice, nit-picking on syntax style, eliminating else-clauses, trivial stuff like that.
drewcoo 4y ago
[flagged]
drewcoo 4y ago
[flagged]
userbinator 4y ago
All the concentration on "developer productivity" has lead to a massive loss of user productivity and wasted energy. Ironically, a lot of developers are also users, so they suffer just the same. The worst part is, AFAIK it's not even clear that the recommendations in Clean Code are better for developer productivity, insofar as they create excessive complexity. Another thing to note is that I've observed a significant fraction of users (and developers!) seem to have a very poor perception of time. You can replace an app they were using with one that is otherwise exactly the same but introduces a whole second of delay when interacting with the UI, and they wouldn't notice unless you gave them the two versions to compare side-by-side. Of course another significant fraction does notice, which is why you often see both "this new version is horribly slow" and "works fine for me, it doesn't feel any slower" opinions.
randoglando 4y ago
I found it interesting how concrete Casey gets, and how he quickly identified the cause of the UI bug (+ a mitigation). Meanwhile, it looks like Bob was speculating in thin air and throwing out random terms (O(n^2)) trying to fit in.
- comex 4y ago
  But Bob was right that the problem was algorithmic. Checking whether a string ends with a prefix of an emoji abbreviation is a task that could easily be done in a microsecond. It’s apparently taking 100 milliseconds, which is 100,000 times slower. Even factoring in the overhead of JavaScript, you could easily add a 10x or 100x “clean code” penalty and still be nowhere near the level where it’s a performance problem – if the algorithm is correct. By “algorithm” I’m referring to more than just asymptotic complexity. Even so, as for “O(n^2)”… well, I didn’t analyze the code myself, but judging by Casey’s analysis (or even just by the symptoms), it seems quite likely that the time taken to input a character is at least O(n) in the number of characters entered so far (if not worse). That makes the total operation of entering n characters take O(n^2) time. Bob does seem to be referring to the total being O(n^2) rather than each character being O(n^2), since the reallocation strategy he mentioned as an example would similarly take O(n) per character. In that context, O(n^2) is less of a guess, more of a reasonable assumption given the observed performance characteristics. And it’s a reasonable aspect to point a finger at, because lowering the asymptotic complexity would be an essential part of fixing the performance problem. Not sufficient by itself, but pretty much necessary.
teo_zero 4y ago
> It is economically better for most organizations to conserve programmer cycles than computer cycles This is only true if "organizations" here means those which write the program. If you include those who actually use the program, I don't see how this sentence could be proved.
Aperocky 4y ago
Simple > Complex. Every extra year I spend in engineering, it's becoming clear that this is actually one of the only few things that mattered in the long run. I would say this is one of the best if not the best advice in programming and even in life. If clean code doesn't follow that, ditch.
- LaLaLand122 4y ago
  What you say makes a lot of sense. Now, to give a concrete example. There was a C++ PR introducing an interface taking an argument of type int representing a duration. I suggested using std::chrono::duration (https://en.cppreference.com/w/cpp/chrono/duration https://en.cppreference.com/w/cpp/chrono/duration), and I was overruled on the basis that "an int is simpler". To have context if you are not too familiar with C++: - std::chrono::duration is part of the C++ standard library - It's a wrapper on top of an arithmetic type just giving it "duration" meaning. It's of the same size as the wrapped arithmetic type. - Yes, you can argue it's more complex since it adds a bunch of templated code on top of a language built-in type. I'm going to guess that's not what you had in mind with your "Simple > Complex" advise. If so, that's what happens with any advice, even with simple one liners: somebody will take it to justify some crazy decision.
  - Aperocky 4y ago
    Simple vs Complex should always be evaluated holistically. Each file could be simple but if they are in 5 level of inheritance, then it's not simple as a whole. Same with 10 different way to do the same thing or 3 different class that can be used to the same effect, it's not. Your case is clearly adding complexity as the new class have no reason of existence, as it's just rebuilding part of the standard library which your compiler would likely have included anyways. The suggestion is clearly a bad one but our industry is filled with people who are either incapable of adequately applying "Simple > Complex" or don't believe in it. That's why enteprise FizzBuzz exist.
fwlr 4y ago
The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The reason it doesn’t sit well is that, in practice, it seems like most products don’t know what needs to be fast and so developers end up making almost everything slow. Casey gives many examples but the one that sticks out most in my mind is the Visual Studio watch window (about 25 minutes into https://m.youtube.com/watch?v=GC-0tCy4P1U https://m.youtube.com/watch?v=GC-0tCy4P1U). The watch window lets you pin variables you’re interested in and it will show you their current values as you step through the program’s execution. Invaluable for debugging. Visual Studio’s watch window is incredibly slow, to the point that it actually has a debounce so it will stop updating when you’re stepping quickly and only update once you’ve stopped quick-stepping. This seriously impacts its usefulness! To me, the watch window seems like it’s obviously one of those modules that needs to be running in milliseconds or less - but the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead. So in my mind, “write clean except where performance matters” comes with an almost fatal caveat, something like “you won’t know where performance matters”.
- lazyasciiart 4y ago
  > the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.
  - fwlr 4y ago
    It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.
    - 4y ago
tester756 4y ago
I'm starting to hate programming discussions, after you've read a lot of them they're predictable, boring as hell and you can argue endlessly just because you value a little bit different things. This discussions is yet another, nothing special way of saying: context matters. You have a list of requirements of what you want to achieve, some of them do appear during development and you develop against this. I have completely no idea why "software part of the internet" is losing their shit over those 2 guys arguing since it doesn't seem to be "deeper" than 2 random people arguing in some random comment chain.
- javaunsafe2019 4y ago
  This. Thank you. Also the amount of claims and self confidence in this thread by people not even able to back their claims with examples is hilarious imo.
- ctx_matters 4y ago
  >context matters I've wrote about my observations with the same conclusion https://trolololo.xyz/programming-discussions https://trolololo.xyz/programming-discussions >I've started thinking about it and realized that people arguing on all previously mentioned platforms tend to have various backgrounds >Web developers, desktop developers, system programmers, cloud engineers, people working at startups, people working in corporations, beginners, experienced and known in the industry people, FP/OOP fans, self-taught, people after electrical engineering/computer science/mathematics, and a looot of more. >So, what's the difference? I'd say context and the context is unfortunately lost in those discussions because all you see is just somebody's comment and that's it. Nickname very often doesn't tell you anything (except on forums after you spend some time there) >And they all are right (or may if you want to argue :)), but very often that information about their respective domains is lost and the argument is around some "generic code base" or some "average project" which is different for everybody.
- bsaul 4y ago
  you've probably never worked in an average enterprise java shop. The religious refactoring of any kind of software to its most generic and decoupled design, under the name of "cleanliness", is quite impressive. it's quite important that one of the most well known figure recognize that those designs have costs in terms of performance and are not suitable anywhere.
vmaurin 4y ago
For me it is not concept to oppose. You can write optimized code but still name your variables "first_item" instead of u_fp_64_ptr like I often see in "optimized code"
- tsimionescu 4y ago
  When code needs to be heavily optimized, the fact that some variable is a pointer to a 64bit unsigned floating point number may well be more relevant for understanding the code than the fact that it points to the first item in some list.
  - kaba0 4y ago
    But that is explicitly known by the type, we are not writing 90s era microsoft office (hungarian notation really should not be used).
    - tsimionescu 4y ago
      The name of a variable is supposed to contain the most relevant information someone needs when looking at an expression. If the most relevant information is the type, then that should be name. The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was. Imagine you see some code masking the first 40 bits from the location pointed to by first_item. Does the name "first_item" help you understand why they are doing that, or would it be more useful to know that it is the first forty bits of an u_fp_64, so it's masking the mantissa and just keeping the exponent?
      - dns_snek 4y ago
        > The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was. Doesn't your IDE allow you to effortlessly see the type of a variable, either through inline hints, some sort of keyboard shortcut or at the very least, by hovering your mouse over it? Admittedly I haven't professionally worked in C/C++ since university, but my understanding is that small functions can be (are?) inlined, removing the function call overhead. If that's the case, couldn't you write a 1-line function like "maskMantissa", which would clearly communicate what the code is doing without overhead?
Spiwux 4y ago
I really do not understand why this is a discussion, why a video had to be made about it and why we now need an interview about this. Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of value
- blondin 4y ago
  it did add something of value. uncle bob realized his "clean code" may have done a disservice with regards to performance. but i am not holding my breath on seeing a change come about soon. it is possible to optimize for both performance and developer productivity. but everybody is leaving that out in the discussion.
- martinhath 4y ago
  > Clean code / readable code / whatever you want to call it is often at odds with performance. I disagree; or rather, I'd put it the other way around by saying that often you can get both clean code (by some metric) and reasonable performance. The patterns in e.g. the book by Robert Martin doesn't give you either, though. > And for most enterprise projects it just doesn't matter. It matters for the users. I use software that is slow for no good reason, and I'd like to live in a world where this is not the case.
- weatherlight 4y ago
  Also, I feel, it's a whole lot easier to refactor "clean" or "readable" code for performance than the other way around. Make it run. Make it clean. (and if need be,) Make it fast.
  - animesh 4y ago
    As a dark matter developer, I learnt it as: Make it work Make it right Make it fast My interpretation of this, so far, "make it right", is to make the code and design cleaner and refactor. Then "make it fast" came into the play, iff, there was enough push.
awesome_dude 4y ago
Function calls are expensive, more news at 11
moomoo11 4y ago
Or you know. Have a toolbelt. You keep tools on that belt and you use them as necessary. Making a simple service? It’s in the descriptor. Just keep it simple. Making something large that has a bunch of people working on it? Time to pull out the toolbelt. Making something super mission critical? Use the right tools. No approach is perfect. That’s why you use what makes most sense, mixing and matching, to put together what works best for the task at hand. Anything else is noise and just ignore.
Manjuuu 4y ago
I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind: What have they ever built? Reading code from popular opensource projects and evaluating the different approaches they took is way more useful than reading those books, full of regurgitated wisdom from people with minimal street creed. And yes, maybe it's time to stop calling him "uncle", it's not your uncle, he has very little to teach. Start building, stop reading.
- donatj 4y ago
  I read through a decent chunk of Patterns of Enterprise Application Architecture for class in college in ~2006 and while I was indeed young and impressionable, it left a very bad taste in my mouth for heavily OO’d systems to the extent that it had the opposite effect - I largely avoided them likely longer than I should have.
- Defletter 4y ago
  > What have they ever built? You have to be careful with that though. We've had a few people who'd "channel Torvalds", so to speak, by parroting his opinions with abrasive fervour. Any dissenters were treated as either thinking they knew better than him, or being ignorant of his work, or not having an appropriate appreciation for his work. And since Torvalds is very opinionated, so were they. It wasn’t exactly a fun work environment. I’d also like to challenge the premise of the question. Being a maintainer for example is just as valid as being a “builder.” In fact, you’ll probably gleam more wisdom from being a maintainer than a builder since you are, by definition, trawling through other people’s code and maintaining it. Look, it’s perfectly valid to consider someone’s body of work while considering their opinions. But dismissing them out of hand is wrong, in my opinion.
  - Manjuuu 4y ago
    I agree with everything you said, especially with how important the role of the maintainer is to get something that keeps working over time (both are builders). And yes, holding someone else opinions strongly doesn't make you instantly a clone of Torvalds, thing that in workplaces with n>1 employees might not be desirable.
blondin 4y ago
i find it baffling that uncle bob thinks it's okay for dialog boxes to be sluggish. and that we can throw CPUs and GPUs at most performance problems. because it's "cheap". that way of thinking is part of the problem.
eviks 4y ago
The performance degradations is a clear harm and pervasive. The dev productivity improvements are questionable. So let's go do some harm! (and that example of slow typing in a "big" paragraph is a big red cherry on top of a brown pile!)
liampulles 4y ago
Enterprise Code should be concerned with getting the best "order" of performance (i.e. O(n) over O(n^2)), but beyond that design for brevity and clarity. Architecture wise, the Clean Architecture is a good starting point, I would enforce one or two rules - maybe domain seperation and business logic/driver seperation, but not go more zealous then that.
revskill 4y ago
Rule 1: if it works, refactor it
xjay 4y ago
Hardware may perform more operations per second, but inefficient software remains inefficient, and it's still wasting roughly the same amount of energy as it did on slower hardware, and waste only accumulates, skewing the performance of the rest of the system. That inefficiency gets multiplied by millions or billions of units worldwide that run this software.
blippage 4y ago
The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin. Functions should do only one thing. Sure, but what does that actually /mean/? If a function calls two other functions, then surely, by definition, it's doing two things? So how much a function is doing is a question of how far you stand back when looking at it. Also, if you follow a rule of functions having only 2-4 lines, then you're going to have a lot of functions, and tracing through code paths is going to be like peeling back layers of an onion. So that advice is just wrong. It's not even clear that long functions are a problem. Back in the early 80's my A level computing science teacher, who had worked in industry, said that there was no real evidence to suggest that long functions are less readable. There was a joke going around some time ago about an interviewee who was asked how big a function would be. He said "I like to be able to keep it within my head." When asked to elaborate, he said "I put my head against the screen. If the function is longer than that, then it's too long." Although facetious, I think that's actually a good idea. A function should be at most a screenful, so you can see it complete on the screen. Recently, I wanted to customise my own gopher client. I first messed around with one written in Go, but it was too complicated to adapt for what I wanted. I switched to a C alternative, which was still a bit too complicated. I decided that I'd basically re-write the whole thing in C++, using whatever bits of functionality from the C part that I thought useful. If there is a magic formula to writing good code, then I'd say that the less code you have the better, and try to keep code reasonably decoupled. The problem with writing applications is that there's a tendency to be promiscuous in how you use objects. So, in essence, every part of the program relies on every other part of the program. There's no separability of design. It is better to take a "library" approach to things, where each "module" doesn't know how it is going to be used. You then have co-ordinating functions which stitch this functionality together. The code you end up with should be much easier to adapt. It's also useful not to be overambitious with your project. Someone once said that the genius of Ritchie and Thompson was being able to obtain 90% of the functionality using 10% of the code. If you think parsimoniously in that way, they'll be a lot less code to wade through when you want to modify things.
- roarcher 4y ago
  > The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin. Totally agree. I believe "Uncle" is a pretty ingenious piece of branding meant to paint him as an implicitly trustworthy and wise figure that I should feel endeared to. He's just a guy who has built a career out of offering his opinions on how others should do a job he's never done. Notice that his About page [0] doesn't mention a single piece of software that he's actually built. He reminds me of a company I used to work for. It was a healthcare architecture firm that got sued so many times for their fuckups that they pivoted to being a "thought leader" in their industry. Instead of continuing to build hospitals, they focused on consulting and publishing articles with their innovative [1] ideas about how hospitals should be designed. A classic case of "those who can't do, teach". [0] http://cleancoder.com/files/about.md http://cleancoder.com/files/about.md [1] I shit you not, one of their ideas was a "hover gurney" that was basically a giant quadcopter with a bed on it. It was supposed to be easier to move. Blasting germs all over the hallway with hurricane-force winds was apparently not an issue anyone thought worthy of consideration.
barisx 4y ago
"Clean Code for me the testable code."
Grothendank 4y ago
Reading this conversation is like watching Casey skillfully and lovingly jailbreak Uncle Bob's GPT personality prompt, yielding a new and exciting performance focused alter ego which I admiringly dub "SPEEDY BOB".
tinco 4y ago
It's just an anecdote but I think the emoji picker problem they explored is really what it is about. You can debate all day about whether Bob's clean code principles are valuable but the reality is that no pattern from any of his teaching will ever make a text editor get slow after just 300 typed characters in a single line. I bet I'm Casey's life it happens often that he has to dismantle clean architecture in an application that is already quite fast just to squeeze out some extra performance. But that's not in the same arena of these every day performance annoyances. It's some sort of variant on Amdahl's law. You could have a million lines of fairly performant code, and then in 3 lines someone fucks up and introduces an accidentally quadratic function into an emoji picker and your whole application will feel slow. That's also the take away conclusion from this discussion. After listening to 8 hours of uncle Bob going on about clean code, he should pause and tell you to check over your codes performance when you're done. Since the clean code made you so productive, and your code so readable, it should be an easy thing to quickly check your performance.
readlikeasloth 4y ago
Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.
- eviks 4y ago
  This confusion is easily resolved - just remove "science"
  - bitwize 4y ago
    Indeed. What we do is more akin to computer voodoo. Now let me wave a dead chicken over those server logs...
stuaxo 4y ago
Yeah, not a fan of atomising code into so many classes as Clean Code recommends, the mental load is higher and its a lot harder to see what's happening. And thata before considering the great analysis of the examples in this book from a few years ago, that showed that they don't conform to the clean code philosophy at all. Lucky for me, I bought this and procrastinated so long about reading it, I've since found out it's not good, so I saved some time.
bitwize 4y ago
What Casey doesn't get is that for the vast, vast majority of code out there, reliability, maintainability, scalability (to hundreds of servers, or hundreds of software engineers working on the code base), testability, and observability trump raw performance. CPU and RAM are cheap. By engineering your software to scale performance as close to linearly as possible with the addition of more CPU and RAM, you've changed the problem from one that requires the best engineers to solve into one that can be solved literally by throwing more money at it. At the largest software deployment scales this is totally doable, and it makes the most sense for the business.
- sgarland 4y ago
  You've now pushed the problem to the infra team, thanks. What happens when the spot instance that pops up is a much older generation, and your app suddenly runs far slower due to reduced memory bandwidth, CPU clock speed, etc.?
bayesian_horse 4y ago
The only clean code is the one that does nothing. Otherwise you can only struggle to add as little dirt as possible.
DeathArrow 4y ago
>What’s more, processors are so cheap and available that it is a trivial matter to add more of them to a system. I don't know what Uncle Bob uses but the motherboard in my PC has exactly one CPU socket. And at $600 I wouldn't say it's cheap. I'm not sure how can I add another CPU to my laptop and my mobile phone. Also not all software is multithreaded.
- gs17 4y ago
  To give him the benefit of the doubt, maybe he meant a distributed system? Much easier to add CPUs then.
DeathArrow 4y ago
Long time ago advices like Uncle Bob's seemed good to me. Now I try to use OOP the least I can, I try to use the less abstractions I can and I try to make the CPU use the least number of instructions. I am using a part procedural and part functional approach, keep data separate from functions that process the data, try to use immutable data where possible and minimize state changes. I am trying to use a data oriented approach and I am more happier and productive than if I hade to apply clean code principles and software patterns on top of software patterns.
jmartin2683 4y ago
I shudder to even think of the cumulative ecological cost of Bob's line of thinking, here. Imagine if Henry Ford did this... we'd all be getting 0.3mpg, but hey... productivity!
- globalreset 4y ago
  Imagine software that was delivered 6 months earlier but is 2x slower than it could be. This lead to productivity increase of it's users of 2x during that 6 months. At the expense of some extra electricity use worth $100, they made $10M worth of real world productivity. My point is... the thing that is much worse than software that is unnecessary slow, is the software that was not yet written at all. Now ... I think some of the Clean Code ideas are meh. But their performance is not the only or even one of most important aspects of it.
  - temphypercube 4y ago
    The software is delivered 6 months earlier, and it's 2x slower than it needs to be. Then it continues to get slower, because the company making this code has a culture that actively disdains making software quick (and in any case, the programmers working there don't know how.) 5 years down the line, the software is 2000x slower than it needs to be, and millions of users are having a minute or more of their day wasted, every day, waiting for things to load and icons to move that should be happening in milliseconds. Additionally, the quality and velocity of their work is far lower because using slow interfaces feels like wading through mud, leading to errors and frustration. The total human cost over the next 20 years is on the order of tens to hundreds of thousands of quality-adjusted person-years. Now, you might say that the right move is to make the code run well once it becomes a problem- but empirically, I don't see this happening!
  - deleted 4y ago
    [deleted]
tempaccount420 4y ago
This is too polite... They're trying very hard not to offend each other. Don't base your opinion on the topic from this conversation, I think it's better to hear what each of them have to say "behind their backs".
phendrenad2 4y ago
I love this video because it's a long-missing counter to Clean Code. In the software world, often someone makes a bold claim (like "clojure considered harmful") and someone rebuts it ("a response to 'clojure considered harmful'") and someone rebuts the rebuttal ("a response to 'a response to «clojure considered harmful»'"). Sure, we've had people criticize Clean Code before, but never a proper critique.
RickJWagner 4y ago
This is the second critical thread about Uncle Bob in the last month or so. (Maybe there have been more.) Why digging at ancient books? Is there something going on here?
hcarvalhoalves 4y ago
I have a problem with software engineering use of the qualifiers “clean”, “simple”, “easy”, “decoupled”, “elegant”, among others that only appeal to aesthetic sense but are not quantified at any moment.

223 points by rinesh 4y ago

"constrained problem within a resource constrained environment" is a good phrasing

this was a very amicable and fruitful discussion it's been chaffing me a lot last couple of years that it is so hard to learn about making performant code. It was nice of Julia Evans to write that very approachable strace zine [1]. I wished there was more of that kind of stuff. So I am happy Casey is doing a whole course on this stuff [2]. [1] https://wizardzines.com/zines/strace/ https://wizardzines.com/zines/strace/ [2] https://www.computerenhance.com/p/performance-aware-programming-series https://www.computerenhance.com/p/performance-aware-programm...

blt 4y ago
Check out Mike Acton's work also.

taneq 4y ago

Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.

nayuki 4y ago
It's true. It's easier to make mathematical connections with algebra, combinatorics, etc. when you're reading short formulas and not being not knee-deep in hand-written SSE asm.
thethirdone 4y ago
From: https://www.computerenhance.com/p/clean-code-horrible-performance https://www.computerenhance.com/p/clean-code-horrible-perfor... > The speed differences range from 20-25x — and of course, none of the AVX-optimized code uses anything remotely like “clean” code principles. If clean code limits your default performance to 20 times worse, those high level optimizations might not even be worth it.
- microtherion 4y ago
  The point is, without a reasonably clean starting point, you'll never get to apply those 20-25x optimizations in code bases beyond a certain size, because they've become a wasteland of mediocre micro-optimizations before you even get started. So the sensible thing to do is to identify a component of manageable size, fence it off with suitable abstraction boundaries, and then apply optimizations WITHIN the confines of that component only.
- taneq 4y ago
  If your performance-critical code is 25x slower than it could be, while using the same algorithm, it’s not “clean”, it’s just bad.

wokwokwok 4y ago

Some gems from the discussion… > Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.” > You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is probably for the same reason that your video was solely focussed on the amplification of performance to the strident denigration of every other concern. To a performance hammer, everything looks like a nail. ;-) Overall a very amicable and interesting read. It’s so easy to preach high level architecture without specifics, but also so very easy to cherry-pick a specific example where generic advice doesn’t apply. I think it’s interesting that there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” …and I’m absolutely 100% with Uncle Bob that bounded contexts for complex code is the solution. This is the approach rust takes with unsafe code and it has proved to be an extremely effective principle.

slavik81 4y ago
> there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” In my experience, poor performance is often because the code is needlessly complex and does unnecessary work. In that case, there's no trade-off. You can both improve performance and readability by simplifying. There may be trade-offs required to optimize for the absolute maximum performance, but you can get most of the way there without sacrificing anything. The vast majority of programs are nowhere near the pareto frontier between performance and readability.

burlesona 4y ago

I’m surprised that such a thoughtful and civil conversation came out of this after the precipitating screed against Clean Code. Kudos to both sides for engaging constructively!

Barrin92 4y ago

The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so much of his advice from his experience on game engines, which are an incredibly forgiving domain in many ways. You can have some bugs, you can drop some things over the network, it doesn't matter much. But you can't really do that in many other applications. If you had a big codebase for an application that is safety critical, going at it with his style of low-level programming you might make some very costly mistakes really quickly.

kamikaz1k 4y ago
Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code. (I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)
- Barrin92 4y ago
  No need to make assumptions given that they dug into that issue and the problem was algorithmic. As Bob points out that's orthogonal to clean code ideas. If you chose the wrong datastructure or algorithm and have quadratic complexity all the micro-optimizations in the world aren't going to help you. The only strawman honestly is to pick someone at github writing shoddy code and then using that to argue against system architecture? It's pretty obvious that a text editor lagging on a paragraph of text isn't the consequnce of having wrapped something in a function. If you've written code slower than a human you don't have clean code, you just have bad code.
oreally 4y ago
I wouldn't go down that line. There is code that makes you -think- it's safer but all it really does is add more needless complexity. It's one of those things where the 'safety' result hasn't really been given a good measurement.

pkolaczk 4y ago

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears. IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed. And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.

Apocryphon 4y ago
Clean Code led to the development of the VIPER framework, which is a crime it must answer for.
- fulafel 4y ago
  I thought about https://github.com/viper-framework/viper https://github.com/viper-framework/viper first, but I guess you mean https://github.com/topics/viper-architecture https://github.com/topics/viper-architecture
- FlyingSnake 4y ago
  True. VIPER was the craziest thing I had to deal with when I developed iOS.
robalni 4y ago
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.

nayuki 4y ago

At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem. As an addendum to Casey's video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD/vectorization. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.

brtkdotse 4y ago
> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I fully agree that human comprehension should be a prime objective for code. Alas, following the tenets of “Clean Code” produces anything but that.
- xjay 4y ago
  I know that the original "MVC guy" and "Bob's nemesis" :^) have been looking into making human comprehension the main goal of a new programming language, "trygve", named after Trygve Reenskaug (MVC). https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction
thethirdone 4y ago
I don't think Casey would object to "optimizing for human comprehension". If you are willing to give up an order of magnitude of performance, you can probably just do it without much care. I agree that "optimizing for human comprehension" is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don't think that guidelines like "clean code" actually are particularly effective at making understandable code. My personal guideline is to prefer code which is "simple" for both humans and computers. > So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it. I hold the controversial opinion that Knuth's advice is not relevant to most modern programmers. Most modern programmers have never done the "optimization" that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won't be significant hotspots. Everything will be lukewarm.

dang 4y ago

Recent and related: “Clean” code, horrible performance - https://news.ycombinator.com/item?id=34966137 https://news.ycombinator.com/item?id=34966137 - Feb 2023 (906 comments)

the_gipsy 4y ago

> preferring inheritance hierarchies to if/switch statements, And then he goes on touting readability right after that. Bold.

noisy_boy 4y ago

This exchange was more enjoyable than I anticipated it to be. > I created this with vi and used 1,$s/ /:/g > Because, I really am an old C hacker at heart. %s/ /:/g would have been shorter.

kilgnad 4y ago

Here's another controversial opinion: It's the genius programmers who write the shittiest code. In my experience clean code tends to be a waste of time for geniuses because shitty code isn't really a problem for smarter people. The further away you are from genius the greater the tendency for you to write cleaner code because you need it in order to deal with the complexity. What's common among HN readers is that they think they're smart. So you may be reading this and thinking "Wait a minute, this isn't true! I'm smart and I like clean code!". Well, I hate to break it to you. The truth hurts because most likely one of those two attributes probably doesn't actually describe you. Also as a side mention, I'm a clean code Nazi. My code is really clean.

anchochilis 4y ago
This was funny. But I've seen too much clean code written by people smarter than me to agree. I actually think how "clean" your code is depends on lots of factors. Eg. (a) Do you care if your coworkers find it easy to modify your code? (b) Do you feel a sense of ownership over the code you're touching? (c) Does your organization reward delivery speed without any checks for code quality? (eg. no culture of code review) (d) Is the code a proof-of-concept that needs validation from users before further investment?
- kilgnad 4y ago
  You're not dealing with the geniuses. You're likely just dealing with people smarter than you. I can assure you geniuses are rare, and people of the same intelligence level tend to gather so you can go through a career completely missing them depending on where you work. There's enough noise such that among these groups you won't notice the correlation. Tbh the geniuses don't view their own code as shitty, to them it's quality. It's only viewed as shitty externally.
dsego 4y ago
I've come to the same conclusion, really smart people who write compilers, name their variables one single letter and the like (the extreme variant) etc., they can actually see the matrix beyond the funny characters on the screen, they have the capacity and attention to understand the messy bits without having to make it neat, those three nested for-loops inside multiple conditionals don't bother them, they can quickly visually parse difficult code without refactoring and sectioning it off. On the opposite side, there some like me who are deficient in that regard, so I spend my time pimping my code to look nice, nit-picking on syntax style, eliminating else-clauses, trivial stuff like that.

drewcoo 4y ago

[flagged]

drewcoo 4y ago

[flagged]

userbinator 4y ago

All the concentration on "developer productivity" has lead to a massive loss of user productivity and wasted energy. Ironically, a lot of developers are also users, so they suffer just the same. The worst part is, AFAIK it's not even clear that the recommendations in Clean Code are better for developer productivity, insofar as they create excessive complexity. Another thing to note is that I've observed a significant fraction of users (and developers!) seem to have a very poor perception of time. You can replace an app they were using with one that is otherwise exactly the same but introduces a whole second of delay when interacting with the UI, and they wouldn't notice unless you gave them the two versions to compare side-by-side. Of course another significant fraction does notice, which is why you often see both "this new version is horribly slow" and "works fine for me, it doesn't feel any slower" opinions.

randoglando 4y ago

I found it interesting how concrete Casey gets, and how he quickly identified the cause of the UI bug (+ a mitigation). Meanwhile, it looks like Bob was speculating in thin air and throwing out random terms (O(n^2)) trying to fit in.

comex 4y ago
But Bob was right that the problem was algorithmic. Checking whether a string ends with a prefix of an emoji abbreviation is a task that could easily be done in a microsecond. It’s apparently taking 100 milliseconds, which is 100,000 times slower. Even factoring in the overhead of JavaScript, you could easily add a 10x or 100x “clean code” penalty and still be nowhere near the level where it’s a performance problem – if the algorithm is correct. By “algorithm” I’m referring to more than just asymptotic complexity. Even so, as for “O(n^2)”… well, I didn’t analyze the code myself, but judging by Casey’s analysis (or even just by the symptoms), it seems quite likely that the time taken to input a character is at least O(n) in the number of characters entered so far (if not worse). That makes the total operation of entering n characters take O(n^2) time. Bob does seem to be referring to the total being O(n^2) rather than each character being O(n^2), since the reallocation strategy he mentioned as an example would similarly take O(n) per character. In that context, O(n^2) is less of a guess, more of a reasonable assumption given the observed performance characteristics. And it’s a reasonable aspect to point a finger at, because lowering the asymptotic complexity would be an essential part of fixing the performance problem. Not sufficient by itself, but pretty much necessary.

teo_zero 4y ago

> It is economically better for most organizations to conserve programmer cycles than computer cycles This is only true if "organizations" here means those which write the program. If you include those who actually use the program, I don't see how this sentence could be proved.

Aperocky 4y ago

Simple > Complex. Every extra year I spend in engineering, it's becoming clear that this is actually one of the only few things that mattered in the long run. I would say this is one of the best if not the best advice in programming and even in life. If clean code doesn't follow that, ditch.

LaLaLand122 4y ago
What you say makes a lot of sense. Now, to give a concrete example. There was a C++ PR introducing an interface taking an argument of type int representing a duration. I suggested using std::chrono::duration (https://en.cppreference.com/w/cpp/chrono/duration https://en.cppreference.com/w/cpp/chrono/duration), and I was overruled on the basis that "an int is simpler". To have context if you are not too familiar with C++: - std::chrono::duration is part of the C++ standard library - It's a wrapper on top of an arithmetic type just giving it "duration" meaning. It's of the same size as the wrapped arithmetic type. - Yes, you can argue it's more complex since it adds a bunch of templated code on top of a language built-in type. I'm going to guess that's not what you had in mind with your "Simple > Complex" advise. If so, that's what happens with any advice, even with simple one liners: somebody will take it to justify some crazy decision.
- Aperocky 4y ago
  Simple vs Complex should always be evaluated holistically. Each file could be simple but if they are in 5 level of inheritance, then it's not simple as a whole. Same with 10 different way to do the same thing or 3 different class that can be used to the same effect, it's not. Your case is clearly adding complexity as the new class have no reason of existence, as it's just rebuilding part of the standard library which your compiler would likely have included anyways. The suggestion is clearly a bad one but our industry is filled with people who are either incapable of adequately applying "Simple > Complex" or don't believe in it. That's why enteprise FizzBuzz exist.

fwlr 4y ago

The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The reason it doesn’t sit well is that, in practice, it seems like most products don’t know what needs to be fast and so developers end up making almost everything slow. Casey gives many examples but the one that sticks out most in my mind is the Visual Studio watch window (about 25 minutes into https://m.youtube.com/watch?v=GC-0tCy4P1U https://m.youtube.com/watch?v=GC-0tCy4P1U). The watch window lets you pin variables you’re interested in and it will show you their current values as you step through the program’s execution. Invaluable for debugging. Visual Studio’s watch window is incredibly slow, to the point that it actually has a debounce so it will stop updating when you’re stepping quickly and only update once you’ve stopped quick-stepping. This seriously impacts its usefulness! To me, the watch window seems like it’s obviously one of those modules that needs to be running in milliseconds or less - but the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead. So in my mind, “write clean except where performance matters” comes with an almost fatal caveat, something like “you won’t know where performance matters”.

lazyasciiart 4y ago
> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.
- fwlr 4y ago
  It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.
  - 4y ago

tester756 4y ago

I'm starting to hate programming discussions, after you've read a lot of them they're predictable, boring as hell and you can argue endlessly just because you value a little bit different things. This discussions is yet another, nothing special way of saying: context matters. You have a list of requirements of what you want to achieve, some of them do appear during development and you develop against this. I have completely no idea why "software part of the internet" is losing their shit over those 2 guys arguing since it doesn't seem to be "deeper" than 2 random people arguing in some random comment chain.

javaunsafe2019 4y ago
This. Thank you. Also the amount of claims and self confidence in this thread by people not even able to back their claims with examples is hilarious imo.
ctx_matters 4y ago
>context matters I've wrote about my observations with the same conclusion https://trolololo.xyz/programming-discussions https://trolololo.xyz/programming-discussions >I've started thinking about it and realized that people arguing on all previously mentioned platforms tend to have various backgrounds >Web developers, desktop developers, system programmers, cloud engineers, people working at startups, people working in corporations, beginners, experienced and known in the industry people, FP/OOP fans, self-taught, people after electrical engineering/computer science/mathematics, and a looot of more. >So, what's the difference? I'd say context and the context is unfortunately lost in those discussions because all you see is just somebody's comment and that's it. Nickname very often doesn't tell you anything (except on forums after you spend some time there) >And they all are right (or may if you want to argue :)), but very often that information about their respective domains is lost and the argument is around some "generic code base" or some "average project" which is different for everybody.
bsaul 4y ago
you've probably never worked in an average enterprise java shop. The religious refactoring of any kind of software to its most generic and decoupled design, under the name of "cleanliness", is quite impressive. it's quite important that one of the most well known figure recognize that those designs have costs in terms of performance and are not suitable anywhere.

vmaurin 4y ago

For me it is not concept to oppose. You can write optimized code but still name your variables "first_item" instead of u_fp_64_ptr like I often see in "optimized code"

tsimionescu 4y ago
When code needs to be heavily optimized, the fact that some variable is a pointer to a 64bit unsigned floating point number may well be more relevant for understanding the code than the fact that it points to the first item in some list.
- kaba0 4y ago
  But that is explicitly known by the type, we are not writing 90s era microsoft office (hungarian notation really should not be used).
  - tsimionescu 4y ago
    The name of a variable is supposed to contain the most relevant information someone needs when looking at an expression. If the most relevant information is the type, then that should be name. The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was. Imagine you see some code masking the first 40 bits from the location pointed to by first_item. Does the name "first_item" help you understand why they are doing that, or would it be more useful to know that it is the first forty bits of an u_fp_64, so it's masking the mantissa and just keeping the exponent?
    - dns_snek 4y ago
      > The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was. Doesn't your IDE allow you to effortlessly see the type of a variable, either through inline hints, some sort of keyboard shortcut or at the very least, by hovering your mouse over it? Admittedly I haven't professionally worked in C/C++ since university, but my understanding is that small functions can be (are?) inlined, removing the function call overhead. If that's the case, couldn't you write a 1-line function like "maskMantissa", which would clearly communicate what the code is doing without overhead?

Spiwux 4y ago

I really do not understand why this is a discussion, why a video had to be made about it and why we now need an interview about this. Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of value

blondin 4y ago
it did add something of value. uncle bob realized his "clean code" may have done a disservice with regards to performance. but i am not holding my breath on seeing a change come about soon. it is possible to optimize for both performance and developer productivity. but everybody is leaving that out in the discussion.
martinhath 4y ago
> Clean code / readable code / whatever you want to call it is often at odds with performance. I disagree; or rather, I'd put it the other way around by saying that often you can get both clean code (by some metric) and reasonable performance. The patterns in e.g. the book by Robert Martin doesn't give you either, though. > And for most enterprise projects it just doesn't matter. It matters for the users. I use software that is slow for no good reason, and I'd like to live in a world where this is not the case.
weatherlight 4y ago
Also, I feel, it's a whole lot easier to refactor "clean" or "readable" code for performance than the other way around. Make it run. Make it clean. (and if need be,) Make it fast.
- animesh 4y ago
  As a dark matter developer, I learnt it as: Make it work Make it right Make it fast My interpretation of this, so far, "make it right", is to make the code and design cleaner and refactor. Then "make it fast" came into the play, iff, there was enough push.

awesome_dude 4y ago

Function calls are expensive, more news at 11

moomoo11 4y ago

Or you know. Have a toolbelt. You keep tools on that belt and you use them as necessary. Making a simple service? It’s in the descriptor. Just keep it simple. Making something large that has a bunch of people working on it? Time to pull out the toolbelt. Making something super mission critical? Use the right tools. No approach is perfect. That’s why you use what makes most sense, mixing and matching, to put together what works best for the task at hand. Anything else is noise and just ignore.

Manjuuu 4y ago

I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc... Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind: What have they ever built? Reading code from popular opensource projects and evaluating the different approaches they took is way more useful than reading those books, full of regurgitated wisdom from people with minimal street creed. And yes, maybe it's time to stop calling him "uncle", it's not your uncle, he has very little to teach. Start building, stop reading.

donatj 4y ago
I read through a decent chunk of Patterns of Enterprise Application Architecture for class in college in ~2006 and while I was indeed young and impressionable, it left a very bad taste in my mouth for heavily OO’d systems to the extent that it had the opposite effect - I largely avoided them likely longer than I should have.
Defletter 4y ago
> What have they ever built? You have to be careful with that though. We've had a few people who'd "channel Torvalds", so to speak, by parroting his opinions with abrasive fervour. Any dissenters were treated as either thinking they knew better than him, or being ignorant of his work, or not having an appropriate appreciation for his work. And since Torvalds is very opinionated, so were they. It wasn’t exactly a fun work environment. I’d also like to challenge the premise of the question. Being a maintainer for example is just as valid as being a “builder.” In fact, you’ll probably gleam more wisdom from being a maintainer than a builder since you are, by definition, trawling through other people’s code and maintaining it. Look, it’s perfectly valid to consider someone’s body of work while considering their opinions. But dismissing them out of hand is wrong, in my opinion.
- Manjuuu 4y ago
  I agree with everything you said, especially with how important the role of the maintainer is to get something that keeps working over time (both are builders). And yes, holding someone else opinions strongly doesn't make you instantly a clone of Torvalds, thing that in workplaces with n>1 employees might not be desirable.

blondin 4y ago

i find it baffling that uncle bob thinks it's okay for dialog boxes to be sluggish. and that we can throw CPUs and GPUs at most performance problems. because it's "cheap". that way of thinking is part of the problem.

eviks 4y ago

The performance degradations is a clear harm and pervasive. The dev productivity improvements are questionable. So let's go do some harm! (and that example of slow typing in a "big" paragraph is a big red cherry on top of a brown pile!)

liampulles 4y ago

Enterprise Code should be concerned with getting the best "order" of performance (i.e. O(n) over O(n^2)), but beyond that design for brevity and clarity. Architecture wise, the Clean Architecture is a good starting point, I would enforce one or two rules - maybe domain seperation and business logic/driver seperation, but not go more zealous then that.

revskill 4y ago

Rule 1: if it works, refactor it

xjay 4y ago

Hardware may perform more operations per second, but inefficient software remains inefficient, and it's still wasting roughly the same amount of energy as it did on slower hardware, and waste only accumulates, skewing the performance of the rest of the system. That inefficiency gets multiplied by millions or billions of units worldwide that run this software.

blippage 4y ago

The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin. Functions should do only one thing. Sure, but what does that actually /mean/? If a function calls two other functions, then surely, by definition, it's doing two things? So how much a function is doing is a question of how far you stand back when looking at it. Also, if you follow a rule of functions having only 2-4 lines, then you're going to have a lot of functions, and tracing through code paths is going to be like peeling back layers of an onion. So that advice is just wrong. It's not even clear that long functions are a problem. Back in the early 80's my A level computing science teacher, who had worked in industry, said that there was no real evidence to suggest that long functions are less readable. There was a joke going around some time ago about an interviewee who was asked how big a function would be. He said "I like to be able to keep it within my head." When asked to elaborate, he said "I put my head against the screen. If the function is longer than that, then it's too long." Although facetious, I think that's actually a good idea. A function should be at most a screenful, so you can see it complete on the screen. Recently, I wanted to customise my own gopher client. I first messed around with one written in Go, but it was too complicated to adapt for what I wanted. I switched to a C alternative, which was still a bit too complicated. I decided that I'd basically re-write the whole thing in C++, using whatever bits of functionality from the C part that I thought useful. If there is a magic formula to writing good code, then I'd say that the less code you have the better, and try to keep code reasonably decoupled. The problem with writing applications is that there's a tendency to be promiscuous in how you use objects. So, in essence, every part of the program relies on every other part of the program. There's no separability of design. It is better to take a "library" approach to things, where each "module" doesn't know how it is going to be used. You then have co-ordinating functions which stitch this functionality together. The code you end up with should be much easier to adapt. It's also useful not to be overambitious with your project. Someone once said that the genius of Ritchie and Thompson was being able to obtain 90% of the functionality using 10% of the code. If you think parsimoniously in that way, they'll be a lot less code to wade through when you want to modify things.

roarcher 4y ago
> The big tip-off that all is not as it seems is that he calls himself "Uncle Bob" Martin. Totally agree. I believe "Uncle" is a pretty ingenious piece of branding meant to paint him as an implicitly trustworthy and wise figure that I should feel endeared to. He's just a guy who has built a career out of offering his opinions on how others should do a job he's never done. Notice that his About page [0] doesn't mention a single piece of software that he's actually built. He reminds me of a company I used to work for. It was a healthcare architecture firm that got sued so many times for their fuckups that they pivoted to being a "thought leader" in their industry. Instead of continuing to build hospitals, they focused on consulting and publishing articles with their innovative [1] ideas about how hospitals should be designed. A classic case of "those who can't do, teach". [0] http://cleancoder.com/files/about.md http://cleancoder.com/files/about.md [1] I shit you not, one of their ideas was a "hover gurney" that was basically a giant quadcopter with a bed on it. It was supposed to be easier to move. Blasting germs all over the hallway with hurricane-force winds was apparently not an issue anyone thought worthy of consideration.

barisx 4y ago

"Clean Code for me the testable code."

Grothendank 4y ago

Reading this conversation is like watching Casey skillfully and lovingly jailbreak Uncle Bob's GPT personality prompt, yielding a new and exciting performance focused alter ego which I admiringly dub "SPEEDY BOB".

tinco 4y ago

It's just an anecdote but I think the emoji picker problem they explored is really what it is about. You can debate all day about whether Bob's clean code principles are valuable but the reality is that no pattern from any of his teaching will ever make a text editor get slow after just 300 typed characters in a single line. I bet I'm Casey's life it happens often that he has to dismantle clean architecture in an application that is already quite fast just to squeeze out some extra performance. But that's not in the same arena of these every day performance annoyances. It's some sort of variant on Amdahl's law. You could have a million lines of fairly performant code, and then in 3 lines someone fucks up and introduces an accidentally quadratic function into an emoji picker and your whole application will feel slow. That's also the take away conclusion from this discussion. After listening to 8 hours of uncle Bob going on about clean code, he should pause and tell you to check over your codes performance when you're done. Since the clean code made you so productive, and your code so readable, it should be an easy thing to quickly check your performance.

readlikeasloth 4y ago

Last time I checked programming had something to do with computer science. You could say its applied computer science. So I ask myself: how come that this discipline, already 50+ years old, has almost no consensus of how its output aka written code should be structured? Why are there no established standards or rules? Not a rethorical question, happy to hear your thoughts.

eviks 4y ago
This confusion is easily resolved - just remove "science"
- bitwize 4y ago
  Indeed. What we do is more akin to computer voodoo. Now let me wave a dead chicken over those server logs...

stuaxo 4y ago

Yeah, not a fan of atomising code into so many classes as Clean Code recommends, the mental load is higher and its a lot harder to see what's happening. And thata before considering the great analysis of the examples in this book from a few years ago, that showed that they don't conform to the clean code philosophy at all. Lucky for me, I bought this and procrastinated so long about reading it, I've since found out it's not good, so I saved some time.

bitwize 4y ago

What Casey doesn't get is that for the vast, vast majority of code out there, reliability, maintainability, scalability (to hundreds of servers, or hundreds of software engineers working on the code base), testability, and observability trump raw performance. CPU and RAM are cheap. By engineering your software to scale performance as close to linearly as possible with the addition of more CPU and RAM, you've changed the problem from one that requires the best engineers to solve into one that can be solved literally by throwing more money at it. At the largest software deployment scales this is totally doable, and it makes the most sense for the business.

sgarland 4y ago
You've now pushed the problem to the infra team, thanks. What happens when the spot instance that pops up is a much older generation, and your app suddenly runs far slower due to reduced memory bandwidth, CPU clock speed, etc.?

bayesian_horse 4y ago

The only clean code is the one that does nothing. Otherwise you can only struggle to add as little dirt as possible.

DeathArrow 4y ago

>What’s more, processors are so cheap and available that it is a trivial matter to add more of them to a system. I don't know what Uncle Bob uses but the motherboard in my PC has exactly one CPU socket. And at $600 I wouldn't say it's cheap. I'm not sure how can I add another CPU to my laptop and my mobile phone. Also not all software is multithreaded.

gs17 4y ago
To give him the benefit of the doubt, maybe he meant a distributed system? Much easier to add CPUs then.

DeathArrow 4y ago

Long time ago advices like Uncle Bob's seemed good to me. Now I try to use OOP the least I can, I try to use the less abstractions I can and I try to make the CPU use the least number of instructions. I am using a part procedural and part functional approach, keep data separate from functions that process the data, try to use immutable data where possible and minimize state changes. I am trying to use a data oriented approach and I am more happier and productive than if I hade to apply clean code principles and software patterns on top of software patterns.

jmartin2683 4y ago

I shudder to even think of the cumulative ecological cost of Bob's line of thinking, here. Imagine if Henry Ford did this... we'd all be getting 0.3mpg, but hey... productivity!

globalreset 4y ago
Imagine software that was delivered 6 months earlier but is 2x slower than it could be. This lead to productivity increase of it's users of 2x during that 6 months. At the expense of some extra electricity use worth $100, they made $10M worth of real world productivity. My point is... the thing that is much worse than software that is unnecessary slow, is the software that was not yet written at all. Now ... I think some of the Clean Code ideas are meh. But their performance is not the only or even one of most important aspects of it.
- temphypercube 4y ago
  The software is delivered 6 months earlier, and it's 2x slower than it needs to be. Then it continues to get slower, because the company making this code has a culture that actively disdains making software quick (and in any case, the programmers working there don't know how.) 5 years down the line, the software is 2000x slower than it needs to be, and millions of users are having a minute or more of their day wasted, every day, waiting for things to load and icons to move that should be happening in milliseconds. Additionally, the quality and velocity of their work is far lower because using slow interfaces feels like wading through mud, leading to errors and frustration. The total human cost over the next 20 years is on the order of tens to hundreds of thousands of quality-adjusted person-years. Now, you might say that the right move is to make the code run well once it becomes a problem- but empirically, I don't see this happening!
- deleted 4y ago
  [deleted]

tempaccount420 4y ago

This is too polite... They're trying very hard not to offend each other. Don't base your opinion on the topic from this conversation, I think it's better to hear what each of them have to say "behind their backs".

phendrenad2 4y ago

I love this video because it's a long-missing counter to Clean Code. In the software world, often someone makes a bold claim (like "clojure considered harmful") and someone rebuts it ("a response to 'clojure considered harmful'") and someone rebuts the rebuttal ("a response to 'a response to «clojure considered harmful»'"). Sure, we've had people criticize Clean Code before, but never a proper critique.

RickJWagner 4y ago

This is the second critical thread about Uncle Bob in the last month or so. (Maybe there have been more.) Why digging at ancient books? Is there something going on here?

hcarvalhoalves 4y ago

I have a problem with software engineering use of the qualifiers “clean”, “simple”, “easy”, “decoupled”, “elegant”, among others that only appeal to aesthetic sense but are not quantified at any moment.