5 ms·

> 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 “bes

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

tbrownaw 1y ago
Consider for example, computerizing a currently-manual process. And the 80/20 rule. Do you handle one "everything is perfect" happy path, and use a manual exception process for odd things? Do you handle "most" cases, which is more tech work but shrinks the number of people you need handling one-off things? Or do you try to computerize everything no matter how rare?
- tonyarkles 1y ago
  My favourite example of this from my own career... automating timesheet -> payroll processing in a unionized environment. As we're converting the collective bargaining agreement into code, we discover that there are a pair of rules that seem contradictory. Go talk to someone in the payroll department to try to figure out how it's handled. Get an answer that makes decent sense, but have a bit of a lingering doubt about the interpretation. Talk to someone else in the same department... they tell us the alternative interpretation. Bring the problem back to our primary contact and they've got no clue what to do. They're on like year 2 of a 7 year contract and they've just discovered that their payroll department has been interpreting the ambiguous rules somewhat randomly. No one wants to commit to an interpretation without a memorandum of understanding from the union, and no one wants to start the process of negotiating that MoU because it's going to mean backdating 2 years of payroll for an unknown number of employees, who may have been affected by it one month but not the next, depending on who processed their paystub that month. That was fun :D
  - mcny 1y ago
    So effectively the company was stealing people's pay
    - tonyarkles 1y ago
      Heh, to make it more fun… it wasn’t actually clear if they were overpaying or underpaying. Underpaying is actually a lot easier to deal with than overpaying. If you underpay someone, the easy solution is to write a cheque and include interest and/or some other form of compensation for the error. If you overpay someone… getting that money back is a challenge. To make it more complicated still, there was an element of “we’re not sure if we overpaid or underpaid” but there was also an element of “we gave person X an overtime shift but person Y was entitled to accept or deny that shift before person X would have even had an opportunity to take it”. That’s even harder to compensate for.
      - mcny 1y ago
        Thank you for the reply. I was only commenting that wage theft is still wage theft even when there is no malicious intent. Clearly, reality is much more nuanced.
    - eadmund 1y ago
      Or overpaying them. Or sometimes underpaying and sometimes overpaying them. Or paying them the right total amount, but incorrectly labelling subtotals. There’s no reason to leap to ‘stealing’ (which requires intent) from ‘ambiguous rules.’ Those ambiguous rules, incidentally, may have been agreed to — or even insisted on — by the union!
  - scarface_74 1y ago
    Wouldn’t the simplest thing possible in that case probably just use one of the many SaaS payroll services? If the second largest employer in the US can use ADP, I’m almost sure your company could.
    - tonyarkles 1y ago
qaq 1y ago
Is the simplest thing possible still the DB? Yes thats why google spent decent amount of resources building out spanner because for many biz domains even at hyper scale it's still the DB.
XorNot 1y ago
I have worked at too many companies where the effort spent not using a simple database was an exponential drag on everything. Hell I just spent a week doing something which should've taken 5 minutes because rather then a settings database, someone has just been maintaining a giant ball of copy+pasted terraform code instead.
- fmbb 1y ago
  A giant ball of copypasted Terraform is not the simplest thing that could possibly work. Adding the runtime complexity and maintenance work for a new database server is not a small decision.
  - deleted 1y ago
    [deleted]
sodapopcan 1y ago
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.
- achierius 1y ago
  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
  - oivey 1y ago
    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.
  - fruitplants 1y ago
    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 https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork 2. https://wiki.c2.com/?SimplestOrEasiest https://wiki.c2.com/?SimplestOrEasiest
  - baxtr 1y ago
    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.
quietbritishjim 1y ago
> 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.
- lll-o-lll 1y ago
  > 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.
- devnullbrain 1y ago
  Then the title just means 'do the right thing' and has no value.
  - 1y ago
neonrider 1y ago
> I think the nuance here is that “the simplest thing possible” is not always the “best solution”. The programmer's mind is the faithful ally of the perfect in its war waged against the good enough. The "best" solution for most people that have a problem is the one they can use right now.
- mpweiher 1y ago
  And in the context of XP, which is where DTSTTCPW comes from: The one you can use right now in order to get feedback from real world use, which will be much better at guiding you in improving the solution than what you thought was "best" before you had that feedback. Real world feedback is the key. Get there as quickly as feasible, then iterate with that.
mattlutze 1y ago
No pop psychology maxim is universally true. However in your example we're presented with the outdated understanding of "tech debt." > As an example, it is possible to solve very many business or operational problems with a simple service sitting in front of a database. If this is the simplest approach within the problem space or business's constraints, and meets the understood needs, it may indeed be the right choice. > 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? No problem in a dynamic human system can be solved statically and left alone. If the demands on a solution grows, and the problem space or business's needs changes, then the solution should be reassessed and the new conditions solved for. Think of it alternatively as resource-constrained work allocation, or agile problem solving. If we don't have enough labor available (and we rarely do) to solve everything "best," then we need to draw a line. Decades of practice now have shown that it's a crap shoot to guess at the shape of levels of complexity down the road. Best case you spend time that could go into something else valuable today, to solve a problem for a year from now; worst case you get the assumptions wrong and fail to solve that second "today" problem as well as still needing to spend future time on refactoring.
strogonoff 1y ago
The apparent discrepancy between “the simplest thing possible” and “the best solution” only exists if we forget that a product exists in time. If the goal is not just an app that works today but something that won’t break tomorrow, that changes what the simplest thing is. If what seems like the simplest thing makes it difficult to maintain, have many poorly vetted dependencies, etc., then that is not really the simplest thing anymore. When this is accounted for, “the simplest thing” approaches “the best solution”.

