Most active commenters

    ←back to thread

    Do the simplest thing that could possibly work

    (www.seangoedecke.com)
    1070 points dondraper36 | 14 comments | 29 Aug 25 19:05 UTC | HN request time: 0.001s | source | bottom
    Show context
    codingwagie ◴[29 Aug 25 20:39 UTC] No.45069135[source]▶
    I think this works in simple domains. After working in big tech for a while, I am still shocked by the required complexity. Even the simplest business problem may take a year to solve, and constantly break due to the astounding number of edge cases and scale.

    Anyone proclaiming simplicity just hasnt worked at scale. Even rewrites that have a decade old code base to be inspired from, often fail due to the sheer amount of things to consider.

    A classic, Chesterton's Fence:

    "There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”"

    replies(44): >>45069141 #>>45069264 #>>45069348 #>>45069467 #>>45069470 #>>45069871 #>>45069911 #>>45069939 #>>45069969 #>>45070101 #>>45070127 #>>45070134 #>>45070480 #>>45070530 #>>45070586 #>>45070809 #>>45070968 #>>45070992 #>>45071431 #>>45071743 #>>45071971 #>>45072367 #>>45072414 #>>45072570 #>>45072634 #>>45072779 #>>45072875 #>>45072899 #>>45073114 #>>45073174 #>>45073183 #>>45073201 #>>45073291 #>>45073317 #>>45073516 #>>45073758 #>>45073768 #>>45073810 #>>45073812 #>>45073942 #>>45073964 #>>45074264 #>>45074642 #>>45080346 #
    sodapopcan ◴[29 Aug 25 22:30 UTC] No.45070127[source]▶
    This is the classic misunderstanding where software engineers can't seem to communicate well with each other.

    We can even just look at the title here: Do the simplest thing POSSIBLE.

    You can't escape complexity when a problem is complex. You could certainly still complicate it even more than necessary, though. Nowhere in this article is it saying you can avoid complexity altogether, but that many of us tend to over-complicate problems for no good reason.

    replies(7): >>45070394 #>>45070713 #>>45072375 #>>45072947 #>>45073130 #>>45074955 #>>45079503 #
    lll-o-lll ◴[29 Aug 25 23:03 UTC] No.45070394[source]▶
    > We can even just look at the title here: Do the simplest thing POSSIBLE.

    I think the nuance here is that “the simplest thing possible” is not always the “best solution”. As an example, it is possible to solve very many business or operational problems with a simple service sitting in front of a database. At scale, you can continue to operate, but the amount of man-hours going into keeping the lights on can grow exponentially. Is the simplest thing possible still the DB?

    Complexity is more than just the code or the infrastructure; it needs to run the entire gamut of the solution. That includes looking at the incidental complexity that goes into scaling, operating, maintaining, and migrating (if a temporary ‘too simple but fast to get going’ stack was chosen).

    Measure twice, cut once. Understand what you are trying to build, and work out a way to get there in stages that provide business value at each step. Easier said than done.

    Edit: Replies seem to be getting hung up over the “DB” reference. This is meant to be a hypothetical where the reader infers a scenario of a technology that “can solve all problems, but is not necessarily the best solution”. Substitute for “writing files to the file system” if you prefer.

    replies(8): >>45070526 #>>45070559 #>>45070597 #>>45070639 #>>45070889 #>>45070897 #>>45072898 #>>45073722 #
    sodapopcan ◴[29 Aug 25 23:45 UTC] No.45070639[source]▶
    Right, and again this is reading too much into it. The simplest thing possible does not mean the best solution. If your solution that worked really well yesterday no longer scales today, it's no longer the correct solution and will require a more complex one.
    replies(2): >>45071988 #>>45072897 #
    1. achierius ◴[30 Aug 25 04:52 UTC] No.45071988[source]▶
    But sometimes it IS better to think a few steps ahead, rather than building a new system from scratch every time things scale up. It's not always easy to upgrade things incrementally: just look at IPv4 vs IPv6
    replies(8): >>45072124 #>>45072267 #>>45072373 #>>45072515 #>>45072559 #>>45072870 #>>45074205 #>>45078662 #
    2. oivey ◴[30 Aug 25 05:34 UTC] No.45072124[source]▶
    It can be hard enough to fix things when some surprise happens. Unwinding complicated “future proof” things on top of that is even worse. The simpler something is, the less you hopefully have to throw away when you inevitably have to.
    3. fruitplants ◴[30 Aug 25 06:06 UTC] No.45072267[source]▶
    I agree with thinking a few steps ahead. It is particularly useful in case of complex problems or foundational systems.

    Also maybe simplicity is sometimes achieved AFTER complexity, anyway. I think the article means a solution that works now... target good enough rather than perfect. And the C2 wiki (1) has a subtitle '(if you're not sure what to do yet)'. In a related C2 wiki entry (2) Ward Cunningham says: Do the easiest thing that could possibly work, and then pound it into the simplest thing that could possibly work.

    IME a lot of complexity is due to integration (in addition to things like scalability, availability, ease of operations, etc.) If I can keep interfaces and data exchange formats simple (independent, minimal, etc.) then I can refactor individual systems separately.

    1. https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork

    2. https://wiki.c2.com/?SimplestOrEasiest

    4. baxtr ◴[30 Aug 25 06:28 UTC] No.45072373[source]▶
    Yes sometimes. But how can you know beforehand? It’s clear in hindsight, for sure.

    The most fundamental issue I have witnessed with these things is that people have a very hard time taking a balanced view.

    For this specific problem, should we invest in a more robust solution which takes longer to build or should we just build a scrappy version and then scale later?

    There is no right or wrong. It’s depends heavily on the context.

    But, some people, especially developers I am afraid, only have one answer for every situation.

    5. twbarr ◴[30 Aug 25 07:01 UTC] No.45072515[source]▶
    IPv6 is arguably a good example of what happens when you don't do the simplest thing possible. What we really needed was a bigger IP address space. What we got was a whole bunch of other crap. If we had literally expanded IPv4 by a couple of octets at the end (with compatible routing), would we be there now?
    replies(2): >>45073247 #>>45073948 #
    6. tonyedgecombe ◴[30 Aug 25 07:12 UTC] No.45072559[source]▶
    >But sometimes it IS better to think a few steps ahead

    The trouble is by the time you get there you will discover the problem isn't what you expected and it will all have been wasted effort.

    https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

    7. lelanthran ◴[30 Aug 25 08:13 UTC] No.45072870[source]▶
    > But sometimes it IS better to think a few steps ahead, rather than building a new system from scratch every time things scale up.

    The problem is knowing when to do it and when not to do it.

    If you're even the slightest bit unsure, err on the side of not thinking a few steps ahead because it is highly unlikely that you can see what complexities and hurdles lie in the future.

    In short, it's easier to unfuck an under engineered system than an over engineered one.

    replies(2): >>45076667 #>>45078684 #
    8. Sesse__ ◴[30 Aug 25 09:28 UTC] No.45073247[source]▶
    That “with compatible routing” thing pulls a lot of weight… I mean, if you have literal magic, then sure.

    Apart from that, IPv6 _is_ IPv4 with a bigger address space. It's so similar it's remarkable.

    9. xorcist ◴[30 Aug 25 12:10 UTC] No.45073948[source]▶
    In a place with even less IPv6 adoption, probably. It's not like there wasn't similar proposals discussed, and there's no need to rehash the exact same discussion again.

    The problem quickly becomes "how do you route it", and that's where we end up with something like today's IPv6. Route aggregation and PI addresses is impratical with IPv4 + extra bits.

    The main changes from v4 to v6 besides the extra bits is mostly that some unnecessary complexity was dropped, which in the end is net positive for adoption.

    10. kmacdough ◴[30 Aug 25 12:51 UTC] No.45074205[source]▶
    IPv4 vs IPv6 seems like a great example for why to keep it simple. Even given decades to learn from the success of IPv4 and almost a decade in design and refinement, IPv6 has flopped hard, not so much because of limitations of IPv4, but because IPv6 isn't backwards compatable and created excessive hardware requirements that basically require an entirely parallel IPv6 routing infrastructure to be maintained in addition to IPv4 infrastructure which isn't going away soon. It solved too far ahead for problems we aren't having.

    As is IPv4s simplicity got us incredibly far and it turns out NAT and CIDR have been quite effective at alleviating address exhaustion. With some address reallocation and future protocol extensions, its looking entirely possible that a successor was never needed.

    11. sevensor ◴[30 Aug 25 17:54 UTC] No.45076667[source]▶
    The best way to think a few steps ahead is to make as much of your solution disposable as possible. I optimize for ease of replacement over performance or scalability. This means that my operating assumption is that everything I’m doing is a mistake, so it’s best to work from a position of being able to throw it out and start over. The result is that I spend a lot of time thinking about where the seams are and making them as simple as possible to cut.
    12. yazantapuz ◴[30 Aug 25 22:48 UTC] No.45078662[source]▶
    But a 128 bit identifier maybe was not the best choice when ipv4 was in the works... maybe 64?
    13. devnullbrain ◴[30 Aug 25 22:51 UTC] No.45078684[source]▶
    Intel followed this strategy with the mobile market to what is apparently terminal fucking.
    replies(1): >>45080862 #
    14. lelanthran ◴[31 Aug 25 06:31 UTC] No.45080862{3}[source]▶
    > Intel followed this strategy with the mobile market to what is apparently terminal fucking.

    And they followed the alternative with Itanium, and look how that turned out.