Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do the simplest thing that can possibly work (2004)

twasink.net

Post reply on HN
Print view View original

71–80 of 95 posts

Re: Do the simplest thing that can possibly work (2004)

#71

Post by xiphias2 »

RangerScience wrote: post #65
xiphias2 wrote: post #58

Earlier quoted context omitted.

What's interesting in Rick Hickeys video is that he talks about prioritizing minimizing what each thing does over minimizing the number of things (that you can ignore anyways). Having more things doesn't make systems more complex in itself if they can be combined differently as requirements change.

I agree and disagree! That talk is a favorite - and it's why I say "number of interacting things". If we're weaving together three strands (basic braid), that's fine - we've got three interactions. If we take that braid and two more and weave them together, IHMO we're only adding three more interactions (now we're at 6), but if we take all nine original strands and weave them all together, we're up to, what... at lea…

,,If we take that braid and two more and weave them together, IHMO we're only adding three more interactions (now we're at 6), but if we take all nine original strands and weave them all together, we're up to, what... at least 72 "interactions" (each of the 9 has an interaction with 8 others), and that's before asking if any of the "interactions" themselves become "interacting things" (and then we get a combinatorial explosion).''

You're totally right in it.

But the huge mistake I made just recently is to create a very simple interface that hides lots of different features with a few elegant flags. Although it's a super tiny interface that's easy to understand, the interactions became very complex.

Instead of using my library, people started to create another that just does 1 thing, and can't take advantage of my hard work even if they wanted.

Have I created 10 different totally independent components that use the same basic data structures (with a bigger total API surface), people could have used just the 2-3 that they need in their own system, and would have been able to understand (and even report / fix / debug) the interactions.

And actually everybody wants something a bit different, and nobody wants really all those 9 features.

This experience is what resonates with me right now when listening to the video.

Re: Do the simplest thing that can possibly work (2004)

#72

Post by blippage »

7speter wrote: post #46
blippage wrote: post #36

MVP: Minimal Viable Product. The greatest example of this is Unix. Multics was a huge produce that failed (initially). Bell Labs washed their hands of it, and didn't want anything to do with Operating Systems again. Ken Thompson wrote an initial scrappy version of Unix in 3 weeks. Re-writing to C was a tremendous move because it meant that Unix could be ported easily to many other systems. I heard someone say that th…

I thought c was primarily developed for the initial purpose of being the language used to write Unix and that their developments were practically one after the other and that Ritchie and Thompson were colleagues at Bell? C was designed for portability in mind?

I could be wrong, but I think Unix was originally written in assembler, which isn't portable.

Unix first appeared on a PDP-7 (not PDP-11). PDP-7 was pretty old even by the standards of the time.

"Originally, UNIX was written in PDP-7 assembly, and then in PDP-11 assembly, but then when UNIX V4 began to be re-written in C in 1973 and was run mostly on the PDP-11.

So far as I can tell, there is no Ancient C compiler that targets the PDP-7, nor any provision for running UNIX V4 or later on the PDP-7" [0] The link also contains some other interesting commentary.

I seem to recall that Thompson wanted to write code in Fortran.

I'm probably getting a few details wrong. The systems were extraordinarily constrained, something like 4K of RAM. "++" exists because it was more concise that "+= 1" (although K&R C uses "=+ 1", I think). They really wanted to make every byte count.

[0] https://retrocomputing.stackexchange.com/questions/6194/why-...

Re: Do the simplest thing that can possibly work (2004)

#73

Post by jghn »

xiphias2 wrote: post #15
addaon wrote: post #4

This write-up is too light to provide any real insight. In particular, how do you assess simplicity? From an example I'm currently working through on a hobby project... do I use a RS-485 transceiver with a custom line code, or do I use a 10base-T1 PHY? Ethernet, especially one pair ethernet, is undoubtedly more /complex/, with echo cancellation, a complicated line code, etc; but if I use the PHY, then /I own/ that co…

