26 ms·

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

by mabbo 4y ago

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.

drivers99 4y ago
It still matters because in your example it will affect how smoothly the computer responds once it gets the user input.
- xupybd 4y ago
  But how much does that matter? If you're scaling to 1000s of users then yes. If you have a GUI for a monthly task that two administrators use, then no. The less something gets used the longer the payback time on the initial development.
  - layer8 4y ago
    You’re not wrong, but today’s software is so slow/high latency so often, despite incredibly powerful hardware, that as a rule it should absolutely matter.
    - datavirtue 4y ago
      Maybe it's because they used AWS Lambda and API Gateway for the API?
  - TeMPOraL 4y ago
    > If you have a GUI for a monthly task that two administrators use, then no. Fine, but be honest with yourself and admit that you are contributing a lot to making the lives of those two admins miserable. It doesn't matter if I'm using your software once a month, or once a day. If it's anything like typical modern software, it will make me hate the task I'm doing, and hate you for making it painful. In fact, shitty performance may be the very reason I'm using it monthly instead of daily - because I reorganized my whole workflow around minimizing the frequency and amount of time I have to spend using your software.
    - xupybd 4y ago
      > Fine, but be honest with yourself and admit that you are contributing a lot to making the lives of those two admins miserable The funning thing is I'm thinking of a specific case and I work closely with those admins. I even have filled in for them when they're sick. Yes I know it's a pain, they know it's a pain, and they let me know it's horrible. The only reason this one is monthly is that it's a stock take. They forgive the crappy performance as it still saves hours of work when compared to the previous manual option of entering things into multiple systems.
FooBarWidget 4y ago
Not only time to market, but also maintainability. In non-performance-critical areas, it's pretty important that when the original dev team leaves, new hires can still fix bugs and add features without breaking things.
- the-smug-one 4y ago
  I don't see how the code snippets presented are less maintainable.
  - rrobukef 4y ago
    I do. Because I was asked to add a convex polygon and calculate its area. And now the shape_union must be rewritten from scratch. ... And maybe we want set-operations in the future...
    - Tomis02 4y ago
      > And now the shape_union must be rewritten from scratch. We spend most of our time reading code. If the Casey's code snippets are easier to reason about (which they are, especially as the codebase get larger), that's a big win. I'd imagine you want to optimize for code that is easy to (re)write, rather than minimize the number of key strokes while increasing the time spent understanding the code.
      - rrobukef 4y ago
        I'd say that the needing rewrites is bad for the future clarity of the code. So much so that people conclude the 50% performance hit is worth it to use open polymorphism (interfaces, etc.) over closed (tagged unions, algebraic data types, etc.). So I optimize for the ability to reason about over the lifetime of the project above the current ability to reason and above performance (with exceptions). What is adding a polygon going to do? Either back to the 'bad' interface to hide variable object size, extend to a tagged union with a size of the biggest datastructure - hurting cache performance each time it grows -, or an involved Object of Arrays structure - not good for clarity but great for performance. All while having to remember which field, width or height, to use for the circles radius.
AnIdiotOnTheNet 4y ago
> Look, most modern software is spending 99.9% of the time waiting for user input If that's true, why does it take forever to load and frequently fail to keep up with my input?
- chpatrick 4y ago
  Often it's because of bad (quadratic) algorithms, not because the code isn't micro-optimized. For example: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
  - AnIdiotOnTheNet 4y ago
    It isn't about "micro-optimization", that's just what bad developers use as an excuse for never caring at all about performance. Casey uses the term "depessimization" to describe the process of making a program not run like shit. Modern computers are ludicrously fast, and modern developers have somehow managed to make them slow. Regardless, these programs should be spending 99% of their time waiting for user input, but instead they're working data through a mountain of abstraction layers on the faulty assumption that it is a) saving developers' time, and 2) that that is worth much more than user time.
    - loup-vaillant 4y ago
      https://www.lesswrong.com/tag/scope-insensitivity https://www.lesswrong.com/tag/scope-insensitivity Emotionally we have no idea how bad it is to waste as little as a few seconds per day for millions of users. It's just a few seconds, right? We're just forgetting to multiply those seconds by the number of users.
  - morelisp 4y ago
    Accidentally super-linear algorithms happen a lot more when you hide stuff behind three layers of interfaces rather than seeing "oh, this uses a list instead of a set".
ajmurmann 4y ago
Don't forget the 90% of the processing time that it's waiting for a DB response
- ilyt 4y ago
  Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.
  - ajmurmann 4y ago
    Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.
  - whstl 4y ago
    I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries. [1] https://github.com/rails/jbuilder https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.
- FridgeSeal 4y ago
  I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.
  - ajmurmann 4y ago
    Just work with some folks who don't know basic query optimization
bgirard 4y ago
Having done a lot of performance work on Gecko (Firefox), we generally knew where cycles mattered a lot (low level graphics like rasterization, js, dom bindings, etc...) and we used every trick there. But for the majority of the millions of LoC of the codebase these details didn't matter like you say. If we had perf issues that showed up outside they were higher level design issues like 1) trying to take a thumbnail of the page at full resolution for a tab thumbnail while loading another tab, not because the thumbnailing code itself was slow, or 2) running slow O(tabs) JS teardown during shutdown when we could run a O(~1) clean up step instead.
mquander 4y ago
> 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. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because of the exact kind of overabstraction that this article criticizes (e.g. people use React and then design React component hierarchies that seem "conceptually clean" instead of ones that perform a rendering strategy that makes sense.)
- PragmaticPulp 4y ago
  > That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.
  - fvdessen 4y ago
    I once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern hardware. However the code was more verbose and needed a lot more technical know-how to understand and maintain.
    - Veliladon 4y ago
      Yep. In Rust land for instance it'd get compiled down to a for loop and be ridiculously fast. Every time you do a .map or a .filter in JS though it gets abstracted down to a function that makes an allocation for the ENTIRE ARRAY and then copies the entire array into that new array doing whatever you asked to data. The JS VM might be able to optimize some of it away but the abstraction is awful. So if you were to manually run a for loop over an array instead of iterating through it I'm not surprised you got an order of magnitude faster performance.
bakugo 4y ago
> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something It's because of this mentality that almost all desktop software nowadays is bloated garbage that needs 2GB of RAM and a 5Ghz CPU to perform even the most basic task that could be done with 1/100th of the resources 20 years ago.
- bitwize 4y ago
  RAM and GPU are cheap. Most users aren't going to notice. Meanwhile by choosing Electron, the developers were able to roll out the app on Windows, Mac, and Linux at nearly zero marginal cost per additional platform.
  - FridgeSeal 4y ago
    > Most users aren't going to notice. And other lies you can tell yourself to sleep at night. Most people notice. Very few have the capacity, power (or realise) to complain about it. They accept what they’ve been given, despite how awful it is, because they have basically no other option. A concrete example: my previous work had to use bitbucket pipelines for our docker builds. My current work uses GitHub actions. GH has my container half-built before I can even click through to the page. Bitbucket took a good minute to start. My complaints about bitbucket fell on deaf ears in the business, and no amount of leaving feedback for Atlassian to “please make builds faster” ever made the slightest amount of difference. Every time MS teams comes up that’s met with complaints about performance (among other things) so people definitely notice that. VS Code gets celebrated for “actually having decent performance”, so the bar is so low that even moderate performance apps receive high praise. Users definitely notice performance, whether the PM/business cares is a different matter, but we should stop deceiving ourselves by saying it’s alright because “users won’t notice or care”.
    - jbverschoor 4y ago
      Yup.. and if facebook didn't invest in a native mobile app, they'd been eliminated 10 years ago. Performance is a feature. Or does anyone here enjoy using an old tomtom gps where every tap on the screen takes 2 seconds? If so, please donate your beefy laptops to charity.
