This is why it’s so important to word such things carefully. Going by the article’s title, you either don’t exist or are no one. In essence, the post discusses away the existence of certain people and mindsets. It is not only intellectually disingenuous and wrong, it’s also rude. It’s a complete non-starter for a fruitful discussion.
Eh. I think reading beyond the title is underrated. The question is “what are you willing to sacrifice to achieve simplicity?”, which requires some explanation but does lead to the conclusion in the title if the answer is, in practice, essentially nothing.
Why are you assuming that the only way to achieve simplicity is to sacrifice something? That is not true at all. A smaller simpler (but better) design can be more feature rush than a more complicated one.
Sadly, this type of wording in titles (also in videos) are the ones that get traction pretty much every where. It cannot allow for a middle ground in the point that (hopefully) the author is trying to move across.
There is no statement about everyone that can possibly be anything but hyperbole, other than the most basic statements of fact like “no one can survive without oxygen.”
I work on safety-critical real-time stuff. We can only use simple software otherwise it becomes impossible to guarantee safety and timing. For many use cases a Linux kernel is too complex. A microprocessor is too complex.
Author here. Obviously my post’s title was inflammatory hyperbole, but to try to defend my main point for a minute:
How many things in your web development stack can you name — things that you actually like and consider to be a Good Thing — that you would be willing to sacrifice to achieve simplicity?
Performance; as long as the code isn’t doing things in a boneheaded way, it’s almost always fast enough.
Visual effects; I’m cheating here – this isn’t something I actually like, so removing it is pure upside. But it’s complexity that many many applications insist on, and removing it would be welcome.
Abstraction; code is often shorter and easier to explain when written with fewer, smaller abstractions. The abstractions may be elegant, but they aren’t worth it.
Resilience; the ability to handle faults gracefully is often fragile, getting it right is time consuming. It typically doesn’t pay it’s way. Detect the error, crash loudly, and move on. Be resilient in a small number of carefully chosen chokepoints instead of spreading error handling everywhere. Aiming for five nines of reliability isn’t worth it.
Because we can’t be arsed to find another job, we let our manager convince us to add yet another baroque curlique to a product that should have been cast in concrete and declared “done” a decade ago….
…the only ethical thing to do actually is remove obsolete features and any remaining bugs.
But it’s still selling and unless we keep adding features we will be out competed by our competitors and creating a new product in a new category is too expensive and risky…
So day by day with a sick feeling in our stomachs we add yet another wart.
And our customers, being in a market for lemons, choose the glossiest and sparkliest lemon on the rack…..
The point, as I take it, is that “simplicity”, like “performance” and other good things people often claim to want more of, is a tradeoff: if you want more “simplicity” or more “performance”, you often will have to give up at least some quantity of something else you care about to get it. And reframing in this way is not just splitting hairs, because it leads to more productive discussions. For example, instead of “why don’t developers care about performance” (unproductive) we can reframe to asking about tradeoffs between performance, which developers do care about, and other things that they also care about, and how to affect the choices being made.
I do. And I installed it myself, which means I can claim with a straight face that dishwashers are pretty simple:
there’s a hookup for power. Electricity is used to heat water and run the controller which handles the user interface, sensors and timing commands. Finally, it runs a motor for a drain pump, possibly with a small grinder.
there’s a hookup for clean water input. Water is used to clean the dishes, and incidentally to spin the distributor arms.
there’s a hookup for grey water draining.
The primary differences between consumer dishwashers are the material of the central tub, the arrangement of the racks, and the arrangement, quantity and quality of the sound insulation. Most of the sound insulation is external and replaceable.
The primary differences between consumer dishwashers are the material of the central tub, the arrangement of the racks, and the arrangement, quantity and quality of the sound insulation
Apparently this is largely due unintended consequences to EU regulation on replacement parts for white goods. This meant that it’s not economically viable to produce dishwashers that are differentiated in any meaningful way unless you are certain to sell very large numbers. They all include almost all of the same components so that they can guarantee availability of replacements for the mandated period.
Once you understand it, it’s simple.
Having flooded the floor by not putting plumbers’ tape on when connecting up the water input, I can attest to the ‘once you understand it’ bit.
I don’t think reducing competition or innovation was an intended consequence. Policy makers being naïve and not considering second-order effects is fairly normal in my experience.
I of course don’t know what’s in anyone’s mind except my own, and you could well be right. I do think that regulatory capture is a transformation that most industries have gone through, and it would require a surprising level of naivete to not anticipate it. I am not an EU resident and I don’t really know any EU politicians, so I’m not really qualified to speculate I guess.
The API is simple, for you. The complexity is hidden behind the form of a commodity. Mining, manufacturing, transport, etc. It always seems like when programmers say they like when things are simple, they generally just mean “simple, for me”, and not simple, for thee. It seems like to me a proclamation for concerns to be handled by others.
All simplicity is subjective. if you disagree, I’m going to have to point out that you are made of billions of cells, each composed of millions of molecules, each built from up to a million atoms, each made of leptons and baryons and held together by forces that require conditions approximating the first minute of the universe even to observe reliably… so nothing is simple and the word has no objective meaning.
On the subject of simplicity, I think one axis that, IME, divides people 50/50 is whether we’re talking about intentional or extensional simplicity. I.e. which one do you think is simpler in a car; Automatic transmission or manual transmission? Automatic transmission has simpler external “semantics”, while manual transmission has a simpler implementation.
Some people think Nix is unnecessary complexity because it wraps everything and does unspeakable things, but I think Nix is essential simplicity, because it does these things to make their semantics simpler.
You can’t make something simpler by piling on complexity.
This is a tautology from an extensional perspective and largely irrelevant from an intensional one. Thank you for demonstrating the other side of the argument.
A lot of developers want simplicity in the same way that a lot of clients claim they want a fast website. You respond “OK, so we can remove some of these 17 Javascript trackers and other bloat that’s making your website horribly slow?” – no, apparently those are all critical business functionality.
Can I interject and say yes, please remove all those trackers, and the other bloat?
You can, but remember that sometimes the trackers are the actual motivation behind the site’s existence.
I maintain that it is not actually a good business model to attempt to surf a margin between the payments from the advertising industry and the costs of a cloud service.
No, Google is the advertising industry, and they own their primary distributor.
If you could be Google, economically, you should. But being an entity that sells to Google’s ad network and buys from Google’s cloud service is a bad place to be.
It doesn’t even designate functions. I don’t think that we should continue to suggest that the ALGOL of the day is simple; the weird machine phenomenon ensures that any machine-to-machine encoding is going to have non-simple edges around the embedding.
I think a good test of whether you truly love simplicity is whether you are able to remove things you have added, especially code you’ve written, even when it is still providing value, because you realise it is not providing enough value.
I agree with this idea. Far too often you have one or two features that are barely used, but add the bulk of complexity to the product.
Engineers are discouraged from removing it because someone is actually paying for the product on the basis of that one functionality.
Product is discouraged from improving it because far too few people care about it. The functionality parks in this limbo, not popular enough to improve, not useless enough to remove. (Some functionalities are mandatory for a given business domain, but far fewer than we think).
We really should have a better handle for “total cost of ownership” of a piece of code tied to a value proposition. If something does not pay for itself in terms of maintenance and opportunity cost (did we take too long to ship feature B because feature A was bogging us down?) then we should be more flexible to remove it. Simplicity is a bonus, but cost reduction is really the goal.
Maybe I’m an outlier, but I love deleting my own code. My favourite PRs are when someone comes along and says ‘this complex thing you have can be replaced with this simple thing and provides the same guarantees’. I’m careful to check that the simple version is not too simple (i.e. it does solve the problem, which may be the useful subset of the problem that my code solved) but that’s then going to be the code I’m talking about at the next tea time.
I think there’s a spectrum. Features that no one uses are easy to justify removing. Features that everyone uses should not be removed (probably, there are a few exceptions, especially with respect to security). The enough value in the original quote suggests that it’s somewhere on the spectrum between these and those bits are always interesting. If there’s something that might be useful but comes with a cost and something simpler will solve the most important bit of the problem, I’d generally lean towards making that change. Especially if the simpler thing gives you enough building blocks that someone who really wants the more expensive version can add it externally.
You’re not an outlier. Between about 3 of us at work, we’ve deleted close to 100k loc at work, just in our front end alone, over the past year. Why? Because it was providing 0 value, and our tooling told us that this code was dead. We’ve even gone and removed routes that users weren’t using, and all of the associated dead code.
There’s even a casual competition between the 3 of us of who’s deleted the most, and during engineering demos if I speak at all someone will joke “How many loc did you delete this time?”
I’ve had a similar experience at my work. But I think you’ve identified a third “layer” that isn’t quite what the article is talking about: at the top, you have code that everyone agrees is worth being there. Then you have some code that perhaps isn’t pulling its weight; this is what the article is discussing. Below that, though, you have code that isn’t there intentionally at all—it’s there because someone forgot to clean it up after a refactoring pass, or because someone used create-react-app and didn’t get rid of the parts they didn’t need.
I agree. Sometimes even the people who sell the product know that the customer will never actually use that feature, but they claim that it helps making the sale. The only reason that complexity is there and “cannot be removed” is because it looks good on the website in the list of features.
Even programmers aren’t immune to that. As an example, many people flock to Clojure for its fancy STM (software transactional memory). In practice, nobody uses it, but people stay for all the other more boring things like simpler tooling than Java, good libraries etc.
I don’t want simplicity at all costs, I want thoughtfully designed software.
I want the time to evaluate my dependencies, and throw away dependencies that suck, inline the parts that matter, or just write it yourself depending on the scope of the dependency.
I want time to understand all the requirements for a given feature & ask if it’s necessary.
I want new features to ask deep questions like “how does this fit with our current system?” “Does it question some underlying principles in codebase” “is it time to re organize our codebase so that its in line with the new principles?”
I want to build something im proud of, and that usually requires a fair amount of polish. Polish is rarely inherently simple.
My experience is neither thoughtful design, nor simplicity, its just tack things on as quick as possible because agile taught us we can’t predict what the customer wants so just launch the shortest time to market version & get feedback on your halfassed solution 🫣😰
Of course we all claim to hate complexity, but it’s actually just complexity added by other people that we hate
Uff, this hits hard! When working on a particular project a few years ago I tested my “love for simplicity” by seeing how easily I could explain new stuff I added to engineers unfamiliar with the project.
In fact one of my proudest accomplishments was that the “steps to do the things” the project was supposed to do were clear enough that the project manager could refer to the actual code and see the order in which things were supposed to happen.
But then again… I’ve written so much code I’m not proud of because (and I think this might be truer in startup culture) adding a few thousand lines of code in packages and just two lines of app code is faster than the 100 LOC that it would take to do the same thing without new packages, and speed seems to trump even product software stability in some companies. (What is it, nice fast and break stuff?)
Part of the author’s impression is simply a weird type of survivorship bias. Complex systems tend to resist both simplification and replacement. Simple implementations are amenable to replacement, both incrementally and wholesale. Since one subset is more easily replaced by the other, the population of all software we work on will tend toward complexity. You could have engineers choosing simplicity at a 2:1 ratio but if every system is replaced and then replaced again most of those simple choices will no longer be evident.
It is kind of ironic that the author is a core developer of Django… :)
We all have our own idea of what simplicity means, and what stack layers we look at. For instance at some point when I was a student (~ 15 years ago) I switched my main language / OS from Python on Linux to Lua on Minix 3 for simplicity reasons. But I was still running on x86 hardware I could never understand fully.
The ultimate simplicity is not using a computer at all. So it’s all about trade-offs, and trade-offs depend on context. I stopped using LuaJIT for personal stuff but I would at work without hesitation, I write neural networks code from scratch or play with tinygrad but at work I use PyTorch, and so on.
I feel like Django hasn’t aged as well as it could have because they tried to moderate the excesses of Rails. Instead of convention over configuration, it was a conventional configuration. But as time has gone on, I think the market bifurcated and people who wanted luxury automated everything went to Rails and everyone else went to a stripped down API like Flask, Express, Fast API, Sinatra, etc. There aren’t as many people in the middle who want some but not all of the luxury automation.
Also, the ORM and templating languages both got overtaken by better ones (Alchemy, Jinja), so using stock Django requires “settling” for something not as good or fighting with the defaults to override it. (Which can be done, but then you ask why you’re not on FastAPI or whatever.)
When designing his compiler for the Oberon system, the one criterion he had to measure its quality was speed of self-compilation. This sacrificed a number of optimisation, though not all of them: while all optimisations made the compiler more complex, they also tended to generate faster code. More code takes longer to compile, but it can be compensated by the faster generated code. So some optimisations did get in. On the other hand, some of Wirth’s students did watch in horror as he removed parts of the compiler, made generated code worse, but enough code was removed that self-compilation was faster.
Personally I like this criterion: it implicitly ascribes a cost to complexity, and makes sure that cost is paid for in actual benefit. Though to be honest Wirth himself says his approach is probably not worth it in today’s world where processors are so much more complicated, faster, and presumably, harder to properly optimise for (not sure about that last one though, my guess is that out of order execution makes optimisations easier, not harder).
When I started using Minix 3, before it switched to ELF and replaced most of the userland with that of NetBSD, the C compiler was called ack.
When you installed the system, its source code came with it. You could just go to /usr/src and there was a makefile to recompile everything from itself.
I went there, and did so. As I remember it it took a few seconds. I was coming from Gentoo so I had already recompiled entire systems, but I was used to compilation times measured in hours, so I assumed there was some kind of error.
There wasn’t. It was just that fast. That is the power of simplicity, both of the compiler itself which wasn’t optimizing much and of the whole system, which was therefore a bliss to compile.
When you installed the system, its source code came with it. You could just go to /usr/src and there was a makefile to recompile everything from itself.
For what it’s worth, that’s the case for all of the BSD family (it may be an optional install but it’s usually in the default). You can build the entire base system (kernel and userland) from here.
Last time I did it on FreeBSD was in a UTM VM on a MacBook Pro and it took 15 minutes (about 10 of which was compiling LLVM). It’s a bit longer if you also bootstrap the toolchain that it uses to compile itself (which you need to do if building on a much older version). Definitely more than a few seconds but also much less than hours.
I remain unconvinced that fast builds are worth the lower performance. Especially over large server deployments, a 10% performance increase translates to an appreciable reduction in the total number of computers that you need to buy / rent and is well worth spending a couple of CPU hours to achieve. Similarly on mobile, it translates to better battery life.
I remain unconvinced that fast builds are worth the lower performance.
This is highly dependent on the compile/run ratio, which is itself dependent (more loosely) on how many non-programming users you have, relative to how many developers. If the only user is Niklaus Wirth, the “make bootstrap as fast as possible” is a great heuristic. If you distribute to hundreds of users that instantly becomes much more questionable.
I believe at the time Wirth worked with Oberon, his heuristic wasn’t too bad: his computers were limited to his university after all. Nowadays however this is very different… except maybe for debug builds. When writing a program compilation often takes a good chunk of the edit/compile/test cycle, and minimising the compile + run phase probably involves removing a lot of optimisations.
You’d better be sure your release build behaves the same as the debug build though.
You may already know, but if not TCCBOOT could compile, link & run the Linux kernel in just a few seconds on some old Pentium4. tcc still works on x86_64 and I use its community-maintained mob branch as a back end for the Nim compiler almost every day. { It’s about 5-10X faster than gcc -O0, but its generated code runs about 3X slower (both ratios obviously just vague ballpark things - obviously it’s sensitive to exact use cases). }
I mean, yeah, no one really cares about abstract concepts? What we really want is (what we think/hope will be) the concrete consequences of striving for said abstract concepts.
But even that is secondary to solving the damn problem. It is, was, and it will always be, hard to argue for temporarily de-prioritizing solving the damn problem in order to address long term, less obvious, issues.
I don’t relate to this, I’ve seen plenty of programmers (I’d say most of the experienced ones I’ve met) that genuinely take pride in the amount of code they delete rather than in what they add. That consider removing dependencies a win and are reluctant about adding new without a reasoned tradeoff analysis (not to mention architecture components). That are always looking for opportunities to decommission systems so they don’t have to maintain them anymore.
I personally like removing software so much that I’m always in the lookout for opportunities to simplify the organization and the processes so that the software can be simplified (or removed) in turn.
Possibly, if you count the complexity of a web browser, but it’s possible to achieve a lot in web development with very little code. I think it might be more fair to say that the ecosystem selects for people who favour complexity but I don’t think that’s limited to web development. It’s much easier to demonstrate impact if you’ve added a load of complexity than if you’ve made something clean and more likely to be bug free and so the people that pile on heaps of crap are often the ones that get promoted and become architects, where they have the same incentives. Even in the F/OSS world, adding a small feature to an existing project that lets it solve a broader range of problems is far less likely to get to visibility than producing a huge new project that subsumes the responsibilities of the old one.
Absolutely. That dynamic in the FOSS world also affects the quality of contributions to existing projects, and is especially rampant on GitHub; one of the many ways picking GitHub to attract contributors is a devil’s bargain.
Not with that attitude! I’m a web developer and I value simplicity. It’s actually a great time for the web as long as you just avoid all the crap that makes it complex for no benefit.
Avoiding complex things that add “no benefit” seems to be the mindset of the developers referenced in the article, who only think they value simplicity. How do you distinguish yourself from them?
The unstated major premise of this argument is that the complexity in question is the simplest possible implementation required to achieve the given functionality, and a simpler design would not provide the same benefits.
I’m highly skeptical that we’re dealing with that situation, in most cases.
Most users want „easy“. If you build something, you start „simple“. Many advertise the simplicity of their early versions and users understand „easy“. Then the users complain about missing features for their complex use cases. Over time they get added. Most fail to keep it simple along the way to easy because it is much more work. Then soon someone else comes along to promote something new and „simple“…
Put more than 2 people into a room and they’ll automagically come up with the most complex bullshit you’ve ever seen.
Unless of course you have a barbarian in the room. Barbarians don’t give a shit about beautiful, or perfect or flowers. They just want to bash in some skulls and get the thing done.
I want simplicity. The reason we get complexity is that software is a team effort. What I think is important is not what you think, and all of us have that one clever hack that is “worth it,” or a fix for an edge case that complicates the code base. These nuances add up to a complicated code base and every nuance has a constituency.
I want simplicity but I’m less eager to go around killing of everyone’s pet solutions.
It is a good point that the best way to get simplicity is to be able to say no to some features. It’s better to build 80% of the required feature set than to end up delivering 20% because of all the complexity that one feature introduced.
But one thing I feel this and similar articles disregard, is how hard it is for beginners to see much simpler paths that don’t come with any additional cost. In other words, much can be gained from training to avoid accidental complexity.
I actually want simplicity.
This is why it’s so important to word such things carefully. Going by the article’s title, you either don’t exist or are no one. In essence, the post discusses away the existence of certain people and mindsets. It is not only intellectually disingenuous and wrong, it’s also rude. It’s a complete non-starter for a fruitful discussion.
Eh. I think reading beyond the title is underrated. The question is “what are you willing to sacrifice to achieve simplicity?”, which requires some explanation but does lead to the conclusion in the title if the answer is, in practice, essentially nothing.
OK, sure. “What are you willing to sacrifice to achieve simplicity?” would still have been a better title.
I did read the article and it doesn’t change the fact that the title is wrong and flamebait.
Why are you assuming that the only way to achieve simplicity is to sacrifice something? That is not true at all. A smaller simpler (but better) design can be more feature rush than a more complicated one.
I’m not, I’m simply stating what the article says.
But I do think almost everyone would agree that simplicity is better if there’s no trade-off necessary to achieve it.
Sadly, this type of wording in titles (also in videos) are the ones that get traction pretty much every where. It cannot allow for a middle ground in the point that (hopefully) the author is trying to move across.
There is no statement about everyone that can possibly be anything but hyperbole, other than the most basic statements of fact like “no one can survive without oxygen.”
No one should be offended by hyperbole.
(ba dum tss)
I work on safety-critical real-time stuff. We can only use simple software otherwise it becomes impossible to guarantee safety and timing. For many use cases a Linux kernel is too complex. A microprocessor is too complex.
Author here. Obviously my post’s title was inflammatory hyperbole, but to try to defend my main point for a minute:
How many things in your web development stack can you name — things that you actually like and consider to be a Good Thing — that you would be willing to sacrifice to achieve simplicity?
I can’t think of many for myself.
Performance; as long as the code isn’t doing things in a boneheaded way, it’s almost always fast enough.
Visual effects; I’m cheating here – this isn’t something I actually like, so removing it is pure upside. But it’s complexity that many many applications insist on, and removing it would be welcome.
Abstraction; code is often shorter and easier to explain when written with fewer, smaller abstractions. The abstractions may be elegant, but they aren’t worth it.
Resilience; the ability to handle faults gracefully is often fragile, getting it right is time consuming. It typically doesn’t pay it’s way. Detect the error, crash loudly, and move on. Be resilient in a small number of carefully chosen chokepoints instead of spreading error handling everywhere. Aiming for five nines of reliability isn’t worth it.
the list goes on.
Obviously my reply is inflammatory hyperbole….
Because we can’t be arsed to find another job, we let our manager convince us to add yet another baroque curlique to a product that should have been cast in concrete and declared “done” a decade ago….
…the only ethical thing to do actually is remove obsolete features and any remaining bugs.
But it’s still selling and unless we keep adding features we will be out competed by our competitors and creating a new product in a new category is too expensive and risky…
So day by day with a sick feeling in our stomachs we add yet another wart.
And our customers, being in a market for lemons, choose the glossiest and sparkliest lemon on the rack…..
…and so life gets shittier for everyone.
I already achieved simplicity. No frameworks and using basic text editors. I guess…
Hyperbole, yes. Inflammatory, no.
I would sacrifice the Lisp and ML families. I would sacrifice
sedandjq. I would sacrifice Nix.So, what are you willing to give up for it?
The point, as I take it, is that “simplicity”, like “performance” and other good things people often claim to want more of, is a tradeoff: if you want more “simplicity” or more “performance”, you often will have to give up at least some quantity of something else you care about to get it. And reframing in this way is not just splitting hairs, because it leads to more productive discussions. For example, instead of “why don’t developers care about performance” (unproductive) we can reframe to asking about tradeoffs between performance, which developers do care about, and other things that they also care about, and how to affect the choices being made.
Simply said
Most people don’t want simplicity, but the author just put “nobody” because it was simpler.
Do you own a dishwasher?
I do. And I installed it myself, which means I can claim with a straight face that dishwashers are pretty simple:
there’s a hookup for power. Electricity is used to heat water and run the controller which handles the user interface, sensors and timing commands. Finally, it runs a motor for a drain pump, possibly with a small grinder.
there’s a hookup for clean water input. Water is used to clean the dishes, and incidentally to spin the distributor arms.
there’s a hookup for grey water draining.
The primary differences between consumer dishwashers are the material of the central tub, the arrangement of the racks, and the arrangement, quantity and quality of the sound insulation. Most of the sound insulation is external and replaceable.
Once you understand it, it’s simple.
Apparently this is largely due unintended consequences to EU regulation on replacement parts for white goods. This meant that it’s not economically viable to produce dishwashers that are differentiated in any meaningful way unless you are certain to sell very large numbers. They all include almost all of the same components so that they can guarantee availability of replacements for the mandated period.
Having flooded the floor by not putting plumbers’ tape on when connecting up the water input, I can attest to the ‘once you understand it’ bit.
Surely that’s an intended consequence. Policymakers would have to be quite naive not to expect that outcome.
This is speculation, of course, please don’t take it too seriously. Your point stands, regardless.
I don’t think reducing competition or innovation was an intended consequence. Policy makers being naïve and not considering second-order effects is fairly normal in my experience.
Sorry for the delay in responding.
I of course don’t know what’s in anyone’s mind except my own, and you could well be right. I do think that regulatory capture is a transformation that most industries have gone through, and it would require a surprising level of naivete to not anticipate it. I am not an EU resident and I don’t really know any EU politicians, so I’m not really qualified to speculate I guess.
The API is simple, for you. The complexity is hidden behind the form of a commodity. Mining, manufacturing, transport, etc. It always seems like when programmers say they like when things are simple, they generally just mean “simple, for me”, and not simple, for thee. It seems like to me a proclamation for concerns to be handled by others.
All simplicity is subjective. if you disagree, I’m going to have to point out that you are made of billions of cells, each composed of millions of molecules, each built from up to a million atoms, each made of leptons and baryons and held together by forces that require conditions approximating the first minute of the universe even to observe reliably… so nothing is simple and the word has no objective meaning.
I know.
On the subject of simplicity, I think one axis that, IME, divides people 50/50 is whether we’re talking about intentional or extensional simplicity. I.e. which one do you think is simpler in a car; Automatic transmission or manual transmission? Automatic transmission has simpler external “semantics”, while manual transmission has a simpler implementation.
Some people think Nix is unnecessary complexity because it wraps everything and does unspeakable things, but I think Nix is essential simplicity, because it does these things to make their semantics simpler.
New Jersey style vs MIT approach.
https://dreamsongs.com/WorseIsBetter.html
I think nix is essential complexity, because wrapping everything is spackle over a cracked foundation.
You can’t make something simpler by piling on complexity.
This is a tautology from an extensional perspective and largely irrelevant from an intensional one. Thank you for demonstrating the other side of the argument.
Can I interject and say yes, please remove all those trackers, and the other bloat?
You can, but remember that sometimes the trackers are the actual motivation behind the site’s existence.
I maintain that it is not actually a good business model to attempt to surf a margin between the payments from the advertising industry and the costs of a cloud service.
At first blush I agree, but then I thought about it a bit more and… isn’t that business model literally all of Google?
No, Google is the advertising industry, and they own their primary distributor.
If you could be Google, economically, you should. But being an entity that sells to Google’s ad network and buys from Google’s cloud service is a bad place to be.
Drew DeVault actually wants simplicity. Look at Hare:
These all give up a lot of tangible value in pursuit of simplicity. But this guy puts his money where his mouth is in terms of simplicity for sure.
It doesn’t even designate functions. I don’t think that we should continue to suggest that the ALGOL of the day is simple; the weird machine phenomenon ensures that any machine-to-machine encoding is going to have non-simple edges around the embedding.
I agree with this idea. Far too often you have one or two features that are barely used, but add the bulk of complexity to the product.
Engineers are discouraged from removing it because someone is actually paying for the product on the basis of that one functionality.
Product is discouraged from improving it because far too few people care about it. The functionality parks in this limbo, not popular enough to improve, not useless enough to remove. (Some functionalities are mandatory for a given business domain, but far fewer than we think).
We really should have a better handle for “total cost of ownership” of a piece of code tied to a value proposition. If something does not pay for itself in terms of maintenance and opportunity cost (did we take too long to ship feature B because feature A was bogging us down?) then we should be more flexible to remove it. Simplicity is a bonus, but cost reduction is really the goal.
Maybe I’m an outlier, but I love deleting my own code. My favourite PRs are when someone comes along and says ‘this complex thing you have can be replaced with this simple thing and provides the same guarantees’. I’m careful to check that the simple version is not too simple (i.e. it does solve the problem, which may be the useful subset of the problem that my code solved) but that’s then going to be the code I’m talking about at the next tea time.
I think that’s not really what this is about, it seems to be more about ruthlessly cutting features, even if they are useful to someone.
I think there’s a spectrum. Features that no one uses are easy to justify removing. Features that everyone uses should not be removed (probably, there are a few exceptions, especially with respect to security). The enough value in the original quote suggests that it’s somewhere on the spectrum between these and those bits are always interesting. If there’s something that might be useful but comes with a cost and something simpler will solve the most important bit of the problem, I’d generally lean towards making that change. Especially if the simpler thing gives you enough building blocks that someone who really wants the more expensive version can add it externally.
You’re not an outlier. Between about 3 of us at work, we’ve deleted close to 100k loc at work, just in our front end alone, over the past year. Why? Because it was providing 0 value, and our tooling told us that this code was dead. We’ve even gone and removed routes that users weren’t using, and all of the associated dead code.
There’s even a casual competition between the 3 of us of who’s deleted the most, and during engineering demos if I speak at all someone will joke “How many loc did you delete this time?”
I’ve had a similar experience at my work. But I think you’ve identified a third “layer” that isn’t quite what the article is talking about: at the top, you have code that everyone agrees is worth being there. Then you have some code that perhaps isn’t pulling its weight; this is what the article is discussing. Below that, though, you have code that isn’t there intentionally at all—it’s there because someone forgot to clean it up after a refactoring pass, or because someone used create-react-app and didn’t get rid of the parts they didn’t need.
I agree. Sometimes even the people who sell the product know that the customer will never actually use that feature, but they claim that it helps making the sale. The only reason that complexity is there and “cannot be removed” is because it looks good on the website in the list of features.
Even programmers aren’t immune to that. As an example, many people flock to Clojure for its fancy STM (software transactional memory). In practice, nobody uses it, but people stay for all the other more boring things like simpler tooling than Java, good libraries etc.
Absolutely agreed.
I don’t want simplicity at all costs, I want thoughtfully designed software.
I want the time to evaluate my dependencies, and throw away dependencies that suck, inline the parts that matter, or just write it yourself depending on the scope of the dependency.
I want time to understand all the requirements for a given feature & ask if it’s necessary.
I want new features to ask deep questions like “how does this fit with our current system?” “Does it question some underlying principles in codebase” “is it time to re organize our codebase so that its in line with the new principles?”
I want to build something im proud of, and that usually requires a fair amount of polish. Polish is rarely inherently simple.
My experience is neither thoughtful design, nor simplicity, its just tack things on as quick as possible because agile taught us we can’t predict what the customer wants so just launch the shortest time to market version & get feedback on your halfassed solution 🫣😰
Uff, this hits hard! When working on a particular project a few years ago I tested my “love for simplicity” by seeing how easily I could explain new stuff I added to engineers unfamiliar with the project.
In fact one of my proudest accomplishments was that the “steps to do the things” the project was supposed to do were clear enough that the project manager could refer to the actual code and see the order in which things were supposed to happen.
But then again… I’ve written so much code I’m not proud of because (and I think this might be truer in startup culture) adding a few thousand lines of code in packages and just two lines of app code is faster than the 100 LOC that it would take to do the same thing without new packages, and speed seems to trump even product software stability in some companies. (What is it, nice fast and break stuff?)
Part of the author’s impression is simply a weird type of survivorship bias. Complex systems tend to resist both simplification and replacement. Simple implementations are amenable to replacement, both incrementally and wholesale. Since one subset is more easily replaced by the other, the population of all software we work on will tend toward complexity. You could have engineers choosing simplicity at a 2:1 ratio but if every system is replaced and then replaced again most of those simple choices will no longer be evident.
If we actually wanted simplicity, we wouldn’t be writing software.
It is kind of ironic that the author is a core developer of Django… :)
We all have our own idea of what simplicity means, and what stack layers we look at. For instance at some point when I was a student (~ 15 years ago) I switched my main language / OS from Python on Linux to Lua on Minix 3 for simplicity reasons. But I was still running on x86 hardware I could never understand fully.
The ultimate simplicity is not using a computer at all. So it’s all about trade-offs, and trade-offs depend on context. I stopped using LuaJIT for personal stuff but I would at work without hesitation, I write neural networks code from scratch or play with tinygrad but at work I use PyTorch, and so on.
Django is not that complex, but the developers sure hate composability and fight it with fire on every occasion.
I feel like Django hasn’t aged as well as it could have because they tried to moderate the excesses of Rails. Instead of convention over configuration, it was a conventional configuration. But as time has gone on, I think the market bifurcated and people who wanted luxury automated everything went to Rails and everyone else went to a stripped down API like Flask, Express, Fast API, Sinatra, etc. There aren’t as many people in the middle who want some but not all of the luxury automation.
Also, the ORM and templating languages both got overtaken by better ones (Alchemy, Jinja), so using stock Django requires “settling” for something not as good or fighting with the defaults to override it. (Which can be done, but then you ask why you’re not on FastAPI or whatever.)
Niklaus Wirth actually wants simplicity.
When designing his compiler for the Oberon system, the one criterion he had to measure its quality was speed of self-compilation. This sacrificed a number of optimisation, though not all of them: while all optimisations made the compiler more complex, they also tended to generate faster code. More code takes longer to compile, but it can be compensated by the faster generated code. So some optimisations did get in. On the other hand, some of Wirth’s students did watch in horror as he removed parts of the compiler, made generated code worse, but enough code was removed that self-compilation was faster.
Personally I like this criterion: it implicitly ascribes a cost to complexity, and makes sure that cost is paid for in actual benefit. Though to be honest Wirth himself says his approach is probably not worth it in today’s world where processors are so much more complicated, faster, and presumably, harder to properly optimise for (not sure about that last one though, my guess is that out of order execution makes optimisations easier, not harder).
When I started using Minix 3, before it switched to ELF and replaced most of the userland with that of NetBSD, the C compiler was called ack.
When you installed the system, its source code came with it. You could just go to
/usr/srcand there was a makefile to recompile everything from itself.I went there, and did so. As I remember it it took a few seconds. I was coming from Gentoo so I had already recompiled entire systems, but I was used to compilation times measured in hours, so I assumed there was some kind of error.
There wasn’t. It was just that fast. That is the power of simplicity, both of the compiler itself which wasn’t optimizing much and of the whole system, which was therefore a bliss to compile.
For what it’s worth, that’s the case for all of the BSD family (it may be an optional install but it’s usually in the default). You can build the entire base system (kernel and userland) from here.
Last time I did it on FreeBSD was in a UTM VM on a MacBook Pro and it took 15 minutes (about 10 of which was compiling LLVM). It’s a bit longer if you also bootstrap the toolchain that it uses to compile itself (which you need to do if building on a much older version). Definitely more than a few seconds but also much less than hours.
I remain unconvinced that fast builds are worth the lower performance. Especially over large server deployments, a 10% performance increase translates to an appreciable reduction in the total number of computers that you need to buy / rent and is well worth spending a couple of CPU hours to achieve. Similarly on mobile, it translates to better battery life.
This is highly dependent on the compile/run ratio, which is itself dependent (more loosely) on how many non-programming users you have, relative to how many developers. If the only user is Niklaus Wirth, the “make bootstrap as fast as possible” is a great heuristic. If you distribute to hundreds of users that instantly becomes much more questionable.
I believe at the time Wirth worked with Oberon, his heuristic wasn’t too bad: his computers were limited to his university after all. Nowadays however this is very different… except maybe for debug builds. When writing a program compilation often takes a good chunk of the edit/compile/test cycle, and minimising the compile + run phase probably involves removing a lot of optimisations.
You’d better be sure your release build behaves the same as the debug build though.
You may already know, but if not TCCBOOT could compile, link & run the Linux kernel in just a few seconds on some old Pentium4.
tccstill works on x86_64 and I use its community-maintained mob branch as a back end for the Nim compiler almost every day. { It’s about 5-10X faster thangcc -O0, but its generated code runs about 3X slower (both ratios obviously just vague ballpark things - obviously it’s sensitive to exact use cases). }I mean, yeah, no one really cares about abstract concepts? What we really want is (what we think/hope will be) the concrete consequences of striving for said abstract concepts.
But even that is secondary to solving the damn problem. It is, was, and it will always be, hard to argue for temporarily de-prioritizing solving the damn problem in order to address long term, less obvious, issues.
I don’t relate to this, I’ve seen plenty of programmers (I’d say most of the experienced ones I’ve met) that genuinely take pride in the amount of code they delete rather than in what they add. That consider removing dependencies a win and are reluctant about adding new without a reasoned tradeoff analysis (not to mention architecture components). That are always looking for opportunities to decommission systems so they don’t have to maintain them anymore.
I personally like removing software so much that I’m always in the lookout for opportunities to simplify the organization and the processes so that the software can be simplified (or removed) in turn.
Arguable if we take “no one” to mean “no web developer.” Someone who actually values simplicity would not specialize in web development.
Possibly, if you count the complexity of a web browser, but it’s possible to achieve a lot in web development with very little code. I think it might be more fair to say that the ecosystem selects for people who favour complexity but I don’t think that’s limited to web development. It’s much easier to demonstrate impact if you’ve added a load of complexity than if you’ve made something clean and more likely to be bug free and so the people that pile on heaps of crap are often the ones that get promoted and become architects, where they have the same incentives. Even in the F/OSS world, adding a small feature to an existing project that lets it solve a broader range of problems is far less likely to get to visibility than producing a huge new project that subsumes the responsibilities of the old one.
Absolutely. That dynamic in the FOSS world also affects the quality of contributions to existing projects, and is especially rampant on GitHub; one of the many ways picking GitHub to attract contributors is a devil’s bargain.
Not with that attitude! I’m a web developer and I value simplicity. It’s actually a great time for the web as long as you just avoid all the crap that makes it complex for no benefit.
Avoiding complex things that add “no benefit” seems to be the mindset of the developers referenced in the article, who only think they value simplicity. How do you distinguish yourself from them?
The unstated major premise of this argument is that the complexity in question is the simplest possible implementation required to achieve the given functionality, and a simpler design would not provide the same benefits.
I’m highly skeptical that we’re dealing with that situation, in most cases.
Simplicity is not an output, simplicity is an input.
(Incidentally, I believe Deming says the same about quality.)
Simple is not easy.
Most users want „easy“. If you build something, you start „simple“. Many advertise the simplicity of their early versions and users understand „easy“. Then the users complain about missing features for their complex use cases. Over time they get added. Most fail to keep it simple along the way to easy because it is much more work. Then soon someone else comes along to promote something new and „simple“…
Put more than 2 people into a room and they’ll automagically come up with the most complex bullshit you’ve ever seen.
Unless of course you have a barbarian in the room. Barbarians don’t give a shit about beautiful, or perfect or flowers. They just want to bash in some skulls and get the thing done.
I want simplicity. The reason we get complexity is that software is a team effort. What I think is important is not what you think, and all of us have that one clever hack that is “worth it,” or a fix for an edge case that complicates the code base. These nuances add up to a complicated code base and every nuance has a constituency.
I want simplicity but I’m less eager to go around killing of everyone’s pet solutions.
It is a good point that the best way to get simplicity is to be able to say no to some features. It’s better to build 80% of the required feature set than to end up delivering 20% because of all the complexity that one feature introduced.
But one thing I feel this and similar articles disregard, is how hard it is for beginners to see much simpler paths that don’t come with any additional cost. In other words, much can be gained from training to avoid accidental complexity.