Actually Rick Hickey's talk ( https://www.youtube.com/watch?v=LKtk3HCgTa8 ) is amazing because he talks about your case by going back to the original meaining of words: ,,Complex comes from the Latin complecti, which means “to entwine around, to embrace'' Simplicity requires layering, so in your examples the main requirement for simplicity is about how intertwined your hobby project is with the transciever code or et…

I always point to this talk when engineering debates around simplicity & complexity come up. To me the key point is that "simplicity" and "easy" aren't synonyms.

Many people, when they said "do the simplest thing" they really mean "do the easiest thing". That's fine if that's what you want, but if you find yourself talking past someone else who means "do the simplest thing", that's why.

Re: Do the simplest thing that can possibly work (2004)

#74

Post by jacobr1 »

addaon wrote: post #32
Zetice wrote: post #31

Earlier quoted context omitted.

I don't think the person you're replying to would consider "till the land" as fitting what they're describing as "simple".

It's a requirement for making a bagel… the question is whether I do it, or someone else. Part of the irreducible complexity of bagelness is the production process of wheat.

It is a good way to consider the extremes of the problem-space, which often is a good way to come at a problem.

But a more practical, analogous situation might be: should I buy a nice, warm bagel at the local bagel shop, or should buy it a store and toast it myself? In that trade-off I can take for granted that I'm getting a bagel, but the delivery mechanism, the quality, the integration options, the cost, are things I need to consider.

The decision will depend upon your requirements. If you are organizing an event, maybe I get some bulk catering from the bagel-shop. If you want to use your aunt's bespoke berry jam, maybe you use the store-bought bagel so you easily can use your home spreads.

Identifying the optimal simplicity can be a hard problem, but that shouldn't preclude narrowing down choices with some rough heuristics so that you don't need to investigate the combinatorial explosion of all possibilities, or rethink the system dependencies back to: "first we have a big bang."

Re: Do the simplest thing that can possibly work (2004)

#75

Post by hinkley »

programd wrote: post #53
shagie wrote: post #16

Earlier quoted context omitted.

That's part of the section in Programming Perl that sticks in my memory. From my copy... > Efficiency > ... > Note that optimizing for time may sometimes cost you in space or programmer efficiency (indicated by conflicting hints below). Them’s the breaks. If program- ming was easy, they wouldn’t need something as complicated as a human being to do it, now would they? > ... > Programmer Efficiency > The half-perfect p…

> Programming Perl That book is one of the most underrated and overlooked works on the philosophy of programming I've ever read. It's ostensibly about best practices in programming Perl (which some people consider a complex language), but in reality this is a very deep book about the best practices for programming in any language. Note the above excerpt is pretty much universally applicable no matter what the languag…

I could say a similar thing about Practical Parallel Rendering. Officially it's a book about raytracing CGI in a cluster, but the first half of the book explains queuing theory and concurrency concerns in tremendous detail. It's a thin book to begin with, and you've more than gotten your money's worth if you read the first half and give up when they start talking about trigonometry.

Re: Do the simplest thing that can possibly work (2004)

#76

Post by icedchai »

addaon wrote: post #7
csdvrx wrote: post #5

Earlier quoted context omitted.

For me, the simplest thing would be using a serial interface instead!

RS-485 is a serial interface, at the physical layer. 8N1 as a line code introduces all sorts of other issues, assuming you're passing messages instead of byte streams over it. In particular, how do you do packetization? How do you synchronize? So many "serial interfaces" have implicit timers (corresponding to interpacket gap for ethernet) used for sync'ing, or play horrible games with embedded CRCs… there's a huge am…

Why reinvent the wheel? Just look at some older protocol, like SLIP.

Re: Do the simplest thing that can possibly work (2004)

#77

Post by RangerScience »

xiphias2 wrote: post #71
RangerScience wrote: post #65

Earlier quoted context omitted.