Cthulhu_ 4y ago
An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with. I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop with no short-circuiting mechanism. That's billions of lines of code being executed (I'm guessing) but the performance bottleneck is in how some consultant clicked some things together. Other than school assignments, I've never had a situation where I ran into performance issues. I've had plenty of situations where I had to deal with poorly written ("unclean") code and spent extra brain cycles trying to make sense of it though.
- scotty79 4y ago
  I heard it as make it work make it work correctly make it work fast Pretty was never in the picture. But if anyone wants to add it, it should come last.
  - treis 4y ago
    I like Make it work Make it good Make it fast
    - gregjor 4y ago
      I can measure "works" and "fast." Good can mean lots of things, it's a subjective assessment of code quality, readability, and maintainability. More experienced programmers probably have a better idea about how to achieve readable and maintainable code, but so far no one has come up with a measurable way to make code "good." Bob Martin spells out his ideas of "good" in his books but I don't find his examples particularly good, or even real-world. The only useful guide to "good" code I've come across in 40 years programming is The Elements of Programming Style, which Bob Martin has managed to expand from a thin pamphlet to multiple large books.
  - yCombLinks 4y ago
    Correctly is covered by make it work
sarchertech 4y ago
>Clean code optimizes for improving time-to-market for those features Does it though? Where's the evidence for it? The vast majority of people I've worked with over the last couple decades who like to bring up "clean code", tend towards the wrong abstractions and over abstracting. I almost always prefer working with someone who writes the kind of code Casey was than someone who follows the clean code examples I've spent my career dealing with. I've seen and worked with many examples of Data Oriented Design that were far from unmaintainable or unreadable.
- grumpyprole 4y ago
  Completely agree. These rules simply do not lead to better outcomes in all cases. Looking at the rules and playing Devil's advocate for fun: > Prefer polymorphism to “if/else” and “switch” Algebraic data types and pattern matching (a more general version of switch), make many types of data transformation far easier to understand and maintain (versus e.g. the visitor pattern which uses adhoc polymorphism). > Code should not know about the internals of objects it’s working with This is interpreted by many as "don't expose data types". Actually some data types are safe to expose. We have a JSON library at work where the actual JSON data type is kept abstract and pattern matching cannot be used. This is despite the fact that JSON is a published (and stable) spec and therefore already exposed! > Functions should be small "Small" is a strange metric to optimise for, which is why I don't like Perl. Functions should be readable and easy to reason about. Let's optimise for "simple" instead. > Functions should do one thing This is not always practical or realistic advice. Most functions in OOP languages are procedures that will likely perform side effects in addition to returning a result (e.g. object methods). Should we also not do logging? :) > “DRY” - Don’t Repeat Yourself The cost of any abstraction must be weighed up against the repetition on a case-by-case basis. For example, many languages do not abstract the for-loop and effectively encourage users to write it out over and over again, because they have decided that the cost of abstracting it (internal iteration using higher-order functions) is too high.
  - rrobukef 4y ago
    my 2 cents: I don't see algebraic data types as strictly superiour. It's just the other side of the polymorphic coin: there is open and closed ploymorphism. Open polymorphism happens with interfaces, inheritance, and typeclasses- the number is unlimited. Closed happens with ADTs - an enumeration of the cases. Open is great for extensibility: libraries can be precompiled, plugins are possible. Changes don't propagate - it is ""forward compatible"" which is great for maintaning the code. Closed on the other hand is great for matching. Finite is predictable & faster. Finite is self-contained and self-describing because it exposes the data types without shame. The purpose of the visitor pattern is now clear: it closes the open polymorphism for a finite set. Great, now we only need one kind and we still get matching. Or is it the worst of two worlds? Slow & incomprehensible and all changes propagate everywhere. So which one is better? Neither. But the reality is that all old imperative languages with polymorphism chose the open kind - the kind that adds more features because it was needed for shared libraries. Leaving you to build any pattern matching yourself and to burn yourself with the unmaintainable code. If people get burned, they learn. First they say don't do that and only then they replace the gas stove by induction.
randomdata 4y ago
> I think the author is taking general advice Not just general advice, but advice that is meant to be applied to TDD specifically. The principals of clean code are meant to help with certain challenges that arise out of TDD. It is often going to seem strange and out of place if you have rejected TDD. Remember, clean code comes from Robert C. Martin, who is a member of the XP/Agile gang. The author cherry-picking one small piece out of what Uncle Bob promotes and criticizing it in isolation without even mentioning why it is suggested with respect to the bigger picture seemed disingenuous. It does highlight that testable code may not be the most performant code, but was anyone believing otherwise? There are always tradeoffs to be made.
- larsonnn 4y ago
  But is this trade off not a little bit to much? It reminds me of Twitter or other companies which starting to change programming languages for performance reasons.
  - randomdata 4y ago
    Is testable code a tradeoff too much? That cannot be answered globally, only locally. That's why we have engineers, after all. You could eliminate the entire profession of engineering if "which tradeoff is best" could be answered broadly without deep understanding of specific circumstances.
ilyt 4y ago
> 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. CPU meter when clicking anything on "modern" webpage proves that's a lie. Also, sure, even if "clicking on things" is maybe 1-5% vs "looking at things" THAT'S THE CRITICAL PATH. Once the app rendered a view obviously it is not doing much but user is also not waiting on anyting and is "being productive", parsing whatever is displayed. The critical path, the wasted time is the time app takes to render stuff and "but 99% of the time is not doing it" is irrelevant.
- deleted 4y ago
  [deleted]
- izacus 4y ago
  Yeah, this comment doesn't even pass a smell test as soon as you try any of the modern Electron "apps". It's all horribly performing turd that needs a 4000$ MacBook to be tolerable at best.
scotty79 4y ago
What does it matter if it does this 0.1% ten times slower than it could? Then user will have to wait for the software which slows the most expensive component of the whole work setup, the human.
- adgjlsfhk1 4y ago
  if the software ever takes more than 10ms to do something it is stealing time from the human. the human is the slowest part of the system so nothing else should ever make the slowest part even slower.
- deleted 4y ago
  [deleted]
- whstl 4y ago
  It matters because, to give an example, Facebook still isn't fast enough to keep up with my typing speed. And I'm not that fast.
  - fifticon 4y ago
    that is probably because they are so busy keylogging every single stroke you type :-/
bilvar 4y ago
I don't know man, my TV has hardware several orders of magnitude faster and more advanced than the hardware that took us to the moon, and it takes dozens of seconds for apps like Netflix or Amazon Prime Video to load dashboards / change profiles or several seconds to do simple navigation or adjust playback. People just don't know how to properly write software these days, universities just churn out code monkeys with a vicious feedback loop occurring at the workplaces afterwards.
- naikrovek 4y ago
  yes. I've observed hardware get faster and faster for 30+ years and I've watched software consume all of that headroom the entire time, for no clear reason other than the way we write software is just getting worse and worse and worse.
- larsonnn 4y ago
  So true and so annoying.
- DeathArrow 4y ago
  Yes, but while you wait for the software to load, don't you have a smile on your face thinking that the developers used "clean code principles"?
yashap 4y ago
100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create massive in memory objects) - GC tuning/not enough memory - Programmer doing something dumb, like using an array when they should be using a set (and then doing a huge number of membership checks) With that being said, I have worked on the odd performance optimization where we had to get quite low level. For example, when working on vehicle routing problems, they’re super computationally heavy, need to be optimized like crazy and the hot spots can indeed involve pretty low level optimizations. But it’s been rare in the work I’ve done. This article is probably meaningful for people who work on databases, games, OSes, etc., but for most devs/apps these tips will yield zero noticeable performance improvements. Just write code in a way you find clean/maintainable/readable, and when you have perf issues, profile them and ship the appropriate fix.
- jimbob45 4y ago
  Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.
  - TeMPOraL 4y ago
    Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat the entire system as untrustworthy and wrap a layer of security around it. You can't do that with performance - there is no way to sandbox your app so it goes faster. You can only profile things then rip out the slow parts and replace them with fast ones - how easy that is depends on the architecture and approach you adopt early in the project.