tbrownaw 1y ago

Consider for example, computerizing a currently-manual process. And the 80/20 rule. Do you handle one "everything is perfect" happy path, and use a manual exception process for odd things? Do you handle "most" cases, which is more tech work but shrinks the number of people you need handling one-off things? Or do you try to computerize everything no matter how rare?

tonyarkles 1y ago
My favourite example of this from my own career... automating timesheet -> payroll processing in a unionized environment. As we're converting the collective bargaining agreement into code, we discover that there are a pair of rules that seem contradictory. Go talk to someone in the payroll department to try to figure out how it's handled. Get an answer that makes decent sense, but have a bit of a lingering doubt about the interpretation. Talk to someone else in the same department... they tell us the alternative interpretation. Bring the problem back to our primary contact and they've got no clue what to do. They're on like year 2 of a 7 year contract and they've just discovered that their payroll department has been interpreting the ambiguous rules somewhat randomly. No one wants to commit to an interpretation without a memorandum of understanding from the union, and no one wants to start the process of negotiating that MoU because it's going to mean backdating 2 years of payroll for an unknown number of employees, who may have been affected by it one month but not the next, depending on who processed their paystub that month. That was fun :D
- mcny 1y ago
  So effectively the company was stealing people's pay
  - tonyarkles 1y ago
    Heh, to make it more fun… it wasn’t actually clear if they were overpaying or underpaying. Underpaying is actually a lot easier to deal with than overpaying. If you underpay someone, the easy solution is to write a cheque and include interest and/or some other form of compensation for the error. If you overpay someone… getting that money back is a challenge. To make it more complicated still, there was an element of “we’re not sure if we overpaid or underpaid” but there was also an element of “we gave person X an overtime shift but person Y was entitled to accept or deny that shift before person X would have even had an opportunity to take it”. That’s even harder to compensate for.
    - mcny 1y ago
      Thank you for the reply. I was only commenting that wage theft is still wage theft even when there is no malicious intent. Clearly, reality is much more nuanced.
  - eadmund 1y ago
    Or overpaying them. Or sometimes underpaying and sometimes overpaying them. Or paying them the right total amount, but incorrectly labelling subtotals. There’s no reason to leap to ‘stealing’ (which requires intent) from ‘ambiguous rules.’ Those ambiguous rules, incidentally, may have been agreed to — or even insisted on — by the union!
- scarface_74 1y ago
  Wouldn’t the simplest thing possible in that case probably just use one of the many SaaS payroll services? If the second largest employer in the US can use ADP, I’m almost sure your company could.
  - tonyarkles 1y ago

qaq 1y ago

Is the simplest thing possible still the DB? Yes thats why google spent decent amount of resources building out spanner because for many biz domains even at hyper scale it's still the DB.

XorNot 1y ago

I have worked at too many companies where the effort spent not using a simple database was an exponential drag on everything. Hell I just spent a week doing something which should've taken 5 minutes because rather then a settings database, someone has just been maintaining a giant ball of copy+pasted terraform code instead.

fmbb 1y ago
A giant ball of copypasted Terraform is not the simplest thing that could possibly work. Adding the runtime complexity and maintenance work for a new database server is not a small decision.
- deleted 1y ago
  [deleted]

sodapopcan 1y ago

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.

achierius 1y ago
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
- oivey 1y ago
  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.
- fruitplants 1y ago
  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 https://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork 2. https://wiki.c2.com/?SimplestOrEasiest https://wiki.c2.com/?SimplestOrEasiest
- baxtr 1y ago
  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.

quietbritishjim 1y ago

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

lll-o-lll 1y ago
> 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.
devnullbrain 1y ago
Then the title just means 'do the right thing' and has no value.
- 1y ago

neonrider 1y ago

> I think the nuance here is that “the simplest thing possible” is not always the “best solution”. The programmer's mind is the faithful ally of the perfect in its war waged against the good enough. The "best" solution for most people that have a problem is the one they can use right now.

mpweiher 1y ago
And in the context of XP, which is where DTSTTCPW comes from: The one you can use right now in order to get feedback from real world use, which will be much better at guiding you in improving the solution than what you thought was "best" before you had that feedback. Real world feedback is the key. Get there as quickly as feasible, then iterate with that.

mattlutze 1y ago

No pop psychology maxim is universally true. However in your example we're presented with the outdated understanding of "tech debt." > As an example, it is possible to solve very many business or operational problems with a simple service sitting in front of a database. If this is the simplest approach within the problem space or business's constraints, and meets the understood needs, it may indeed be the right choice. > 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? No problem in a dynamic human system can be solved statically and left alone. If the demands on a solution grows, and the problem space or business's needs changes, then the solution should be reassessed and the new conditions solved for. Think of it alternatively as resource-constrained work allocation, or agile problem solving. If we don't have enough labor available (and we rarely do) to solve everything "best," then we need to draw a line. Decades of practice now have shown that it's a crap shoot to guess at the shape of levels of complexity down the road. Best case you spend time that could go into something else valuable today, to solve a problem for a year from now; worst case you get the assumptions wrong and fail to solve that second "today" problem as well as still needing to spend future time on refactoring.

strogonoff 1y ago

The apparent discrepancy between “the simplest thing possible” and “the best solution” only exists if we forget that a product exists in time. If the goal is not just an app that works today but something that won’t break tomorrow, that changes what the simplest thing is. If what seems like the simplest thing makes it difficult to maintain, have many poorly vetted dependencies, etc., then that is not really the simplest thing anymore. When this is accounted for, “the simplest thing” approaches “the best solution”.