Heh
“I apologize for such a long letter - I didn't have time to write a short one.”
― Mark Twain
The Danger of “Simplicity”
101–110 of 172 posts
Re: The Danger of “Simplicity”
#102"Simple is often erroneously mistaken for easy. 'Easy' means 'to be at hand', 'to be approachable'. 'Simple' is the opposite of 'complex' which means 'being intertwined', 'being tied together'" - https://www.infoq.com/presentations/Simple-Made-Easy/
Simplicity is often a matter of perspective, a function of a certain perception of a complex subject and the set of expectations that go with this perception. There is no absolute in analysis and in modelling synthetic propositions from the atoms used by the particular analysis. (E.g., we may analyse and model an action in terms of verb-noun or of noun-verb, with major differences in what may be perceived as "simple"…
> Simplicity is often a matter of perspective
Complexity was formally defined by Kolmogorov, using with Turing machines even. Hence, Simplicity is also objectively defined.
Re: The Danger of “Simplicity”
#103I would define simplicity as "the approach that minimizes cognitive load while meeting all other objectives"
I would hope that people with the same objectives would agree on simplicity for that domain.
Examples:
Need a lot of machine control, direct memory control (page alignment, cache alignment, shared memory, numa, etc) interact with system calls directly, interact with hardware, and security is not important in the domain (e.g. private hpc cluster behind a firewall)
C is probably the simplest
Need to quickly prototype something medium sized that involves non-trivial data structures or needs to interact with an http server. And you don't care about performance.
Something like Python is probably simplest
Etc etc etc
By contrast.. try doing the former with Python, Java, etc and see how much additional cognitive load you have to add.. ever try the later with C.. no fun.
Re: The Danger of “Simplicity”
#104"Simple is often erroneously mistaken for easy. 'Easy' means 'to be at hand', 'to be approachable'. 'Simple' is the opposite of 'complex' which means 'being intertwined', 'being tied together'" - https://www.infoq.com/presentations/Simple-Made-Easy/
I am yet to appreciate Rich Hickey's now famous "Simple Made Easy". While I agree with his points, I don't understand the significance of it. Simpler is easier than complex, right? Even the title said "simple-made-easy". What is the fuss about emphasizing "Simple is erroneously mistaken for easy"? They are not the same, but they are intimately related. Or is this an emphasis on relative vs absolute -- that relative s…
Modules are "simpler" than vectors because they have fewer axioms, but they are also much harder to understand. For example, not all modules have a basis, which can make them much harder to work with.
For background on the math, see: https://math.stackexchange.com/questions/137442/a-module-wit...
Re: The Danger of “Simplicity”
#105There was a wise thing along the lines of "to build a simpler system, start with more powerful (and complex, by necessity) building blocks"... I think it was Alan Kay who said this or something very similar. Worst thing is that "simple" languages like Go force you to mix up "business logic" with "plumbing/infra logic" with "error handling logic" if you try to be idiomatic... I know that for security crucial code you…
>Worst thing is that "simple" languages like Go force you to mix up "business logic" with "plumbing/infra logic" with "error handling logic" if you try to be idiomatic...
How so? Can you not write modular code in just about any language? I'm not saying programming languages don't matter, but in terms of seperating business logic from plumbing I don't see huge differences.
I also don't think you can seperate errors from the rest of your code on the same level of abstraction. Business logic errors such as "account overdrawn" are business logic. Plumbing errors such as a broken network connection are plumbing.
The only errors that can and should be kept separate are bugs that need to be fixed.
Re: The Danger of “Simplicity”
#106Earlier quoted context omitted.
I am yet to appreciate Rich Hickey's now famous "Simple Made Easy". While I agree with his points, I don't understand the significance of it. Simpler is easier than complex, right? Even the title said "simple-made-easy". What is the fuss about emphasizing "Simple is erroneously mistaken for easy"? They are not the same, but they are intimately related. Or is this an emphasis on relative vs absolute -- that relative s…
Modules are "simpler" than vectors because they have fewer axioms, but they are also much harder to understand. For example, not all modules have a basis, which can make them much harder to work with. For background on the math, see: https://math.stackexchange.com/questions/137442/a-module-wit...
Good luck explaining "simpler" with modules and vectors :).
Simple is defined as not to inter-wine. To understand an axiom is to understand how it "inter-wine" with other axioms to prove certain results. So fewer axioms necessarily results in more interwines, ie complex. I think here we are switching the subjects: from axiom itself to the results that we want to prove. If we focus on the simplicity of proving the results, the simplicity of axioms are irrelevant.
Re: The Danger of “Simplicity”
#107Earlier quoted context omitted.
>watching it will make you a 10x better programmer. That sounds wrong. Can we drop this rhetoric?
What rhetoric? Are you confusing this with "the 10x programmer" meme? Claims of becoming a 10x better programmer aren't claims about making one a 10x programmer. The former is about relative self-improvement and motivationally hyperbolic; the latter is about relative comparison to others, is often used negatively to belittle, and is detrimentally hyperbolic.
I would defensively be more hyperbolic and use a different number, just because 10x is tainted by stupid ideas in programming. But your intent was pretty clear to anyone paying attention... that's just a high bar sometimes.
Re: The Danger of “Simplicity”
#108There are several key "rules of thumb" to keep in mind, and they are often contradictory. Knowing how to weigh them well against each other takes experience in both the domain and IT in general.
Another rule of thumb to add is "don't obsess on a single rule of thumb; they are all important."
In my experience "keep it approachable" often overrides "less code" and DRY. Maintenance staff changes and you probably cannot control the quality of the next maintainer such that if your code requires an abstraction guru to figure out, you may put your org in a difficult spot.
Re: The Danger of “Simplicity”
#109"Simple is often erroneously mistaken for easy. 'Easy' means 'to be at hand', 'to be approachable'. 'Simple' is the opposite of 'complex' which means 'being intertwined', 'being tied together'" - https://www.infoq.com/presentations/Simple-Made-Easy/
If you haven't seen this talk; watching it will make you a 10x better programmer. This is what I take for my definition of complex and it applies broadly in a very practical manner.
I've measured between 2x - 3.5x for every 12 minutes of a Rich Hickey talk. What's even more staggering is this continues even for repeated viewings.
Re: The Danger of “Simplicity”
#110The article refers to "the much-abused YAGNI" and links to another blog post that goes into detail. Apparently some people take YAGNI to mean never anticipate anything. Is that your experience? I've always taken it as a tie-breaker when you're unsure whether to anticipate or not, and I've had the impression that others take it the same way. Overall I like this article and the YAGNI one it links to.
Yes, I worked in teams where "YAGNI" would come up all the time, preventing any kind of actual code design/architecture. Every time YAGNI is mentioned, it should be put against code quality (maintainability, readability, testability, etc) because they are often opposite/fighting concepts: code quality, in the end, is all about making (not yet known) changes easily, which means you have to anticipate different possibl…
> is all about making not yet known changes easily, which means you have to anticipate different possible futures.
The absurdity of this statement should immediately convince you that YAGNI is fundamentally correct. Anticipating the future is literally science-fiction. More often, it is superstition ; developers are very prone to FUDing themselves.
The thing is, demands create products and products create new demands. Even on small personal hobby projects this feedback loop can happen and sometimes lead to a full rewrite.
More over, code quality is far from being "all about making changes easily" [1]
> The sweet spot between these two principles is not easy to find. Thinking and discussing about this on projects is a good start.
There's nothing to discuss about it at the coding/design level. Anticipating a demand, generalizing it is done at a level above, or by someone else who has a better understanding of the market or the customer. Know your place. What you have is a document that tells you what needs to be done and a lot of freedom as for how to implement it.
The only case where anticipation can play a role is when you have several equal implementation options. There you can choose the one that seems more resilient to imaginary changes in the demands.