4 ms·

It's interesting the contrast between the Sonos soundbar piece and the networking setup - both are described as simple, but I think one is much more complicated

It's interesting the contrast between the Sonos soundbar piece and the networking setup - both are described as simple, but I think one is much more complicated to set up than the other. So I suppose it's about the end result being easier to reason about, versus the overall convenience? Minimalism is good in both life and work. The best code is no code, and the next best is as little code as possible.

loopz 7y ago
Simple != Easy Like certain stuff looks simple in ie. golang, there's tons of opinionated design decision behind every nuance of the language. For some, simple would be more like Haskell, while for others bash (until they need to understand old code). Each eye of the beholder can argue either way. So what is most simple? Compile linux kernel by hand, or automate it? Automation becomes "simpler" (more valuable) the more it is actually used. The article talks about simplifying, though is more about discipline, something many find hard to find motivation and incentives for in this age of instant gratification!
- ISO-morphism 7y ago
  > Simple != Easy > For some, simple would be more like Haskell, while for others bash (until they need to understand old code). Each eye of the beholder can argue either way. Certainly simple != easy, but I think in the second part there "simple" should be replaced with "easy". Simple is objective, while easy is subjective [1]. Haskell may be easier for some as they've spent more time with it, similarly bash for others. However, their simplicity, i.e. how many concerns are intertwined, how much global context is required to reason about a program, can be more objectively analyzed. > The article talks about simplifying, though is more about discipline, something many find hard to find motivation and incentives for in this age of instant gratification! Indeed, it takes discipline to maintain simplicity. Simplicity is hard. Complexity is easy. "If I had more time to write, this letter would be shorter." [1] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
ben509 7y ago
Simple is too vague. The goal is avoiding unnecessary complexity, but not all complexity is the same. For instance, I'm not an audiophile, so I have no investment in audio equipment. A Sonos soundbar is, in absolute terms, an extremely complex device; you could measure all the steps to production and the complexity is pretty astounding. In some ways, a consumer product may be more complex because it'll have additional circuitry to provide the "simpler" interface. But that's counting the wrong complexity. It's the interface that I care about, because I'm trying to minimize the number of tasks and things about the device I have to memorize. So now we're studying a different class of entities: tasks I have to both learn and perform, and some amount of information I have to organize. There's also a degree of risk, as the damned thing can break, and I can sink a tremendous amount of time on the phone trying to remedy it, or have to throw it out, which I don't like. I've only used Ubiquiti products a bit, but they seem to have all their own special sauce. And, I'll bet the design tends to assume you recall things you did months ago or take perfect notes. So while I'd probaby go with the Ubiquiti, especially if the defaults just work, I might find it's simpler to set up a Linux box. How? That's advertising a ton of complexity to me, the entire Unix OS. But... I don't have to learn anything new, any configuration goes into a repo, and updating can be automated. That means the marginal complexity is still quite small. Managing complexity, like risk, cost or time, is very much an economic function. And, of course, since there's a limit to the amount of complexity you can manage in your life, a production-possibility frontier naturally emerges from these choices. When you're overloaded, you're dropping unmanageable complexity, most likely unconciously.

loopz 7y ago

Simple != Easy Like certain stuff looks simple in ie. golang, there's tons of opinionated design decision behind every nuance of the language. For some, simple would be more like Haskell, while for others bash (until they need to understand old code). Each eye of the beholder can argue either way. So what is most simple? Compile linux kernel by hand, or automate it? Automation becomes "simpler" (more valuable) the more it is actually used. The article talks about simplifying, though is more about discipline, something many find hard to find motivation and incentives for in this age of instant gratification!

ISO-morphism 7y ago
> Simple != Easy > For some, simple would be more like Haskell, while for others bash (until they need to understand old code). Each eye of the beholder can argue either way. Certainly simple != easy, but I think in the second part there "simple" should be replaced with "easy". Simple is objective, while easy is subjective [1]. Haskell may be easier for some as they've spent more time with it, similarly bash for others. However, their simplicity, i.e. how many concerns are intertwined, how much global context is required to reason about a program, can be more objectively analyzed. > The article talks about simplifying, though is more about discipline, something many find hard to find motivation and incentives for in this age of instant gratification! Indeed, it takes discipline to maintain simplicity. Simplicity is hard. Complexity is easy. "If I had more time to write, this letter would be shorter." [1] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/

ben509 7y ago

Simple is too vague. The goal is avoiding unnecessary complexity, but not all complexity is the same. For instance, I'm not an audiophile, so I have no investment in audio equipment. A Sonos soundbar is, in absolute terms, an extremely complex device; you could measure all the steps to production and the complexity is pretty astounding. In some ways, a consumer product may be more complex because it'll have additional circuitry to provide the "simpler" interface. But that's counting the wrong complexity. It's the interface that I care about, because I'm trying to minimize the number of tasks and things about the device I have to memorize. So now we're studying a different class of entities: tasks I have to both learn and perform, and some amount of information I have to organize. There's also a degree of risk, as the damned thing can break, and I can sink a tremendous amount of time on the phone trying to remedy it, or have to throw it out, which I don't like. I've only used Ubiquiti products a bit, but they seem to have all their own special sauce. And, I'll bet the design tends to assume you recall things you did months ago or take perfect notes. So while I'd probaby go with the Ubiquiti, especially if the defaults just work, I might find it's simpler to set up a Linux box. How? That's advertising a ton of complexity to me, the entire Unix OS. But... I don't have to learn anything new, any configuration goes into a repo, and updating can be automated. That means the marginal complexity is still quite small. Managing complexity, like risk, cost or time, is very much an economic function. And, of course, since there's a limit to the amount of complexity you can manage in your life, a production-possibility frontier naturally emerges from these choices. When you're overloaded, you're dropping unmanageable complexity, most likely unconciously.