matheusmoreira 4y ago
Most software can barely keep up with the display's refresh rate due to their unacceptably high latencies.
AbusiveHNAdmin 4y ago
"So by violating the first rule of clean code — which is one of its central tenants" The word is TENET. Tenants rent stuff.
nikanj 4y ago
But somehow modern software (Outlook, I’m looking at you) has trouble keeping up at my typing speed, and there’s a visible delay before characters appear on the screen. It doesn’t matter what the software does 99.9% of the time, if it’s an utter pig that crucial 0.1% of the time when the user is providing input.
overgard 4y ago
I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, you do need the latter a lot). Small functions can make code hard to understand because you need to jump to a lot of places and lose the thread on the sequential state (bonus points if the small functions are only ever used once by one other function). The more I work in code bases the more I find that overusing these "clean" ideas can obscure the code more than if it was just written plainly. I think a lot of times, if a technique confuses compiler optimization and static code analysis, it's probably going to confuse humans also.
- wsc981 4y ago
  There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it becomes kinda hard to maintain. And I tend to use an object oriented programming style (of course it also doesn't help that Lua is not typesafe). After I finish my current game, I want to try to make a game using a procedural approach. I wonder if this would solve some of the issues I see in my current code base. One of the core ideas of procedural programming is that data and functionality is not mixed in classes as we do in object oriented programming. Instead, you might have a module that contains some functions and some data objects the functions act upon. This approach would make some other aspects of game programming with Lua easier as well (e.g. serialisation), but perhaps it will make the code also easier maintainable as the size of the codebase grows. It's something I want to contemplate upon.
  - NohatCoder 4y ago
    I think it is important to understand what makes a style actually different and what is just semantics. For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability. However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different. Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way. There is no silver bullet, but best of luck, changing one's style can be hard.
greysphere 4y ago
>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. All that says is you should focus your energy on the increasing the value of .1%. It's not actually an argument to not spend any energy. It's like saying 'Astronauts only spend .1% of their time in space' or 'tomatoes only spend .1% of their existence being eaten' - that .1% is the whole point. You can debate how best to maximize that value, more features or more performance. The OP is suggesting folks are just leaving performance on the floor and then making vacuous arguments to excuse it.
Aeolun 4y ago
I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API.
- naikrovek 4y ago
  > I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API. you're right. some things are inevitably slow so we should therefore never care about performance in any situation. avoid belittling the efforts here just because they don't apply to all situations.
  - Aeolun 4y ago
    I’m making a point, not belittling the ‘efforts’ here. Though I’m inclined to believe it didn’t take the author too much effort.
deleted 4y ago
[deleted]
GuB-42 4y ago
> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. Assuming it is right, there is something called multitasking, the CPU, RAM, and most importantly, the cache is not all yours, if there is 1000 pieces of software like yours, that's 100%. You may argue that 1000 pieces of software is unreasonable, and you would mostly be right, but it happens, and mostly for the same reason software isn't optimized: quantity over quality. Another issue is that you have to make a distinction between throughput and latency. You don't have to keep up with a sustained 100 actions per second, people don't go that fast, but you definitely have to respond within tens of milliseconds, because more than that is noticeable. Latency is much harder to optimize and if you are in the critical path, these cycles may matter. A lot of devices are battery powered these days, and all these wasted cycle are reducing the battery life of the entire system. Mobile devices are crazy powerful these days, but this power is meant to be used sparingly. And even with line powered devices, I think we waste enough energy as it is... And finally, what is the point of "clean code"? Hopefully not just because it gives software architects boners. The point is usually to make software that will last: easier maintenance, less bugs, etc... But performance bugs exist too, and one of the most common software evolution is to do more of what the software already does. An image editing software will process more and bigger images, a database will store more entries and more details about each entry, documents will get larger, etc... You may even find that your users are using some feature on a scale you never intended, maybe someone is pasting entire books on your note taking app, and it may turn out working quite well... if you cared about performance. Not caring about performance is technical debt, and it may negate the advantage of using "clean code" in the first place.
naikrovek 4y ago
> I think the author is taking general advice and applying it to a niche situation. I don't. how many programs are running in your OS right now? how much CPU do you need to keep those things plus the things you need running in a performant manner? how much CPU would you need if things performed better? the answer is "less" every time. better software performance = less money required for hardware to obtain the responsiveness you require. it's important, and it's important completely independently of how it is framed here. just wait till you've seen software get slower for 30 years. to put it another way, watch hardware get faster and faster and faster for 30 years while you observe software continually consume all of the available headroom until it feels slow again. watch that happen for THREE DECADES and wait for someone to tell you that everything is fine and that someone saying "software is unnecessarily slow" is wrong because they aren't framing their argument how you think it should be framed.
julik 4y ago
What if you have a growing team of N people, and they need to be able to add shape subclasses / new shape logic all the time? As with anything this is a tradeoff. Often having decoupled code is more important than raw performance.
thescriptkiddie 4y ago
In my experience, software has been getting slower faster than hardware has been getting faster. Bringing focus back to performance would be a welcome improvement.
paxys 4y ago
Yeah, the article might be technically correct but is ultimately pointless. In almost every software engineering environment the priority is always going to be writing readable and composable code over something that runs 5 microseconds faster. All of your clever efficiency gains are anyways going to be wiped out by a single database call.
Wowfunhappy 4y ago
What you're basically saying is "modern computers are so much faster than anyone needs them to be, it's okay to make them a little slower." This works until your computer is old enough to be slower than what a majority of wealthy people (ie desirable customers) are using, at which point you need to buy a newer, faster computer, even though your current one was already "faster than anyone could reasonably need it to be". This is all harmless enough—a little disrespectful perhaps, to make other people waste their money, but not so terrible—until you consider the environmental impact of all these new computers, which the average spreadsheet absolutely should not need but does anyway. It's also an equity issue—someone on a fixed income can't necessarily afford a new machine. What would actually happen if Moore's law ended tomorrow, and we were no longer able to make computers any faster than they are today? It would really suck for scientists and hardcore gamers, but I actually think a majority of computer users would benefit The experience of someone who just writes documents and checks email would be unchanged, except that their current computers would never slow down!
photochemsyn 4y ago
So if understand correctly, insulate the performant code by wrapping it in a clean code buffer that protects it from the nefarious user input?
jackmott 4y ago
[dead]
naniwaduni 4y ago
> 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. Value of time is disproportionately weighted by user attention, which is at its highest right around when user input is happening.
osigurdson 4y ago
I think there is a relatively comfortable middle ground. High quality, readable and performant code are not mutually exclusive optimization quantities - though they will start to compete against each other in the extreme. Often, O(WTF) algorithms are complicated, full of useless fluff and hard to understand - occasionally attempting to follow Uncle Bob's unresearched and unexamined ideas.
sidlls 4y ago
Like everything else in the software industry the context does matter: at larger scales small gains in performance translate to large savings in costs (infrastructure, maintenance, etc.). Also, "clean code" (as in from the "Clean Code" book) is generally not good advice for most programs anyway. Not only does it eat performance, it's not all that great for building maintainable, extensible systems.
iamcreasy 4y ago
> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. This talk(Preventing the Collapse of Civilization) by Jonathan Blow disagrees with you. Link: https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko
yieldcrv 4y ago
always be aware of the computational time. but also be aware of where the real bottlenecks are. every place we work at is FAR more likely to scale how many compute instances we are using, than optimize the application.
croes 4y ago
>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% Wrong focus. Software time doesn't matter, user time does. Users don't want to wait, even slow typists want instand results as soon as they hit Enter.
harry8 4y ago
>Look, most modern software is spending 99.9% of the time waiting for user input That's fine, that's as it should be and isn't an interesting metric. The computer should wait for me, not the other way around. Needlessly waiting for the computer is a sign of s%&t software and not as uncommon as we'd like, huh?
DeathArrow 4y ago
I wonder if you ever used Slack or Microsoft Teams and find them fast and reliable.
22289d 4y ago
Did you read the title? He's addressing performance. And you're saying for many developers, performance is not the biggest priority. That's fine. But it doesn't make him even 0.000001% wrong. And he's not applying anything to any niche situations. You just missed his point. Performance.
smnplk 4y ago
Actually in his example, he goes down from 35 cycles to 3 cycles per shape.
dusted 4y ago
Look, most modern software is running in datacenters serving millions of users. > I think the author is taking general advice and applying it to a niche situation. I think the author is taking a general situation and applying common sense to it.
resonious 4y ago
Sure I leave apps sitting around waiting for my input quite often. But then when I do start inputting stuff, they lock up, fail to respond to my inputs, show me loading screens, blank screens, delayed responses, and otherwise waste my time. Pretty silly given how much money I pay for the hardware.
nottorp 4y ago
> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. So why isn't my browser at 0% CPU when IN THE BACKGROUND then?
DeathArrow 4y ago
While I agree with Casey, for some situations it's hard to do. You can't really develop web app in C# and Java in a simple way. Not only you have to fight the language design, but all framework and libraries are written with OOP, clean code and design patterns in mind. So you might write your code in a straight way, careful to not lose efficiency and then you are going to call slow code. So his advices are easier to follow on some scenarios than others.
coldtea 4y ago
>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. I hear this a lot, but that 0.1% when I'm actually waiting to do its calculation, it better be fast. And the rest 99.9% of time, it better not eat my battery and memory...
fartsucker69 4y ago
There is nothing more maintainable about the clean code variant either.
- gjulianm 4y ago
  There is. The first one is that the code with the switch pattern can only process simple shapes. Let's say you want to get the area of a donut now. Well, you need to change the whole code to compute the area of the union. Or imagine that there are other places in the code that need to know the area of a single shape. Do they need to copy/paste the same code?
hdhrufjdi 4y ago
I think we absolutely should care, because when the devices do something, the user still expects software to be fast. So if it is not fast enough, he buys a new device, because this is what he can do. He can't just buy the software rewritten. Usually This is bad for sustainability
meindnoch 4y ago
>most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something Bad mindset. A GFCI breaker spends 99.99999% of the time waiting with zero leakage current. Yet, when it does detect leakage current, you want the breaker to trip as quickly as possible. See where I'm going? Imagine if it would take 5 seconds from flicking a light switch until the lights actually turn on. Because the switch is waiting for user input 99.99% of the time, right? Would you install that light switch in your home?
benj111 4y ago
>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. Is it? What processes are running on your computer right now, how many are waiting for your interaction? Further the 0.1% of the time I do interact, I want the results promptly.
kilgnad 4y ago
The gaming industry is not 0.1 percent.
CuriousCosmic 4y ago
Honestly in many cases you can have your cake and eat it too if you just write in a functional or data-flow style rather than a rigorous OO style. Since this is C++, using std::algorithm or another algorithms library would let you abstract your implementation details while relying on the compiler's ability to optimise/vectorise/inline code as needed. This applies doubly so if you can rely on templates & structural typing to push your polymorphism to compile time. clang & gcc are surprisingly good at optimisation as long when you don't have to bounce off a vtable and code is clean / avoids "manual optimisation". Also while I'm not saying I don't believe the author here, I wish they would have used https://quick-bench.com/ https://quick-bench.com/ or https://godbolt.org/ https://godbolt.org/ so that readers could trivially verify the results & methodology.
berniedurfee 4y ago
100% agree. Clean code (OOP, DRY, etc) is optimized for maintainability and extensibility, not necessarily performance. In fact, I think it’s pretty well understood that clean code is a tradeoff wrt performance, at least that’s the way I’ve always understood it. Clean code works well for something like a web app that’ll need to be maintained by scores of different engineers over many years or decades. At least that’s the theory. In practice, at least some level of abstraction makes it a bit easier to rip and replace parts of the app without a total rewrite.
hburd 4y ago
I don’t think the percentage of time waiting for input has anything to do with this. Outside of video games, the way most people will see performance problems is in the latency of their UI interactions. You press a button and want to see the result as fast as possible. In other words, the user’s entire perception of your program’s performance falls into that 0.1%.
- gspencley 4y ago
  Performance is not an absolute. At the end of the day it is about user experience. From a computer science point of view, we can measure memory and CPU usage, but if the users haven't been complaining then what problems are you actually solving (at least from a product POV)? Performance for performance sake is an interesting and appealing challenge to us engineers. I was writing C code in the 90s and I miss being that close to the hardware, trying to spare every clock cycle that I could while working with machines that had sparse resources. But today I'm building SaaS products for millions of simultaneous active users. When customers complain about performance it is often not what us engineers think of as "performance." They're NOT saying things like "Your app is eating all memory on my phone" or "the rendering of this table looks choppy." It's usually issues related to server-side replication lag causing data inconsistencies or in some cases network timeouts due to slow responding services. The point is the age old advice that we were giving aspiring game programmers back in the 90s: Figure out and understand your priorities. The famous inverse square root function in the Quake III Arena source code is a great example. If memory serves me, they needed this calculation as part of their particle physics engine. The problem is that calculating inverse square roots precisely is very expensive, especially at the scale they were required to. So they exploited how 32-bit floating point numbers are represented in binary in order to do a fast, good enough approximation. This is a good example of a targeted, purposeful optimization. Back in the 90s we were obsessed over getting the most out of our hardware, especially when coding games. So we picked up all sorts of performance hacks and optimizations and learned how to code in assembly so that we could get even closer to the bare metal if we needed to. The result was impossible to understand and maintain code and so experienced engineers taught us young'uns: Write clean code first, then profile to understand what your bottlenecks are, then to make TARGETED optimizations aimed at solving performance issues in order of priority. That priority always being driven by user experience and/or scalability requirements. Anything else is premature optimization. You're speculating about where your performance bottlenecks are, and you're throwing out maintainable code for speculative reasons; not actually knowing how much of an impact your optimizations are going to have on user experience.
JustSomeNobody 4y ago
There is speed and there's the perception of speed. Some code (games) has to run fast. But most of the code we work on has to only have the perception of speed. If you're loading all of your resources and making the user stare at a twirly, you're doing it wrong.
dogen 4y ago
dude then why does most modern software feel like shit even on high performance systems? Well written video games, the kind of thing Casey works on usually, beat the hell out of basically any other category of software in terms of user responsiveness. At least of all the software I use regularly.
Applejinx 4y ago
And then when you're not waiting for user input and you have a simple keystroke… how long is it taking you to show the result on the screen?

by mabbo 4y ago

drivers99 4y ago

It still matters because in your example it will affect how smoothly the computer responds once it gets the user input.

xupybd 4y ago
But how much does that matter? If you're scaling to 1000s of users then yes. If you have a GUI for a monthly task that two administrators use, then no. The less something gets used the longer the payback time on the initial development.
- layer8 4y ago
  You’re not wrong, but today’s software is so slow/high latency so often, despite incredibly powerful hardware, that as a rule it should absolutely matter.
  - datavirtue 4y ago
    Maybe it's because they used AWS Lambda and API Gateway for the API?
- TeMPOraL 4y ago
  > If you have a GUI for a monthly task that two administrators use, then no. Fine, but be honest with yourself and admit that you are contributing a lot to making the lives of those two admins miserable. It doesn't matter if I'm using your software once a month, or once a day. If it's anything like typical modern software, it will make me hate the task I'm doing, and hate you for making it painful. In fact, shitty performance may be the very reason I'm using it monthly instead of daily - because I reorganized my whole workflow around minimizing the frequency and amount of time I have to spend using your software.
  - xupybd 4y ago
    > Fine, but be honest with yourself and admit that you are contributing a lot to making the lives of those two admins miserable The funning thing is I'm thinking of a specific case and I work closely with those admins. I even have filled in for them when they're sick. Yes I know it's a pain, they know it's a pain, and they let me know it's horrible. The only reason this one is monthly is that it's a stock take. They forgive the crappy performance as it still saves hours of work when compared to the previous manual option of entering things into multiple systems.

FooBarWidget 4y ago

Not only time to market, but also maintainability. In non-performance-critical areas, it's pretty important that when the original dev team leaves, new hires can still fix bugs and add features without breaking things.

the-smug-one 4y ago
I don't see how the code snippets presented are less maintainable.
- rrobukef 4y ago
  I do. Because I was asked to add a convex polygon and calculate its area. And now the shape_union must be rewritten from scratch. ... And maybe we want set-operations in the future...
  - Tomis02 4y ago
    > And now the shape_union must be rewritten from scratch. We spend most of our time reading code. If the Casey's code snippets are easier to reason about (which they are, especially as the codebase get larger), that's a big win. I'd imagine you want to optimize for code that is easy to (re)write, rather than minimize the number of key strokes while increasing the time spent understanding the code.
    - rrobukef 4y ago
      I'd say that the needing rewrites is bad for the future clarity of the code. So much so that people conclude the 50% performance hit is worth it to use open polymorphism (interfaces, etc.) over closed (tagged unions, algebraic data types, etc.). So I optimize for the ability to reason about over the lifetime of the project above the current ability to reason and above performance (with exceptions). What is adding a polygon going to do? Either back to the 'bad' interface to hide variable object size, extend to a tagged union with a size of the biggest datastructure - hurting cache performance each time it grows -, or an involved Object of Arrays structure - not good for clarity but great for performance. All while having to remember which field, width or height, to use for the circles radius.

AnIdiotOnTheNet 4y ago

> Look, most modern software is spending 99.9% of the time waiting for user input If that's true, why does it take forever to load and frequently fail to keep up with my input?

chpatrick 4y ago
Often it's because of bad (quadratic) algorithms, not because the code isn't micro-optimized. For example: https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times-by-70/ https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
- AnIdiotOnTheNet 4y ago
  It isn't about "micro-optimization", that's just what bad developers use as an excuse for never caring at all about performance. Casey uses the term "depessimization" to describe the process of making a program not run like shit. Modern computers are ludicrously fast, and modern developers have somehow managed to make them slow. Regardless, these programs should be spending 99% of their time waiting for user input, but instead they're working data through a mountain of abstraction layers on the faulty assumption that it is a) saving developers' time, and 2) that that is worth much more than user time.
  - loup-vaillant 4y ago
    https://www.lesswrong.com/tag/scope-insensitivity https://www.lesswrong.com/tag/scope-insensitivity Emotionally we have no idea how bad it is to waste as little as a few seconds per day for millions of users. It's just a few seconds, right? We're just forgetting to multiply those seconds by the number of users.
