Live data from Hacker News

The Danger of “Simplicity”

asthasr.github.io

111–120 of 172 posts

Re: The Danger of “Simplicity”

#111
post #92

I once worked on a system where the senior engineer on the project had a dogmatic definition of simple. It was an MVC web application. He insisted that having any form of flow control or logic in views was too complex - it was simpler to regard all logic as application logic and put it in the controller. This meant that instead of one controller being able to drive multiple views, something as straightforward as rend…

Yip, I've also encountered "architects" who obsess on certain things, and make a mess in the process, at least something that is a "mess" to the majority of coders.

One is left with a dilemma of complain harder or leave. Unfortunately, leaving is probably the only way out. Often such people have "connections" and are thus not correctable. They have outlier minds and want a system that models their outlier brain even if multiple developers complain. Bail out.

Re: The Danger of “Simplicity”

#112
post #17

I’m starting to think that I’m in the minority that agrees with most (if not all) Go’s design decision and appreciate Rob Pike’s stewardship so far.

Depends on who's opinion we're talking about.

In general, Go community is satisfied with its direction according to 2018 survey: https://blog.golang.org/survey2018-results

In my experience, most harsh criticism comes from those who either barely used Go if at all or tried to build something Go wasn't aimed for.

Re: The Danger of “Simplicity”

#113

Earlier 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…

> Simpler is easier than complex, right? Well, no. Complexity has an obvious price but simplicity does too. You have to work for simplicity, even fight for it. Think of code; it just somehow becomes more complex. You have to work to pare it back to what's needed. I can't think ATM of better examples (and you deserve some), but no, simplicity does not come easy. A nice phrase I came across: "elegance is refusal".

Until you find a good example, I challenge your understanding :)

Similar to my response to another comment, I suspect there is a switching of subjects. It starts with a problem, and the subject is a solution to the problem. Simpler solution is easier to understand and manage. A more complex solution is more difficult. Is there a counter example?

Try not to switch out the subject here. For example, one may propose to use a library to solve the problem by calling `library.solve`. And then one may argue that the simplicity of the code is actually more difficult to manage as one need trouble shoot all the details/bugs/interfaces with the library. We should recognize that the library itself is not the same as the solution. The solution includes the calling the library and its details/bugs/interfaces/packaging/updating/synchronizing etc. And these elements interwine to make the complexity. So the solution itself using the library is not necessarily simple. It is difficult exactly because of the complexity.

As you can tell, I am essentially making the same opinion as Rich Hickey, which is `simple-made-easy`. And it is very far away from the click-bate opening statement of "simple is often erroneously mistaken for easy". A more correct sentence probably should be "simple is often erroneously labeled by partial".

EDIT: To clarify, I am not saying a solution using a library is more complex. It depends. With a library, the solution is layered and delegated. The entire solution is more complex and more difficult to understand -- if one is to understand every byte of it. However, the layering means not all complexity need to be understood for practical reasons. So with proper layering and a good judgement of practicality, the part of the complexity that you practically need manage may well be simpler (and easier) by using a library, or not. It depends.

Re: The Danger of “Simplicity”

#114
post #72

> For example, dynamically typed languages like Python (or Ruby, Lisp, etc.) are easy and pleasant to write. They avoid the difficulty of convincing a compiler that you’ve written your code correctly, but they’re harder for a new team member to comprehend: you’re trading fluent writing for more laborious reading. I feel like this misses the point of high-level languages. In my experience, higher-level code is easier…

Re: "Lisp isn't more productive just because..."

Whether Lisp or functional programming is "more productive" in general or just in the hands of a few is a controversial topic. Example debates:

https://wiki.c2.com/?IfFooIsSoGreatHowComeYouAreNotRich

https://wiki.c2.com/?GreatLispWar

