6 ms·

The worse is better essay is a great read: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html Over time, I have come

The worse is better essay is a great read: https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html Over time, I have come to believe that the problem is overly-aggressive abstraction. It is very tempting for most developers, especially good developers, to reach for abstraction as soon as things get complicated. And this can pay off very, very well in some cases. However, too much abstraction in a system leads to a very, well, abstract code base that becomes hard to get a handle on: there's no there there. You see this in the java world with AbstractFactoryBuilderLookupServiceBuilders and so forth, and with very elaborate type setups in functional programming languages. Concretizing the crucial bits of your system, even if that means a few large, complex and gronky methods or classes, ends up often making things more understandable and maintainable and, certainly, debuggable. John Ousterhout wrote a book that makes this point as well, advocating for "deep" rather than "shallow" classes and methods: https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design https://www.goodreads.com/en/book/show/39996759-a-philosophy...

rob74 4y ago
The kind of codebase you describe with "elaborate type setups" (multiple levels of inheritance, design patterns like Facade used for "decoupling" etc.) make it very hard to read the code and understand what it's doing (unless it's very well documented), and because of that also make it harder to extend without resorting to kludges. Or, if you want to extend it in a way the original designer didn't foresee, you now have to change 5 different classes to be able to access some private property in some class.
funcDropShadow 4y ago
> Over time, I have come to believe that the problem is overly-aggressive abstraction. Sometimes, yes, overly-aggressive abstractions are a problem. But the author describes policies of v1 and v2 of the linker. And I would say the most critical difference between them is, that the authors of v2 had a better understanding of the requirements that actually mattered. Therefore they were in a better situation to evaluate the architecture and they were able to make better trade-offs. Deciding to trust object files as inputs might raise a red flag for some people. In principle it could allow attacks/exploits of the linker. But in reality for most threat models this does not matter. Because the compiler generating object files has the same level of trust as the linker. Companies that want to provide an elf linker as a service product are out of scope. Deciding what is in scope and what is out of scope is probably one of the hardest decisions in product engineering. Because many of us software engineers lean towards perfectionism or, especially inexperienced developers are searching for the silver bullet, that set of rules that enables them to develop every product successfully. [edited typos]
ncmncm 4y ago
I suspect the "Worse is Better" essay has caused untold harm. It is written from the standpoint of a purist offended that the world doesn't appreciate purity, complaining that the things people end up using are built by pragmatic people. The lesson seems to be that doing things better is punished. But that is the wrong lesson. The correct lesson is that the real world is not obliged to conform to your personal model of "better". You have a personal obligation to continuously adapt your model to match the real world. This is the model of science, and is opposed to Platonism. After you have adjusted your model, it is certain to still not be right, and need further adjustment. Usually "the world" you are obliged to adjust to has its own problems. There are powerful forces making us favor accommodating a Microsoft execution environment, even though that execution environment has always been a cesspit. It represents its own poor abstraction. Posix file system semantics are another example. Von Neumann architecture and the C abstract machine are not the only, or best way to organize computational resources. It is important to recognize when somebody else's pragmatic failure threatens to taint your own models. Lisp, RG's hobbyhorse, didn't get sidelined because of Philistines. Lisp turned out not to be better, despite how strongly RG felt about it. Instead of figuring out what about Lisp was not right, he called things that were, along axes that matter, more right "worse", preserving his personal model and lessening readers' ability to reason about merit.
- recursivedoubts 4y ago
  I don't agree at all. I think he was able to give a clear and accurate analysis of why lisp failed, despite liking the language so much. He also wrote critical responses to his own essay under a pseudonym, with a back and forth that is quite funny and demonstrates the ability to understand both sides of the argument. In "Worse is better" he explicitly mentions how that approach favors real-world application, because it is so simple it is fast and is "good enough" and then can be moved to 90% of the right thing. All of this is to say: I don't agree with you, but I also agree with you and I suspect he would as well, with qualifications. And he would probably also disagree with you.
  - fileeditview 4y ago
    Perfect user name! Also this was my comment of the day.. nay week at least!
polotics 4y ago
Also, I often see developers running to the abstractions they know (cough design patterns...) mostly because they're very afraid of acknowledging they haven't grasped the real complexity of a domain. By the time a pragmatic efficient design emerges, you're on the second or third rewrite...
tynpeddler 4y ago
One of the best programming aphorisms I've heard is "Everything in programming can be solved with another layer of abstraction except for the problem of to many layers of abstraction."
- layer8 4y ago
  https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_softw...
Bjartr 4y ago
It can be worth understanding why the Java ecosystem evolved that way. It's not because simplicity wasn't valued, but rather it's not code simplicity that's valued. Rather, much of the Java ecosystem is designed to allow dozens of independent teams, totaling hundreds of developers, within a company (or across companies) to build their small piece of the application, with whatever build process is used by them. Then you put all the .jar files in one bundle, and the AbstractFactoryBuilderLookupServiceBuilders puts the pieces together at runtime. It's complex as hell code-wise, but it simplifies the amount of cross-team/cross-company alignment and synchronization that has to happen in order to cut a new version of the application containing hotfix 8495 for the part of the app maintained by Steve's team. There's actually a decent parallel between that and Microservices. Microservices make maintenance of the whole more complicated by introducing the network between pieces, but allow each piece more flexibility in how it's developed.
robocat 4y ago
From https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html: The folks at Lucid were starting to get a little worried because I would bring them review drafts of papers arguing for worse is better, and later I would bring them rebuttals against myself. One fellow was seriously nervous that I might have a mental disease. after over a decade of thinking and speaking about it . . . [I wrote] "Back to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called "Back to the Future: Worse (Still) is Better!" which was in favor of it. This is the heart of engineering or politics: finding the optimal compromise.
AtlasBarfed 4y ago
Worse is better is simply a local maxima of features - schedule - cost tradeoffs, and there not being enough of a sustained investment to "hop out" of the local maxima. When those maxima are things like operating systems and programming language ecosystems, those are very very big hops to make.

