6 ms·

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally, etc. I’ve built many 0-1 systems, and this is the common thread among all of them. [0] https://en.m.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution https://en.m.wikipedia.org/wiki/Lehman%27s_laws_of_software_...

zokier 2y ago
Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.
- z3t4 2y ago
  There will always be edge cases, and yes they will make the code more complicated, but what really helps is automatic testing to make sure those edge cases don't break when making changes.
  - Vampiero 2y ago
    Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.
    - z3t4 2y ago
      It doesn't have to be difficult, for example when developing user interfaces I have a secret key combo for triggering the latest test, and another for running all tests. And I make mock functions that will trigger user interaction automatically. I inline the tests so they are next to the code being tested. I also place them inside comments so I can regexp remove the tests for the release because I don't want my program to be more then two MB, but if you don't care about size you could just leave the tests there so that they can be triggered by users in a prod environment as well. The problem with modern development is that the frameworks makes everything more complicated. Just ditch the leaky abstractions and increase your productivity 100x
- immibis 2y ago
  Failing to account for this gives you Wayland (which at this time is more complex than X11)
  - dartos 2y ago
    Is it actually more complex? I find it more understandable, it’s just that DEs need to write their own compositors.
    - immibis 2y ago
      X11 has plenty of warts, but Wayland has more. Example: screenshot. X11: "please tell me the pixels in the root window". Wayland: "please tell me the extension number of the portals extension so I can open a portal to pipewire so I can get the pipewire connection string so I can connect to the pipewire server so I can ..." Example: get window position on screen. Example: set window title. X11 is a protocol about managing windows on a screen. Wayland is a protocol about sending pixel buffers to an unspecified destination. All the screen-related stuff, which is integral to X11, is hard to do in Wayland with a pile of optional extensions and external protocol servers which do not interact. X11 is also more standardized, de facto, because there are fewer server implementations, which is not just an accident but is by design.
      - vacuity 2y ago
        X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly: base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that is in some ways mechanism with slightly more abstraction (e.g. drawing shapes) -> some more policy-mechanism abstraction (e.g. windows) ... until you get to your desired layer of abstraction to work at. This goes along with modularity, composition, code reuse. X11 itself has many design flaws, but Wayland's design is untenable.
- bunderbunder 2y ago
  This is where the advice in the article is excellent. If you start with code that's easy to delete, it's often possible to alter your data representation or otherwise transform the problem in a way that simply eliminates the edge cases. With the result being a design that is simpler by virtue of being more robust. If you start with code that's hard to delete, usually by the time you discover your edge and corner cases it's already too late and you're stuck solving the problem by adding epicycles.