I personally find functional harder to debug and haven't got past that bottleneck yet. Yes, maybe I'm "doing it wrong", but can't find "right". Somebody else once told me, "functional makes it easier to express what you want but imperative (traditional programming) makes it easier to figure out what's actually happening". That rings very very true for me. In terms of productivity, it looks the second is trumping the first. In another forum, the "solution" was "just don't make bugs". Doh! Even if true for an individual, it may not scale to a bigger team.

Re: The Danger of “Simplicity”

#115
post #5

"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 think it's important to note that 'simple' can be used as an epithet.

Re: The Danger of “Simplicity”

#116
post #108

There 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…

>There are several key "rules of thumb" to keep in mind, and they are often contradictory.

Rules of thumb in software engineering is bullshit masquerading as wisdom. Don't keep them in mind. They will hog your cognitive bandwidth which you could use to actually reason about problems.

Real engineering involves balancing tradeoffs. To balance them, you need to understand what they are. Sloganistic "rules of thumb" do not help with that at all.

For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info or it could be used to advocate for ignoring a critical design flaw that's guaranteed to bite you in the ass later on.

Good engineers don't spew out slogans. They explain their reasoning.

Re: The Danger of “Simplicity”

#117
post #49

Earlier quoted context omitted.

I had a math teacher in primary school who used to shout with an exaggerated accent, "simple is not the same as easy!" She really wanted to drill the idea into our heads that just because you know exactly how to do something, doesn't mean that it will be quick or easy to accomplish. Like, for a schoolchild, long division. The rules are simple, but given big enough numbers you'll probably mess up at least once. And th…

"It is straightforward to show that..." means that you could probably do it with your current knowledge, but it will take 6 dense pages, four false starts and about a week of focused work.

'You' being personified here, rather than the general you.

Straightforward tends to suggest we don't have to have a bunch of meetings about it, because the right person either has the knowledge or we know precisely where to get it.

Re: The Danger of “Simplicity”

#118
post #10
post #7

I think the confusion around simplicity is in what terms a thing is simple. For example, 2 pieces of text can be simple in 2 different ways: First text is long but uses fewer words in vocabulary. So it is "simple" in a sense you need to learn only few words to read it. Second text is short but uses richer vocabulary to describe things with fewer words (syntactic sugar). It is "simple" in a sense you only need few wor…

>"Neat" code can be "simple" to maintain. "Messy" code can be "simple" to implement. I was thinking something similar recently. Good code should take the next developer less time / effort to understand it than it took the original developer to write it (assuming similar levels of ability).

> the next developer

And that's often you, just in a few months' time.

Re: The Danger of “Simplicity”

#119
post #108

There 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…

>There are several key "rules of thumb" to keep in mind, and they are often contradictory. Rules of thumb in software engineering is bullshit masquerading as wisdom. Don't keep them in mind. They will hog your cognitive bandwidth which you could use to actually reason about problems. Real engineering involves balancing tradeoffs. To balance them, you need to understand what they are. Sloganistic "rules of thumb" do n…

Re: "For example: YAGNI. "Your ain't gonna need it." It could be used to advocate for deferring a decision for which you don't have enough info..."

Another rule of thumb is "know your domain".

Re: "Good engineers don't spew out slogans. They explain their reasoning."

That is true, but it's also good to have summary reminders. People won't remember most 2 hour lectures unless refreshed over time, and rules of thumb are one way to do this without re-attending the same 2 hour lecture over and over. In the ideal world they'd re-attend the full lectures (or close to) to get a refresh, but that's not the way most humans do things.

Re: The Danger of “Simplicity”

#120

The two perspectives that I often find at opposite poles when proposing simplicity is that of the developer vs. that of the user. Generally what's simple for the user drives less simple solutions for the developer and vice versa. It's not always possible, but when it is, I strive to find the solution that ends up being dead simple for both.

I really noticed this when I caught business folks conflating the two.

Often the more easily you can describe the situation, the more code it takes to make it Just Work.

Simple for the user is harder for me.

Post reply on HN