←back to thread

1070 points dondraper36 | 5 comments | | HN request time: 0.001s | source
Show context
codingwagie ◴[] 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 ◴[] 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 ◴[] 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 #
1. quietbritishjim ◴[] No.45070889[source]
> 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?

Don't worry, the second half of the title has this covered:

> ... that could possibly work

In the scenario you've described, the technology is not working, in the complete sense including business requirements of reasonable operating costs.

Perhaps it really did work at first, in the complete sense, when the number of users was quite small. That's where the actual content of the article kicks in: it suggests you really do use that simple solution, because maybe you'll never need to scale after all, or you'll need to rewrite everything by then anyway, or you'll have access to more engineering talent by then, etc. I'd tend to agree, but with the caveat that you should feel free to break the rule so long as you're doing it consciously. But none of that implies that you should end up in the situation you described.

replies(2): >>45071232 #>>45073767 #
2. lll-o-lll ◴[] No.45071232[source]
> Perhaps it really did work at first, in the complete sense, when the number of users was quite small. That's where the actual content of the article kicks in: it suggests you really do use that simple solution, because maybe you'll never need to scale after all, or you'll need to rewrite everything by then anyway, or you'll have access to more engineering talent by then, etc.

This is where I am arguing nuance. These decisions are contextual; and the superficially more complicated solution may be solving inherent complexity in the problem space that only provides benefit over a time period.

As an example, some team might decide to forgo a database and read/write directly to the file system. This may enable a release in less time and that might be the right decision in certain contexts. Or it could be a terrible decision as the externalised costs begin to manifest and the business fails because of loss of customer trust.

My point is that you cannot only look at what is right in front of you, you also need to tactically plan ahead. In the big org context, you also need to strategically plan ahead.

3. devnullbrain ◴[] No.45073767[source]
Then the title just means 'do the right thing' and has no value.
replies(1): >>45075349 #
4. quietbritishjim ◴[] No.45075349[source]
No, it means don't (usually) over engineer a solution for a larger scale than you can be sure you'll need. If you don't see the value in that then you haven't worked with enough junior developers!
replies(1): >>45078665 #
5. devnullbrain ◴[] No.45078665{3}[source]
Well hold on, we're going in circles here

>In the scenario you've described, the technology is not working, in the complete sense including business requirements of reasonable operating costs.

In the parent comment's reasaonble premise, they wouldn't be sure of what they would need.