- Skeime 2y ago
  Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn. The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice like using vacuous falsity, i.e. all [] == False (Just for illustration what I mean by "vacuous falsity", Python's all correctly returns True). Now, every layer above has to special-case these as well, even if they would be a completely normal case otherwise.
  - friendzis 2y ago
    Your example perfectly illustrates oversimplification: attempt to stuff categorical variable into another of lower order. If a language has absence of value available as an expressible concept (nullability), then a list is at least 3-way categorical variable: absence of value, empty list, non-empty list. Any attempts to stuff that into a binary truthy value will eventually leak one way or another.
arkh 2y ago
> encourage simple duplication A rule I like to follow: - first time: write it - second time: copy it - third time: maybe refactor it
- jumploops 2y ago
  Agreed! I'll usually go one step further for early projects and lean towards 3rd time copy, 4th time refactor. Example: So much early code is boilerplate CRUD, that it's tempting to abstract it. 9 times out of 10, you'll create a quasi-ORM that starts inheriting business logic and quickly grows omni-functions. Eventually you may actually need this layer, assuming you're system miraculously scales to needing multiple services, datastores, and regions. However this doesn't just apply to the obvious, and you may find omni-logic that made a feature more simple once and is currently blocking N new features. Code is cheap, especially today. Complexity necessarily constrains, for better or worse.
  - tetha 2y ago
    Hence why I am rather looking if two pieces of code change together, opposed to just looking the same. If I need to introduce the same feature in multiple places in roughly the same way, that's a decent indication code wants to be the same and wants to change together. That's something to consider extracting. Fixing the same bug in several places is a similar, but weaker indication. It's weaker, because a bug might also occur from using a framework or a library wrong and you do that in several places. Fixing the same business logic error in several places could mean to centralize some things.
  - sjducb 2y ago
    It’s so easy to accidentally write an ORM or a database. I constantly stop and think; is this piece of code secretly a database?
- jolt42 2y ago
  Everything in balance. While I agree with this philosophy, I've also seen lots of duplicate bugs because it wasn't realized there was two copies of the same bug.
antonhag 2y ago
+1, but I'm not sure if the "simple is robust" saying is straightforward enough? It opens up to discussion about what "simple" means and how it applies to the system (which apparently is a complex enough question to warrant the attention of the brilliant Rich Hickey). Maybe "dumb is robust" or "straightforward is robust" capture the sentiment better?
- jumploops 2y ago
  The usual metric is complexity, but that can be hard to measure in every instance. Used within a team setting, what is simple is entirely subjective to that set of experiences. Example: Redis is dead simple, but it's also an additional service. Depending on the team, the problem, and the scale, it might be best to use your existing RDBMS. A different set of circumstances may make Redis the best choice. Note: I love "dumb is robust," as it ties simplicity and straightforwardness together, but I'm concerned it may carry an unnecessarily negative connotation to both the problems and the team. Simple isn't necessarily dumb.
  - soco 2y ago
    Dull?
- seb1204 2y ago
  Indeed, simple is not a good word to qualify something technical. I have a colleague and if he comes up with something new and simple it usually takes me down a rabbit hole of mind bending and head shaking. A matter of personal perspective?
  - Vampiero 2y ago
    Is my code simple if all it does is call one function (that's 50k lines long) hidden away in a dependency? You can keep twisting this question until you realize that without the behemoths of complexity that are modern operating systems (let alone CPUs), we wouldn't be able to afford the privilege to write "simple" code. And that no code is ever "simple", and if it is it just means that you're sitting on an adequate abstraction layer. So we're back at square one. Abstraction is how you simplify things. Programming languages themselves are abstractions. Everything in this discipline is an abstraction over binary logic. If you end up with a mess of spaghetti, you simply chose the wrong abstractions, which led to counter-productive usage patterns. My goal as someone who writes library code is to produce a framework that's simple to use for the end user (another developer). That means I'm hiding TONS of complexity within the walls of the infrastructure. But the result is simple-looking code. Think about DI in C#, it's all done via reflection. Is that simple? It depends on who you ask, is it the user or the library maintainer who needs to parametrize an untyped generic with 5 different type arguments? Obviously, when all one does is write business logic, these considerations fall short. There's no point in writing elegant, modular, simple code if there's no one downstream to use it. Might as well just focus on ease of readability and maintainability at that point, while you wait for the project to become legacy and die. But that's just one particular case where you're essentially an end user from the perspective of everyone who wrote the code you're depending on.
cedws 2y ago
Can’t upvote enough. Too much dogshit in software is caused by solving imaginary problems. Just write the damn code to do the thing. Stop making up imaginary scaling problems. Stop coming up with clever abstractions to show how smart you are. Write the code as a monolith. Put it on a VM. You are ready to go to production. Then when you have problems, you can start to solve them, hopefully once you are cash positive. Why is your “AirBnb for dogs” startup with zero users worrying about C100K? Did AWS convince you to pay for serverless shit because they have your interests in mind, or to extract money from you?
- 392 2y ago
  I am not sure on that. But I am certain the article Amazon published on cutting AWS bill by 90% by simplifying juvenile microservices to a dead simple monolith was deleted on accident.
throw156754228 2y ago
You can't wish the complexity of business logic away. If it is vast and interconnected, then so is the code.

zokier 2y ago

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

z3t4 2y ago
There will always be edge cases, and yes they will make the code more complicated, but what really helps is automatic testing to make sure those edge cases don't break when making changes.
- Vampiero 2y ago
  Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.
  - z3t4 2y ago
    It doesn't have to be difficult, for example when developing user interfaces I have a secret key combo for triggering the latest test, and another for running all tests. And I make mock functions that will trigger user interaction automatically. I inline the tests so they are next to the code being tested. I also place them inside comments so I can regexp remove the tests for the release because I don't want my program to be more then two MB, but if you don't care about size you could just leave the tests there so that they can be triggered by users in a prod environment as well. The problem with modern development is that the frameworks makes everything more complicated. Just ditch the leaky abstractions and increase your productivity 100x
immibis 2y ago
Failing to account for this gives you Wayland (which at this time is more complex than X11)
- dartos 2y ago
  Is it actually more complex? I find it more understandable, it’s just that DEs need to write their own compositors.
  - immibis 2y ago
    X11 has plenty of warts, but Wayland has more. Example: screenshot. X11: "please tell me the pixels in the root window". Wayland: "please tell me the extension number of the portals extension so I can open a portal to pipewire so I can get the pipewire connection string so I can connect to the pipewire server so I can ..." Example: get window position on screen. Example: set window title. X11 is a protocol about managing windows on a screen. Wayland is a protocol about sending pixel buffers to an unspecified destination. All the screen-related stuff, which is integral to X11, is hard to do in Wayland with a pile of optional extensions and external protocol servers which do not interact. X11 is also more standardized, de facto, because there are fewer server implementations, which is not just an accident but is by design.
    - vacuity 2y ago
      X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly: base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that is in some ways mechanism with slightly more abstraction (e.g. drawing shapes) -> some more policy-mechanism abstraction (e.g. windows) ... until you get to your desired layer of abstraction to work at. This goes along with modularity, composition, code reuse. X11 itself has many design flaws, but Wayland's design is untenable.
bunderbunder 2y ago
This is where the advice in the article is excellent. If you start with code that's easy to delete, it's often possible to alter your data representation or otherwise transform the problem in a way that simply eliminates the edge cases. With the result being a design that is simpler by virtue of being more robust. If you start with code that's hard to delete, usually by the time you discover your edge and corner cases it's already too late and you're stuck solving the problem by adding epicycles.
Skeime 2y ago
Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn. The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice like using vacuous falsity, i.e. all [] == False (Just for illustration what I mean by "vacuous falsity", Python's all correctly returns True). Now, every layer above has to special-case these as well, even if they would be a completely normal case otherwise.
- friendzis 2y ago
  Your example perfectly illustrates oversimplification: attempt to stuff categorical variable into another of lower order. If a language has absence of value available as an expressible concept (nullability), then a list is at least 3-way categorical variable: absence of value, empty list, non-empty list. Any attempts to stuff that into a binary truthy value will eventually leak one way or another.

arkh 2y ago

> encourage simple duplication A rule I like to follow: - first time: write it - second time: copy it - third time: maybe refactor it

jumploops 2y ago
Agreed! I'll usually go one step further for early projects and lean towards 3rd time copy, 4th time refactor. Example: So much early code is boilerplate CRUD, that it's tempting to abstract it. 9 times out of 10, you'll create a quasi-ORM that starts inheriting business logic and quickly grows omni-functions. Eventually you may actually need this layer, assuming you're system miraculously scales to needing multiple services, datastores, and regions. However this doesn't just apply to the obvious, and you may find omni-logic that made a feature more simple once and is currently blocking N new features. Code is cheap, especially today. Complexity necessarily constrains, for better or worse.
- tetha 2y ago
  Hence why I am rather looking if two pieces of code change together, opposed to just looking the same. If I need to introduce the same feature in multiple places in roughly the same way, that's a decent indication code wants to be the same and wants to change together. That's something to consider extracting. Fixing the same bug in several places is a similar, but weaker indication. It's weaker, because a bug might also occur from using a framework or a library wrong and you do that in several places. Fixing the same business logic error in several places could mean to centralize some things.
- sjducb 2y ago
  It’s so easy to accidentally write an ORM or a database. I constantly stop and think; is this piece of code secretly a database?
jolt42 2y ago
Everything in balance. While I agree with this philosophy, I've also seen lots of duplicate bugs because it wasn't realized there was two copies of the same bug.

antonhag 2y ago

+1, but I'm not sure if the "simple is robust" saying is straightforward enough? It opens up to discussion about what "simple" means and how it applies to the system (which apparently is a complex enough question to warrant the attention of the brilliant Rich Hickey). Maybe "dumb is robust" or "straightforward is robust" capture the sentiment better?

jumploops 2y ago
The usual metric is complexity, but that can be hard to measure in every instance. Used within a team setting, what is simple is entirely subjective to that set of experiences. Example: Redis is dead simple, but it's also an additional service. Depending on the team, the problem, and the scale, it might be best to use your existing RDBMS. A different set of circumstances may make Redis the best choice. Note: I love "dumb is robust," as it ties simplicity and straightforwardness together, but I'm concerned it may carry an unnecessarily negative connotation to both the problems and the team. Simple isn't necessarily dumb.
- soco 2y ago
  Dull?
seb1204 2y ago
Indeed, simple is not a good word to qualify something technical. I have a colleague and if he comes up with something new and simple it usually takes me down a rabbit hole of mind bending and head shaking. A matter of personal perspective?
- Vampiero 2y ago
  Is my code simple if all it does is call one function (that's 50k lines long) hidden away in a dependency? You can keep twisting this question until you realize that without the behemoths of complexity that are modern operating systems (let alone CPUs), we wouldn't be able to afford the privilege to write "simple" code. And that no code is ever "simple", and if it is it just means that you're sitting on an adequate abstraction layer. So we're back at square one. Abstraction is how you simplify things. Programming languages themselves are abstractions. Everything in this discipline is an abstraction over binary logic. If you end up with a mess of spaghetti, you simply chose the wrong abstractions, which led to counter-productive usage patterns. My goal as someone who writes library code is to produce a framework that's simple to use for the end user (another developer). That means I'm hiding TONS of complexity within the walls of the infrastructure. But the result is simple-looking code. Think about DI in C#, it's all done via reflection. Is that simple? It depends on who you ask, is it the user or the library maintainer who needs to parametrize an untyped generic with 5 different type arguments? Obviously, when all one does is write business logic, these considerations fall short. There's no point in writing elegant, modular, simple code if there's no one downstream to use it. Might as well just focus on ease of readability and maintainability at that point, while you wait for the project to become legacy and die. But that's just one particular case where you're essentially an end user from the perspective of everyone who wrote the code you're depending on.

cedws 2y ago

Can’t upvote enough. Too much dogshit in software is caused by solving imaginary problems. Just write the damn code to do the thing. Stop making up imaginary scaling problems. Stop coming up with clever abstractions to show how smart you are. Write the code as a monolith. Put it on a VM. You are ready to go to production. Then when you have problems, you can start to solve them, hopefully once you are cash positive. Why is your “AirBnb for dogs” startup with zero users worrying about C100K? Did AWS convince you to pay for serverless shit because they have your interests in mind, or to extract money from you?

392 2y ago
I am not sure on that. But I am certain the article Amazon published on cutting AWS bill by 90% by simplifying juvenile microservices to a dead simple monolith was deleted on accident.

throw156754228 2y ago

You can't wish the complexity of business logic away. If it is vast and interconnected, then so is the code.