- morelisp 4y ago
  Accidentally super-linear algorithms happen a lot more when you hide stuff behind three layers of interfaces rather than seeing "oh, this uses a list instead of a set".

ajmurmann 4y ago

Don't forget the 90% of the processing time that it's waiting for a DB response

ilyt 4y ago
Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.
- ajmurmann 4y ago
  Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.
- whstl 4y ago
  I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries. [1] https://github.com/rails/jbuilder https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.
FridgeSeal 4y ago
I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.
- ajmurmann 4y ago
  Just work with some folks who don't know basic query optimization

bgirard 4y ago

Having done a lot of performance work on Gecko (Firefox), we generally knew where cycles mattered a lot (low level graphics like rasterization, js, dom bindings, etc...) and we used every trick there. But for the majority of the millions of LoC of the codebase these details didn't matter like you say. If we had perf issues that showed up outside they were higher level design issues like 1) trying to take a thumbnail of the page at full resolution for a tab thumbnail while loading another tab, not because the thumbnailing code itself was slow, or 2) running slow O(tabs) JS teardown during shutdown when we could run a O(~1) clean up step instead.

mquander 4y ago

> 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. That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time, and indeed, that's often because of the exact kind of overabstraction that this article criticizes (e.g. people use React and then design React component hierarchies that seem "conceptually clean" instead of ones that perform a rendering strategy that makes sense.)

