The Power of Simplicity

Bug tickets overflowing, more features than you can shake a stick at, and coffee-break-level loading times.
Dependencies upon dependencies, and layers upon layers.
Does it have to be this way?

I would argue that we can all benefit from an infusion of simplicity.
Whether we're talking about software, art, life, or food, going back to the basics and building up again (while keeping it simple) is often just what is needed.
It can be tempting to assume all sorts of things are necessary, to solve all sorts of problems/needs, but oftentimes it is perfectly fine to not solve a problem.

KISS and YAGNI

I am not particularly a fan of buzzword-driven development, and these four-letter-all-caps words often serve to enforce some narrow idea.
But "Keep It Simple, Stupid¹", and You Ain't Gonna Need It are my favourite guiding principles.

But, but!! It has to be able to X while Y is happening and maybe somebody does Z!!!

Maybe, or maybe that is an unreasonable constraint.
When developing software, you are essentially acting as a human constraint solver.
You have a certain problem space, where there is a goal to fulfill and various edge cases and particular circumstances to deal with. Real life is of course, not simple after all.
But you are not forced to stretch the solution space to the problem space. Not all constraints should be weighed equally.
There is the purpose that the software is supposed to solve, and the main guiding principles. Then there are all the edge cases.
Often times the edge cases are important to solve, but not if that creates even more edge cases, or if it greatly reduces the quality of more important goals.

It is perfectly reasonable to say "this is not a sane situation".

Well, we may need to change this in the future!

Sure, but then you can just change it.
It is very tempting to make a very flexible and configurable System (with a capital S), that has multiple layers and API entry points, and overrides.
But is that better than Just Changing The Code™?
Think about it, how often is the case that you go through a codebase and it takes a huge amount of Jump to Definition presses to get to the part that actually does the thing.
What if it just did the thing from the beginning? Does it need to be a comprehensive plugin system with config files? Or should it just be a very simple and easily modifiable piece of code that anyone can understand at a glance?

Of course the broad picture may be more complicated, but each component can be kept simple if some self-control is applied.
Just one function, no out-of-band config, takes in some data and spits out a modified version of it.
See how far you can get with this. You'll know it when it gets too far, and if you succesfully kept it simple you can easily split things out to maintain simplicity.

Code is disposable, but Data are forever

There is too much attention spent on discussing code, writing code, architecting code.
But code is there to solve a problem, and if the problem changes or the circumstances change, your code is gonna need to change.
No denying reality, no excess future-proofing by making every single line of code into a separate overridable class with 15 virtual functions, just write it once and then write something else the next time.

But not data, data is truly forever².
Spend not time on landscaping beautiful code, spend time on simple and understandable data structures.
Spend not time on future-proofing code, spend time on having data migration strategies.
Spend not time on making the code your interface, spend time on universal and interoperable data.
Code is just there to service the data. Keep your data simple, and your code disposable.

Consider a typical Object-Oriented program, where the highest goal is to prevent anyone from ever knowing where any of the data is, at the smallest granularity possible.
What do you do with this? All you can do is just keep making more interfaces, and more managers, and more abstractions.
But what if you just had all your data right there?
You have the data, and then you just need a collection of procedures that transform the data.
No more pretending, just keep the data understandable and write whatever needs to happen with it whenever you need, and delete it when you need some other type of transformation.
Maybe split it all into a handful of different pieces, whatever feels natural to keep the problem space manageable.
Keep a good distinction between persistent data, runtime data, and temporary/disposable/implementation-specific data.

Minimalism?

Extreme spartan minimalism is not for everyone, and I would not necessarily consider myself a full-on minimalism.
There are folks out there perfectly fine with having a room that has nothing but a desk and a bed. No sofa, no dining table, no shelves or plants or even curtains.
On the other hand, there are rooms out there that are overflowing with furniture and paintings and plants and all sorts of decorative trinkets.
One feels cold and uninviting, and the other feels like an overbearing outburst of personality.

Balance is good to strive for. Enterprise FizzBuzz is the overbearing maximalist room, but you don't need to go full suckless and make everything a <1000k C file.
But it is a worthy exercise to attempt the latter as a starting point, adopt simplicity, and be cautious about things spinning out of control.
Starting with the bare minimum doesn't mean you can never grow your feature set.
You can have a large quantity of things, without them being chaotic and hard to reason about.
Ordered clutter, not chaotic mess.

Conclusion

This was a brain-dump about simplicity, but the article itself was perhaps not as simple as it could be. Quite ironic.
This does hint at the concept of simple does not mean easy.
To the next time, when I will attempt to apply my advice to the article and start from clear examples.

Until then, please enjoy this simple sunset.