rob74 4y ago

The kind of codebase you describe with "elaborate type setups" (multiple levels of inheritance, design patterns like Facade used for "decoupling" etc.) make it very hard to read the code and understand what it's doing (unless it's very well documented), and because of that also make it harder to extend without resorting to kludges. Or, if you want to extend it in a way the original designer didn't foresee, you now have to change 5 different classes to be able to access some private property in some class.

funcDropShadow 4y ago

> Over time, I have come to believe that the problem is overly-aggressive abstraction. Sometimes, yes, overly-aggressive abstractions are a problem. But the author describes policies of v1 and v2 of the linker. And I would say the most critical difference between them is, that the authors of v2 had a better understanding of the requirements that actually mattered. Therefore they were in a better situation to evaluate the architecture and they were able to make better trade-offs. Deciding to trust object files as inputs might raise a red flag for some people. In principle it could allow attacks/exploits of the linker. But in reality for most threat models this does not matter. Because the compiler generating object files has the same level of trust as the linker. Companies that want to provide an elf linker as a service product are out of scope. Deciding what is in scope and what is out of scope is probably one of the hardest decisions in product engineering. Because many of us software engineers lean towards perfectionism or, especially inexperienced developers are searching for the silver bullet, that set of rules that enables them to develop every product successfully. [edited typos]

ncmncm 4y ago

I suspect the "Worse is Better" essay has caused untold harm. It is written from the standpoint of a purist offended that the world doesn't appreciate purity, complaining that the things people end up using are built by pragmatic people. The lesson seems to be that doing things better is punished. But that is the wrong lesson. The correct lesson is that the real world is not obliged to conform to your personal model of "better". You have a personal obligation to continuously adapt your model to match the real world. This is the model of science, and is opposed to Platonism. After you have adjusted your model, it is certain to still not be right, and need further adjustment. Usually "the world" you are obliged to adjust to has its own problems. There are powerful forces making us favor accommodating a Microsoft execution environment, even though that execution environment has always been a cesspit. It represents its own poor abstraction. Posix file system semantics are another example. Von Neumann architecture and the C abstract machine are not the only, or best way to organize computational resources. It is important to recognize when somebody else's pragmatic failure threatens to taint your own models. Lisp, RG's hobbyhorse, didn't get sidelined because of Philistines. Lisp turned out not to be better, despite how strongly RG felt about it. Instead of figuring out what about Lisp was not right, he called things that were, along axes that matter, more right "worse", preserving his personal model and lessening readers' ability to reason about merit.

recursivedoubts 4y ago
I don't agree at all. I think he was able to give a clear and accurate analysis of why lisp failed, despite liking the language so much. He also wrote critical responses to his own essay under a pseudonym, with a back and forth that is quite funny and demonstrates the ability to understand both sides of the argument. In "Worse is better" he explicitly mentions how that approach favors real-world application, because it is so simple it is fast and is "good enough" and then can be moved to 90% of the right thing. All of this is to say: I don't agree with you, but I also agree with you and I suspect he would as well, with qualifications. And he would probably also disagree with you.
- fileeditview 4y ago
  Perfect user name! Also this was my comment of the day.. nay week at least!

polotics 4y ago

Also, I often see developers running to the abstractions they know (cough design patterns...) mostly because they're very afraid of acknowledging they haven't grasped the real complexity of a domain. By the time a pragmatic efficient design emerges, you're on the second or third rewrite...

tynpeddler 4y ago

One of the best programming aphorisms I've heard is "Everything in programming can be solved with another layer of abstraction except for the problem of to many layers of abstraction."

layer8 4y ago
https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.m.wikipedia.org/wiki/Fundamental_theorem_of_softw...

Bjartr 4y ago

It can be worth understanding why the Java ecosystem evolved that way. It's not because simplicity wasn't valued, but rather it's not code simplicity that's valued. Rather, much of the Java ecosystem is designed to allow dozens of independent teams, totaling hundreds of developers, within a company (or across companies) to build their small piece of the application, with whatever build process is used by them. Then you put all the .jar files in one bundle, and the AbstractFactoryBuilderLookupServiceBuilders puts the pieces together at runtime. It's complex as hell code-wise, but it simplifies the amount of cross-team/cross-company alignment and synchronization that has to happen in order to cut a new version of the application containing hotfix 8495 for the part of the app maintained by Steve's team. There's actually a decent parallel between that and Microservices. Microservices make maintenance of the whole more complicated by introducing the network between pieces, but allow each piece more flexibility in how it's developed.

robocat 4y ago

From https://www.dreamsongs.com/WorseIsBetter.html https://www.dreamsongs.com/WorseIsBetter.html: The folks at Lucid were starting to get a little worried because I would bring them review drafts of papers arguing for worse is better, and later I would bring them rebuttals against myself. One fellow was seriously nervous that I might have a mental disease. after over a decade of thinking and speaking about it . . . [I wrote] "Back to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called "Back to the Future: Worse (Still) is Better!" which was in favor of it. This is the heart of engineering or politics: finding the optimal compromise.

AtlasBarfed 4y ago

Worse is better is simply a local maxima of features - schedule - cost tradeoffs, and there not being enough of a sustained investment to "hop out" of the local maxima. When those maxima are things like operating systems and programming language ecosystems, those are very very big hops to make.