PragmaticPulp 4y ago
> That's really not even close to true. Loading random websites frequently costs multiple seconds worth of local processing time Unless we’re talking about specific compute-intensive websites, this is almost certainly network loading latency. Modern web browsers are very fast. Moderns CPUs are very fast. Common, random websites aren’t churning through “multiple seconds” of CPU time just to render.
- fvdessen 4y ago
  I once optimised a SPA app that had to be really fast for usability reasons (industrial use), I replaced all the 'high level' JS patterns such as map, filter, and frontend framework things to use just if else and for loops and native dom manipulation, and it ended up more than 10x faster, each click would update the app in one frame, it was very noticeable. So yes CPU cycles do matter for websites, even with modern hardware. However the code was more verbose and needed a lot more technical know-how to understand and maintain.
  - Veliladon 4y ago
    Yep. In Rust land for instance it'd get compiled down to a for loop and be ridiculously fast. Every time you do a .map or a .filter in JS though it gets abstracted down to a function that makes an allocation for the ENTIRE ARRAY and then copies the entire array into that new array doing whatever you asked to data. The JS VM might be able to optimize some of it away but the abstraction is awful. So if you were to manually run a for loop over an array instead of iterating through it I'm not surprised you got an order of magnitude faster performance.

bakugo 4y ago

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something It's because of this mentality that almost all desktop software nowadays is bloated garbage that needs 2GB of RAM and a 5Ghz CPU to perform even the most basic task that could be done with 1/100th of the resources 20 years ago.

bitwize 4y ago
RAM and GPU are cheap. Most users aren't going to notice. Meanwhile by choosing Electron, the developers were able to roll out the app on Windows, Mac, and Linux at nearly zero marginal cost per additional platform.
- FridgeSeal 4y ago
  > Most users aren't going to notice. And other lies you can tell yourself to sleep at night. Most people notice. Very few have the capacity, power (or realise) to complain about it. They accept what they’ve been given, despite how awful it is, because they have basically no other option. A concrete example: my previous work had to use bitbucket pipelines for our docker builds. My current work uses GitHub actions. GH has my container half-built before I can even click through to the page. Bitbucket took a good minute to start. My complaints about bitbucket fell on deaf ears in the business, and no amount of leaving feedback for Atlassian to “please make builds faster” ever made the slightest amount of difference. Every time MS teams comes up that’s met with complaints about performance (among other things) so people definitely notice that. VS Code gets celebrated for “actually having decent performance”, so the bar is so low that even moderate performance apps receive high praise. Users definitely notice performance, whether the PM/business cares is a different matter, but we should stop deceiving ourselves by saying it’s alright because “users won’t notice or care”.
  - jbverschoor 4y ago
    Yup.. and if facebook didn't invest in a native mobile app, they'd been eliminated 10 years ago. Performance is a feature. Or does anyone here enjoy using an old tomtom gps where every tap on the screen takes 2 seconds? If so, please donate your beefy laptops to charity.

Cthulhu_ 4y ago

