Live data from Hacker News

Do the simplest thing that can possibly work (2004)

twasink.net

81–90 of 95 posts

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

#81
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.

And, to add a bit more nuance, simplicity can also depend on the stage a project is at... It may be really simple to implement core functionality to demonstrate an idea, but developing on that code can add a lot of complexity later. For example, adding security late in a project is almost always much more difficult than adding a small amount up front. Even the simple to implement metric can be a difficult judgement c…

I haven't been able to distill it to first principles yet, but I do have a practice of writing code in such a way that it invites the next step.

I suspect that at first I did this in an attempt to hack my own sense of motivation, like putting the books you need to return next to the front door. But it turned out to be quite handy for seducing junior developers (and sometimes senior developers) into finishing an idea that you started.

They are so proud that they've thought of something you didn't think of, rather than something you were looking for a maintainer/free cycles for.

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

#82
As a relatively newbie software developer, I'm going to ignore this advice and just try to cobble together something that works and I'm deliberately not going to worry about whether or not there is a simpler, cleaner solution to the problem. The rationale is, if I keep searching for the simpler cleaner solution I'll keep falling down rabbit holes and never get to the point of having a solution to the problem at hand. After the fact, if someone comes along and says, 'hey, here's a simpler solution' that's great, but if I don't at least have a working project, nobody will even bother to deliver that helpful input.

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

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

I like to distinguish complexity from complication: the former requires cleverness to understand more of; the latter time and effort.

In the simple case of a solo project, as much complexity as you understand is fine; in a team you obviously need some idea of a threshold, not that you could quantitatively define it. Complexity isn't necessary, though isn't a problem - complication on the other hand is always bad, it's just making things hard to reason about, but may be necessary if the only alternative is adding unacceptable complexity.

The problem with discussing 'simplicity' is that it's an antonym for both complexity and complicatedness.

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

#84
post #54
post #51

Earlier quoted context omitted.

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

Irrelevant point of order: leftpad didn't get hacked, the owner took it down to prove a point and broke every package that depended on it as npm allowed packages to just be completely removed by the authors at that time.

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

#85

As a relatively newbie software developer, I'm going to ignore this advice and just try to cobble together something that works and I'm deliberately not going to worry about whether or not there is a simpler, cleaner solution to the problem. The rationale is, if I keep searching for the simpler cleaner solution I'll keep falling down rabbit holes and never get to the point of having a solution to the problem at hand.…

[flagged]

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

#86

As a relatively newbie software developer, I'm going to ignore this advice and just try to cobble together something that works and I'm deliberately not going to worry about whether or not there is a simpler, cleaner solution to the problem. The rationale is, if I keep searching for the simpler cleaner solution I'll keep falling down rabbit holes and never get to the point of having a solution to the problem at hand.…

> As a relatively newbie software developer, I'm going to ignore this advice

As a relatively senior software developer, I'd say don't worry about it too much. The article accepts that reducing complexity is hard, and it's ok if you can't make it any simpler. Try not to add intentional complexity when you can, because statistically speaking, YAGNI.

This industry is full of clowns trying to upsell things that nobody needs, just don't fall for it.

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

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

Comparative simplicity requires you to accurately imagine the entire lifecycle of each alternative.

This is a lot of work. And your prediction can end up wrong anyway (by your mistake or by the world changing).

How are we then to make choices? Perhaps just, if one solution seems clearly simpler (to you), then choose that. If one looks unnecessarily complex, don't choose that.

Simpl-est derails us perfectionist programmers. So maybe "Do the simpler thing that can possibly work"

"You don't need to know a man's weight to know that he's fat" - Benjamin Graham.

EDIT "Could possibly work" also implies a lack of foreknowledge as to its actual simplicity, or whether it will function correctly... or at all.

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

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

That said, can't barcode be replaced with something easy to generate and read like braille?

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

#90
post #7

Earlier quoted context omitted.

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.

SLIP uses byte stuffing to reserve its end-of-frame sequence, which leads to data-dependent packet transmission times, which is not acceptable in my application.
Post reply on HN