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

51–60 of 95 posts

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

#51

Post by addaon »

Zetice wrote: post #49
addaon wrote: post #32

Earlier quoted context omitted.

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.

I'm not sure how you arrived at "every single step involved must be considered" from "can't be reduced further". If a step available to you is "buy a bagel", that's all you have to consider.

At the risk of beating an analogy to death... this is exactly the mental model that gets us leftpad. Outsourcing of complexity is /not/ elimination of complexity. I may go my whole life without having to debug the lower-level steps in the process that put a bagel on my table, and if that's the case then treating dependencies as zero-cost makes sense -- but also, I may not be so lucky. When the supply chain collapses, I have to go without my bagel, or dig deeper. Either of which may be fine, depending on my requirements -- but the exported complexity is now present and impacting my experience.

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

#53

Post by programd »

shagie wrote: post #16
addaon wrote: post #10

Earlier quoted context omitted.

Agreed. But I also think that "simple to implement," "simple to debug," and "simple to test" are different metrics -- and that one has to choose which one to optimize for. This is independent from assessment of "simple" varying with intuition -- "simple" alone isn't a coherent concept.

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 language. Much of the book is written at that level.

https://www.oreilly.com/library/view/programming-perl-4th/97...

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

#54

Post by Zetice »

addaon wrote: post #51
Zetice wrote: post #49

Earlier quoted context omitted.

I'm not sure how you arrived at "every single step involved must be considered" from "can't be reduced further". If a step available to you is "buy a bagel", that's all you have to consider.

At the risk of beating an analogy to death... this is exactly the mental model that gets us leftpad. Outsourcing of complexity is /not/ elimination of complexity. I may go my whole life without having to debug the lower-level steps in the process that put a bagel on my table, and if that's the case then treating dependencies as zero-cost makes sense -- but also, I may not be so lucky. When the supply chain collapses,…

There's nothing wrong with leftpad as a library concept. The problem was that it got hacked, not that it does something useless that everyone should write on their own.

leftpad was incorporated into ECMAScript in 2017 for a reason.

> Outsourcing of complexity is /not/ elimination of complexity.

This is technically true but functionally false. You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.

There are two thoughts I have regarding this:

1) Leaky Abstractions seems like what you're trying to point out, and accurately so [0] but,

2) you can still rely on even leaky abstractions. You must, in fact, to function in this world. In some ways the quote, "In preparing for battle I have always found that plans are useless but planning is indispensable" [1] applies to abstraction as well.

[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

[1] https://quoteinvestigator.com/2017/11/18/planning/

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

#55

Post by RangerScience »

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…

I like to use SMBC's take[1] on the "Watchmaker Analogy" - complexity comes from, in order:

(1) number of things interacting

(2) complexity of interaction

(3) complexity of thing

So simplicity is then an inversion of that. You can "maximize simplicity" by:

(1) minimizing the number of things

(2) minimizing the complexity of interaction

(3) minimizing the complexity of each thing

This ends up reinventing many of things you find elsewhere (think SOLID; same-level-of-abstraction principle, etc) although I also generally find it's the first one - the most important one - that gets fucked up the most (one example: "type explosions", when you end up with just a bazillion different slightly different types).

Also, on a broader level, there really do seem to be two kinds of systems: Engineered systems, which (notionally) attempt to minimize those things, and "evolved" systems, which somewhat maximize them - both economies and ecologies have (1) many different interacting things, (2) with complex interactions, and (3) which are themselves complex.

You're right that it's an intuitive sense, but, I do think the right advice and perspectives can give you a leg up on learning and applying that sense.

[1] https://www.smbc-comics.com/?id=2344

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

#56

Post by xiphias2 »

majkinetor wrote: post #37
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. You can have very large number of layers, and to understand inner goings and interconnetions of all becomes very hard. I highly doubt you can equalize "set of superb interfaces" with simplicity.

You're totally right. Just watch the video, I can't compete with Rick Hickey. I just rewatched it and would probably modify what I wrote, but the main point is: it's better to not write a summarizing article or comment when that video is so great, so I won't try to write something smarter (rather try to apply the things he said in the video).

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

#57

Post by hinkley »

hinkley wrote: post #8
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…

Obligatory Simple Made Easy link: https://www.youtube.com/watch?v=SxdOUGdseq4 Simple is a matter of intuition, and that can't be transmitted to others easily, or with a single class or book. At one particular job we got punished by the business for calling things 'easy' when what we mean is that we understand the problem and all of the steps are (mostly) known. Our boss coached the hell out of us to say 'straightforw…

I am taking my own advice and re-watching this presentation. I'm being surprised enough by parts I don't remember that I've decided that I need to watch this video at least once a year.

Certainly there are some things I've just forgotten, and others I just wasn't ready to hear.

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

#58

Post by xiphias2 »

RangerScience wrote: post #55
addaon wrote: post #17

Earlier quoted context omitted.

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

I like to use SMBC's take[1] on the "Watchmaker Analogy" - complexity comes from, in order: (1) number of things interacting (2) complexity of interaction (3) complexity of thing So simplicity is then an inversion of that. You can "maximize simplicity" by: (1) minimizing the number of things (2) minimizing the complexity of interaction (3) minimizing the complexity of each thing This ends up reinventing many of thing…

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.

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

#59

Post by IshKebab »

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…

Yes exactly. The simplest thing that "works" is string and duck tape.

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

#60

Post by Xeoncross »

kemiller2002 wrote: post #42
Xeoncross wrote: post #39

I wish I could convince product teams that the MVP is often just a single feature. Like a search bar + results page. Something we can ship very fast, then we can add the banners, tracking for marketing, account creation, user ratings, community forums, results commenting and sharing, image carousels and a mobile app with push notifications that the results changed. You know, the regular MVP stuff. So many people thin…

My voice is hoarse from saying this so many times. It's a constant battle trying to explain that it's not perfect, but we can't improve on it based on feedback, if it's not done.

It often seems to be the illusion (confusion?) of adding enough features will somehow make this product useful because 1) I know about facebook/amazon/google and 2) it's successful and 3) has all the stuff.
Post reply on HN