An oft recited of thumb: Make it work, make it pretty, make it fast - in that order. That is, performance bottlenecks are easier to find and fix if your code is clean to begin with. I sometimes wish performance was an issue in the projects I work with, but if it is, it's on a higher level / architectural level - things like a point-and-click API gateway performing many separate queries to the SAP server in a loop with no short-circuiting mechanism. That's billions of lines of code being executed (I'm guessing) but the performance bottleneck is in how some consultant clicked some things together. Other than school assignments, I've never had a situation where I ran into performance issues. I've had plenty of situations where I had to deal with poorly written ("unclean") code and spent extra brain cycles trying to make sense of it though.

scotty79 4y ago
I heard it as make it work make it work correctly make it work fast Pretty was never in the picture. But if anyone wants to add it, it should come last.
- treis 4y ago
  I like Make it work Make it good Make it fast
  - gregjor 4y ago
    I can measure "works" and "fast." Good can mean lots of things, it's a subjective assessment of code quality, readability, and maintainability. More experienced programmers probably have a better idea about how to achieve readable and maintainable code, but so far no one has come up with a measurable way to make code "good." Bob Martin spells out his ideas of "good" in his books but I don't find his examples particularly good, or even real-world. The only useful guide to "good" code I've come across in 40 years programming is The Elements of Programming Style, which Bob Martin has managed to expand from a thin pamphlet to multiple large books.
- yCombLinks 4y ago
  Correctly is covered by make it work

sarchertech 4y ago

>Clean code optimizes for improving time-to-market for those features Does it though? Where's the evidence for it? The vast majority of people I've worked with over the last couple decades who like to bring up "clean code", tend towards the wrong abstractions and over abstracting. I almost always prefer working with someone who writes the kind of code Casey was than someone who follows the clean code examples I've spent my career dealing with. I've seen and worked with many examples of Data Oriented Design that were far from unmaintainable or unreadable.

grumpyprole 4y ago
Completely agree. These rules simply do not lead to better outcomes in all cases. Looking at the rules and playing Devil's advocate for fun: > Prefer polymorphism to “if/else” and “switch” Algebraic data types and pattern matching (a more general version of switch), make many types of data transformation far easier to understand and maintain (versus e.g. the visitor pattern which uses adhoc polymorphism). > Code should not know about the internals of objects it’s working with This is interpreted by many as "don't expose data types". Actually some data types are safe to expose. We have a JSON library at work where the actual JSON data type is kept abstract and pattern matching cannot be used. This is despite the fact that JSON is a published (and stable) spec and therefore already exposed! > Functions should be small "Small" is a strange metric to optimise for, which is why I don't like Perl. Functions should be readable and easy to reason about. Let's optimise for "simple" instead. > Functions should do one thing This is not always practical or realistic advice. Most functions in OOP languages are procedures that will likely perform side effects in addition to returning a result (e.g. object methods). Should we also not do logging? :) > “DRY” - Don’t Repeat Yourself The cost of any abstraction must be weighed up against the repetition on a case-by-case basis. For example, many languages do not abstract the for-loop and effectively encourage users to write it out over and over again, because they have decided that the cost of abstracting it (internal iteration using higher-order functions) is too high.
- rrobukef 4y ago
  my 2 cents: I don't see algebraic data types as strictly superiour. It's just the other side of the polymorphic coin: there is open and closed ploymorphism. Open polymorphism happens with interfaces, inheritance, and typeclasses- the number is unlimited. Closed happens with ADTs - an enumeration of the cases. Open is great for extensibility: libraries can be precompiled, plugins are possible. Changes don't propagate - it is ""forward compatible"" which is great for maintaning the code. Closed on the other hand is great for matching. Finite is predictable & faster. Finite is self-contained and self-describing because it exposes the data types without shame. The purpose of the visitor pattern is now clear: it closes the open polymorphism for a finite set. Great, now we only need one kind and we still get matching. Or is it the worst of two worlds? Slow & incomprehensible and all changes propagate everywhere. So which one is better? Neither. But the reality is that all old imperative languages with polymorphism chose the open kind - the kind that adds more features because it was needed for shared libraries. Leaving you to build any pattern matching yourself and to burn yourself with the unmaintainable code. If people get burned, they learn. First they say don't do that and only then they replace the gas stove by induction.

randomdata 4y ago

> I think the author is taking general advice Not just general advice, but advice that is meant to be applied to TDD specifically. The principals of clean code are meant to help with certain challenges that arise out of TDD. It is often going to seem strange and out of place if you have rejected TDD. Remember, clean code comes from Robert C. Martin, who is a member of the XP/Agile gang. The author cherry-picking one small piece out of what Uncle Bob promotes and criticizing it in isolation without even mentioning why it is suggested with respect to the bigger picture seemed disingenuous. It does highlight that testable code may not be the most performant code, but was anyone believing otherwise? There are always tradeoffs to be made.

larsonnn 4y ago
But is this trade off not a little bit to much? It reminds me of Twitter or other companies which starting to change programming languages for performance reasons.
- randomdata 4y ago
  Is testable code a tradeoff too much? That cannot be answered globally, only locally. That's why we have engineers, after all. You could eliminate the entire profession of engineering if "which tradeoff is best" could be answered broadly without deep understanding of specific circumstances.

ilyt 4y ago

> 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. CPU meter when clicking anything on "modern" webpage proves that's a lie. Also, sure, even if "clicking on things" is maybe 1-5% vs "looking at things" THAT'S THE CRITICAL PATH. Once the app rendered a view obviously it is not doing much but user is also not waiting on anyting and is "being productive", parsing whatever is displayed. The critical path, the wasted time is the time app takes to render stuff and "but 99% of the time is not doing it" is irrelevant.

deleted 4y ago
[deleted]
izacus 4y ago
Yeah, this comment doesn't even pass a smell test as soon as you try any of the modern Electron "apps". It's all horribly performing turd that needs a 4000$ MacBook to be tolerable at best.

scotty79 4y ago

What does it matter if it does this 0.1% ten times slower than it could? Then user will have to wait for the software which slows the most expensive component of the whole work setup, the human.

adgjlsfhk1 4y ago
if the software ever takes more than 10ms to do something it is stealing time from the human. the human is the slowest part of the system so nothing else should ever make the slowest part even slower.
deleted 4y ago
[deleted]
whstl 4y ago
It matters because, to give an example, Facebook still isn't fast enough to keep up with my typing speed. And I'm not that fast.
- fifticon 4y ago
  that is probably because they are so busy keylogging every single stroke you type :-/

bilvar 4y ago

I don't know man, my TV has hardware several orders of magnitude faster and more advanced than the hardware that took us to the moon, and it takes dozens of seconds for apps like Netflix or Amazon Prime Video to load dashboards / change profiles or several seconds to do simple navigation or adjust playback. People just don't know how to properly write software these days, universities just churn out code monkeys with a vicious feedback loop occurring at the workplaces afterwards.

naikrovek 4y ago
yes. I've observed hardware get faster and faster for 30+ years and I've watched software consume all of that headroom the entire time, for no clear reason other than the way we write software is just getting worse and worse and worse.
larsonnn 4y ago
So true and so annoying.
DeathArrow 4y ago
Yes, but while you wait for the software to load, don't you have a smile on your face thinking that the developers used "clean code principles"?

yashap 4y ago

100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create massive in memory objects) - GC tuning/not enough memory - Programmer doing something dumb, like using an array when they should be using a set (and then doing a huge number of membership checks) With that being said, I have worked on the odd performance optimization where we had to get quite low level. For example, when working on vehicle routing problems, they’re super computationally heavy, need to be optimized like crazy and the hot spots can indeed involve pretty low level optimizations. But it’s been rare in the work I’ve done. This article is probably meaningful for people who work on databases, games, OSes, etc., but for most devs/apps these tips will yield zero noticeable performance improvements. Just write code in a way you find clean/maintainable/readable, and when you have perf issues, profile them and ship the appropriate fix.

jimbob45 4y ago
Well said. The aphorism "Premature optimization is the root of all evil" is meant to mean "Build it right first, then optimize only what needs to be optimized". There's really no need to start cooking spaghetti right off the bat. Clean code with some performance tweaks will be more maintainable in the long run without sacrificing performance.
- TeMPOraL 4y ago
  Casey's implied point is that clean code is already sacrificing performance from the start. And of course real life tells us that those "performance tweaks" will never happen. There is this popular wisdom that security must be designed for from the start, and cannot be just added after the fact. Performance is like that too, except worse, because you actually can add security after the fact - worst-case, you treat the entire system as untrustworthy and wrap a layer of security around it. You can't do that with performance - there is no way to sandbox your app so it goes faster. You can only profile things then rip out the slow parts and replace them with fast ones - how easy that is depends on the architecture and approach you adopt early in the project.