I agree and disagree! That talk is a favorite - and it's why I say "number of interacting things". If we're weaving together three strands (basic braid), that's fine - we've got three interactions. If we take that braid and two more and weave them together, IHMO we're only adding three more interactions (now we're at 6), but if we take all nine original strands and weave them all together, we're up to, what... at lea…

,,If we take that braid and two more and weave them together, IHMO we're only adding three more interactions (now we're at 6), but if we take all nine original strands and weave them all together, we're up to, what... at least 72 "interactions" (each of the 9 has an interaction with 8 others), and that's before asking if any of the "interactions" themselves become "interacting things" (and then we get a combinatorial…

Yup yup! It's like Asimov's Three Laws; you want to end up with a balance between the principles, and the "more important" ones just get higher weighting. It's totally possible (and common, I'd say) for the "weight" of the third one (complexity of the things) to reach the point where it's better to shift the complexity onto the "number of things".

(actually, on that note, a piece of my life philosophy is to have "opposing principles", since it's only through forces in opposition that balance is possible).

Re: Do the simplest thing that can possibly work (2004)

#78

Post by eternalban »

addaon wrote: post #17
xiphias2 wrote: post #15

Earlier quoted context omitted.

Actually Rick Hickey's talk ( https://www.youtube.com/watch?v=LKtk3HCgTa8 ) is amazing because he talks about your case by going back to the original meaining of words: ,,Complex comes from the Latin complecti, which means “to entwine around, to embrace'' Simplicity requires layering, so in your examples the main requirement for simplicity is about how intertwined your hobby project is with the transciever code or et…

> As long as the abstraction layer works well for you without getting too much into the details of the implementation, it's a simple solution. But this is where the engineering intuition has to come in. "As long as you will not end up spending more time debugging the system than implementing it" is an equivalent statement -- and that requires prediction of the future. If I'm going to spend hours staring at signals on…

easy =/= simple

While I get Rich's epistemological framing -- composing with coherent, independent, units -- "embracing" certainly does not ipso facto imply 'complex'. As a matter of fact, that line of thinking smells like a tautology.

Let's assume that if X is complex in one embodiment (say as software), it's analog will also be complex in the mapped domain. The most common occurance of this is when we describe a system. As it happens, our brains are much much better at assessing language constructs than material constructs. Simply describing system X will go a long way in gauging its complexity. A comparative description will make it crystal clear.

p.s.

Fully embracing simplicity:

https://architizer.com/blog/inspiration/industry/japanese-ar...

Description: Traditional Japanese joinery is made entirely without the use of metal fasteners or adhesives, relying on compression forces and friction of interleaving pieces.

Re: Do the simplest thing that can possibly work (2004)

#79

Post by EGreg »

addaon wrote: post #4

This write-up is too light to provide any real insight. In particular, how do you assess simplicity? From an example I'm currently working through on a hobby project... do I use a RS-485 transceiver with a custom line code, or do I use a 10base-T1 PHY? Ethernet, especially one pair ethernet, is undoubtedly more /complex/, with echo cancellation, a complicated line code, etc; but if I use the PHY, then /I own/ that co…

It’s too light to generate real insight because he took his own advice lol

Re: Do the simplest thing that can possibly work (2004)

#80

Post by peterashford »

NegativeLatency wrote: post #27
harpiaharpyja wrote: post #6

The sentiment is nice but ceases to be useful when people have trouble distinguishing what could possibly work from what appears to work for a bit and then breaks down horribly. And it's not really about the fallibility of people. Often in engineering you can be designing in a space with a lot of unknowns, that simply can't be resolved without building out a bit to explore the space more. In such case some level of f…

Yeah sometimes you have to do the complicated thing, the saying "you can't build a ladder to the moon" comes to mind I do think that many people make the wrong tradeoff in terms of complexity to features ratio though.

That is, I think, why a lot of people add "that can possibly work"
Post reply on HN