| What even does "keep it simple" mean. What even is "understandable". Every article about this sort of thing skips past the interesting arguments and assumes that their approach is the simple one, that their aim is simplicity. If you are presented with the option of an abstraction – perhaps a library or framework, perhaps a service or API – is it "simpler" to use it or to not? If you don't use it, and you build the alternative, you know more about how the system works as a whole, and therefore arguably it's simpler. But complexity is still introduced, and in some cases the abstraction layers still need to be built (but maybe not all of them). If you do use it, you can consider the system to be simpler because you hide the complexity, and on the happy-path of usage that may be true, but the complexity still exists and you don't understand it because it's hidden. Arguably it's simpler, but it's easy to point to how it's more complex. I've met engineers who strongly prioritise one or the other of these sorts, and to them that way is obviously simpler, but the problem is that both approaches are obviously simpler when you look at them in a certain way, you have to get past the obvious to realise that there are trade-offs. |
But if you want to make an apple pie from scratch, you first need to create a Universe, and you likely go for the simplest Universe that supports apple pies. The overall stack would be simpler (especially if you pursue simplicity and ease of understanding as a goal), but the last step, making the actual pie, may be more involved, and the taste of the resulting pie may be not top-notch. In exchange, you have a pie which you completely understand from first principles.