matheusmoreira 4y ago

Most software can barely keep up with the display's refresh rate due to their unacceptably high latencies.

AbusiveHNAdmin 4y ago

"So by violating the first rule of clean code — which is one of its central tenants" The word is TENET. Tenants rent stuff.

nikanj 4y ago

But somehow modern software (Outlook, I’m looking at you) has trouble keeping up at my typing speed, and there’s a visible delay before characters appear on the screen. It doesn’t matter what the software does 99.9% of the time, if it’s an utter pig that crucial 0.1% of the time when the user is providing input.

overgard 4y ago

I would argue that ignoring performance, a lot of "clean" code isn't really that much clearer and more maintainable at all (At least by the Robert Martin definition of "Clean Code"). Things like dependency injection and runtime polymorphism can make it really hard to trace exactly what happens in what sequence in the code, and things like asynchronous callbacks can make things like call stacks a nightmare (granted, you do need the latter a lot). Small functions can make code hard to understand because you need to jump to a lot of places and lose the thread on the sequential state (bonus points if the small functions are only ever used once by one other function). The more I work in code bases the more I find that overusing these "clean" ideas can obscure the code more than if it was just written plainly. I think a lot of times, if a technique confuses compiler optimization and static code analysis, it's probably going to confuse humans also.

wsc981 4y ago
There's some videos on the internet claiming object oriented programming is pretty bad in many situations. And lately I've been wondering if there's a kernel of truth in this statement. As an alternative, often procedural programming is advised instead. I think a lot of the clean code advice in general related to object oriented programming. I've noticed that once my Lua programs (games) grow to reasonable size, it becomes kinda hard to maintain. And I tend to use an object oriented programming style (of course it also doesn't help that Lua is not typesafe). After I finish my current game, I want to try to make a game using a procedural approach. I wonder if this would solve some of the issues I see in my current code base. One of the core ideas of procedural programming is that data and functionality is not mixed in classes as we do in object oriented programming. Instead, you might have a module that contains some functions and some data objects the functions act upon. This approach would make some other aspects of game programming with Lua easier as well (e.g. serialisation), but perhaps it will make the code also easier maintainable as the size of the codebase grows. It's something I want to contemplate upon.
- NohatCoder 4y ago
  I think it is important to understand what makes a style actually different and what is just semantics. For instance, if you write a function to do some operation on an object, you could have written that as a method instead. But ultimately it is the same code, it is unlikely that the difference matters much for either performance or readability. However if you need to do some operation on a bunch of objects you could pack each operation on the individual objects in a method, and call those methods from a main function. Or you could just put it all in one function, with as many nested loops and if statements as there needs to be. Now the difference is real, you pay in performance for a lot of function calls, and following the control flow is different. Personally I tend to prefer the one function, but sometimes part of it makes sense as its own function, in particular when I can avoid duplication that way. There is no silver bullet, but best of luck, changing one's style can be hard.

greysphere 4y ago

>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. All that says is you should focus your energy on the increasing the value of .1%. It's not actually an argument to not spend any energy. It's like saying 'Astronauts only spend .1% of their time in space' or 'tomatoes only spend .1% of their existence being eaten' - that .1% is the whole point. You can debate how best to maximize that value, more features or more performance. The OP is suggesting folks are just leaving performance on the floor and then making vacuous arguments to excuse it.

Aeolun 4y ago

I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API.

naikrovek 4y ago
> I’m always glad to save nanoseconds on my code so that we get the absolute best performance out of that 10s long call to the legacy API. you're right. some things are inevitably slow so we should therefore never care about performance in any situation. avoid belittling the efforts here just because they don't apply to all situations.
- Aeolun 4y ago
  I’m making a point, not belittling the ‘efforts’ here. Though I’m inclined to believe it didn’t take the author too much effort.

deleted 4y ago

[deleted]

GuB-42 4y ago

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. Assuming it is right, there is something called multitasking, the CPU, RAM, and most importantly, the cache is not all yours, if there is 1000 pieces of software like yours, that's 100%. You may argue that 1000 pieces of software is unreasonable, and you would mostly be right, but it happens, and mostly for the same reason software isn't optimized: quantity over quality. Another issue is that you have to make a distinction between throughput and latency. You don't have to keep up with a sustained 100 actions per second, people don't go that fast, but you definitely have to respond within tens of milliseconds, because more than that is noticeable. Latency is much harder to optimize and if you are in the critical path, these cycles may matter. A lot of devices are battery powered these days, and all these wasted cycle are reducing the battery life of the entire system. Mobile devices are crazy powerful these days, but this power is meant to be used sparingly. And even with line powered devices, I think we waste enough energy as it is... And finally, what is the point of "clean code"? Hopefully not just because it gives software architects boners. The point is usually to make software that will last: easier maintenance, less bugs, etc... But performance bugs exist too, and one of the most common software evolution is to do more of what the software already does. An image editing software will process more and bigger images, a database will store more entries and more details about each entry, documents will get larger, etc... You may even find that your users are using some feature on a scale you never intended, maybe someone is pasting entire books on your note taking app, and it may turn out working quite well... if you cared about performance. Not caring about performance is technical debt, and it may negate the advantage of using "clean code" in the first place.

naikrovek 4y ago

> I think the author is taking general advice and applying it to a niche situation. I don't. how many programs are running in your OS right now? how much CPU do you need to keep those things plus the things you need running in a performant manner? how much CPU would you need if things performed better? the answer is "less" every time. better software performance = less money required for hardware to obtain the responsiveness you require. it's important, and it's important completely independently of how it is framed here. just wait till you've seen software get slower for 30 years. to put it another way, watch hardware get faster and faster and faster for 30 years while you observe software continually consume all of the available headroom until it feels slow again. watch that happen for THREE DECADES and wait for someone to tell you that everything is fine and that someone saying "software is unnecessarily slow" is wrong because they aren't framing their argument how you think it should be framed.

julik 4y ago

What if you have a growing team of N people, and they need to be able to add shape subclasses / new shape logic all the time? As with anything this is a tradeoff. Often having decoupled code is more important than raw performance.

thescriptkiddie 4y ago

In my experience, software has been getting slower faster than hardware has been getting faster. Bringing focus back to performance would be a welcome improvement.

paxys 4y ago

Yeah, the article might be technically correct but is ultimately pointless. In almost every software engineering environment the priority is always going to be writing readable and composable code over something that runs 5 microseconds faster. All of your clever efficiency gains are anyways going to be wiped out by a single database call.

Wowfunhappy 4y ago

What you're basically saying is "modern computers are so much faster than anyone needs them to be, it's okay to make them a little slower." This works until your computer is old enough to be slower than what a majority of wealthy people (ie desirable customers) are using, at which point you need to buy a newer, faster computer, even though your current one was already "faster than anyone could reasonably need it to be". This is all harmless enough—a little disrespectful perhaps, to make other people waste their money, but not so terrible—until you consider the environmental impact of all these new computers, which the average spreadsheet absolutely should not need but does anyway. It's also an equity issue—someone on a fixed income can't necessarily afford a new machine. What would actually happen if Moore's law ended tomorrow, and we were no longer able to make computers any faster than they are today? It would really suck for scientists and hardcore gamers, but I actually think a majority of computer users would benefit The experience of someone who just writes documents and checks email would be unchanged, except that their current computers would never slow down!

photochemsyn 4y ago

So if understand correctly, insulate the performant code by wrapping it in a clean code buffer that protects it from the nefarious user input?

jackmott 4y ago

[dead]

naniwaduni 4y ago

osigurdson 4y ago

I think there is a relatively comfortable middle ground. High quality, readable and performant code are not mutually exclusive optimization quantities - though they will start to compete against each other in the extreme. Often, O(WTF) algorithms are complicated, full of useless fluff and hard to understand - occasionally attempting to follow Uncle Bob's unresearched and unexamined ideas.

sidlls 4y ago

Like everything else in the software industry the context does matter: at larger scales small gains in performance translate to large savings in costs (infrastructure, maintenance, etc.). Also, "clean code" (as in from the "Clean Code" book) is generally not good advice for most programs anyway. Not only does it eat performance, it's not all that great for building maintainable, extensible systems.

iamcreasy 4y ago

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. This talk(Preventing the Collapse of Civilization) by Jonathan Blow disagrees with you. Link: https://www.youtube.com/watch?v=ZSRHeXYDLko https://www.youtube.com/watch?v=ZSRHeXYDLko

yieldcrv 4y ago

always be aware of the computational time. but also be aware of where the real bottlenecks are. every place we work at is FAR more likely to scale how many compute instances we are using, than optimize the application.

croes 4y ago

>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% Wrong focus. Software time doesn't matter, user time does. Users don't want to wait, even slow typists want instand results as soon as they hit Enter.

harry8 4y ago

>Look, most modern software is spending 99.9% of the time waiting for user input That's fine, that's as it should be and isn't an interesting metric. The computer should wait for me, not the other way around. Needlessly waiting for the computer is a sign of s%&t software and not as uncommon as we'd like, huh?

DeathArrow 4y ago

I wonder if you ever used Slack or Microsoft Teams and find them fast and reliable.

22289d 4y ago

Did you read the title? He's addressing performance. And you're saying for many developers, performance is not the biggest priority. That's fine. But it doesn't make him even 0.000001% wrong. And he's not applying anything to any niche situations. You just missed his point. Performance.

smnplk 4y ago

Actually in his example, he goes down from 35 cycles to 3 cycles per shape.

dusted 4y ago

Look, most modern software is running in datacenters serving millions of users. > I think the author is taking general advice and applying it to a niche situation. I think the author is taking a general situation and applying common sense to it.

resonious 4y ago

Sure I leave apps sitting around waiting for my input quite often. But then when I do start inputting stuff, they lock up, fail to respond to my inputs, show me loading screens, blank screens, delayed responses, and otherwise waste my time. Pretty silly given how much money I pay for the hardware.

nottorp 4y ago

> Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. So why isn't my browser at 0% CPU when IN THE BACKGROUND then?

DeathArrow 4y ago

While I agree with Casey, for some situations it's hard to do. You can't really develop web app in C# and Java in a simple way. Not only you have to fight the language design, but all framework and libraries are written with OOP, clean code and design patterns in mind. So you might write your code in a straight way, careful to not lose efficiency and then you are going to call slow code. So his advices are easier to follow on some scenarios than others.

coldtea 4y ago

>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. I hear this a lot, but that 0.1% when I'm actually waiting to do its calculation, it better be fast. And the rest 99.9% of time, it better not eat my battery and memory...

fartsucker69 4y ago

There is nothing more maintainable about the clean code variant either.

gjulianm 4y ago
There is. The first one is that the code with the switch pattern can only process simple shapes. Let's say you want to get the area of a donut now. Well, you need to change the whole code to compute the area of the union. Or imagine that there are other places in the code that need to know the area of a single shape. Do they need to copy/paste the same code?

hdhrufjdi 4y ago

I think we absolutely should care, because when the devices do something, the user still expects software to be fast. So if it is not fast enough, he buys a new device, because this is what he can do. He can't just buy the software rewritten. Usually This is bad for sustainability

meindnoch 4y ago

>most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something Bad mindset. A GFCI breaker spends 99.99999% of the time waiting with zero leakage current. Yet, when it does detect leakage current, you want the breaker to trip as quickly as possible. See where I'm going? Imagine if it would take 5 seconds from flicking a light switch until the lights actually turn on. Because the switch is waiting for user input 99.99% of the time, right? Would you install that light switch in your home?

benj111 4y ago

>Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. Is it? What processes are running on your computer right now, how many are waiting for your interaction? Further the 0.1% of the time I do interact, I want the results promptly.

kilgnad 4y ago

The gaming industry is not 0.1 percent.

CuriousCosmic 4y ago

Honestly in many cases you can have your cake and eat it too if you just write in a functional or data-flow style rather than a rigorous OO style. Since this is C++, using std::algorithm or another algorithms library would let you abstract your implementation details while relying on the compiler's ability to optimise/vectorise/inline code as needed. This applies doubly so if you can rely on templates & structural typing to push your polymorphism to compile time. clang & gcc are surprisingly good at optimisation as long when you don't have to bounce off a vtable and code is clean / avoids "manual optimisation". Also while I'm not saying I don't believe the author here, I wish they would have used https://quick-bench.com/ https://quick-bench.com/ or https://godbolt.org/ https://godbolt.org/ so that readers could trivially verify the results & methodology.

berniedurfee 4y ago

100% agree. Clean code (OOP, DRY, etc) is optimized for maintainability and extensibility, not necessarily performance. In fact, I think it’s pretty well understood that clean code is a tradeoff wrt performance, at least that’s the way I’ve always understood it. Clean code works well for something like a web app that’ll need to be maintained by scores of different engineers over many years or decades. At least that’s the theory. In practice, at least some level of abstraction makes it a bit easier to rip and replace parts of the app without a total rewrite.

hburd 4y ago

I don’t think the percentage of time waiting for input has anything to do with this. Outside of video games, the way most people will see performance problems is in the latency of their UI interactions. You press a button and want to see the result as fast as possible. In other words, the user’s entire perception of your program’s performance falls into that 0.1%.

gspencley 4y ago
Performance is not an absolute. At the end of the day it is about user experience. From a computer science point of view, we can measure memory and CPU usage, but if the users haven't been complaining then what problems are you actually solving (at least from a product POV)? Performance for performance sake is an interesting and appealing challenge to us engineers. I was writing C code in the 90s and I miss being that close to the hardware, trying to spare every clock cycle that I could while working with machines that had sparse resources. But today I'm building SaaS products for millions of simultaneous active users. When customers complain about performance it is often not what us engineers think of as "performance." They're NOT saying things like "Your app is eating all memory on my phone" or "the rendering of this table looks choppy." It's usually issues related to server-side replication lag causing data inconsistencies or in some cases network timeouts due to slow responding services. The point is the age old advice that we were giving aspiring game programmers back in the 90s: Figure out and understand your priorities. The famous inverse square root function in the Quake III Arena source code is a great example. If memory serves me, they needed this calculation as part of their particle physics engine. The problem is that calculating inverse square roots precisely is very expensive, especially at the scale they were required to. So they exploited how 32-bit floating point numbers are represented in binary in order to do a fast, good enough approximation. This is a good example of a targeted, purposeful optimization. Back in the 90s we were obsessed over getting the most out of our hardware, especially when coding games. So we picked up all sorts of performance hacks and optimizations and learned how to code in assembly so that we could get even closer to the bare metal if we needed to. The result was impossible to understand and maintain code and so experienced engineers taught us young'uns: Write clean code first, then profile to understand what your bottlenecks are, then to make TARGETED optimizations aimed at solving performance issues in order of priority. That priority always being driven by user experience and/or scalability requirements. Anything else is premature optimization. You're speculating about where your performance bottlenecks are, and you're throwing out maintainable code for speculative reasons; not actually knowing how much of an impact your optimizations are going to have on user experience.

JustSomeNobody 4y ago

There is speed and there's the perception of speed. Some code (games) has to run fast. But most of the code we work on has to only have the perception of speed. If you're loading all of your resources and making the user stare at a twirly, you're doing it wrong.

dogen 4y ago

dude then why does most modern software feel like shit even on high performance systems? Well written video games, the kind of thing Casey works on usually, beat the hell out of basically any other category of software in terms of user responsiveness. At least of all the software I use regularly.

Applejinx 4y ago

And then when you're not waiting for user input and you have a simple keystroke… how long is it taking you to show the result on the screen?