Title: Simple solution VS over-engineering | |
Author: Solène | |
Date: 13 May 2021 | |
Tags: software opensource | |
Description: | |
# Introduction | |
I wanted to share my thoughts about software in general. I've been | |
using and writing software for a long time and I've seen some patterns | |
over time. | |
# Simple solutions | |
I am a true adept of the "KISS" philosophy, in which KISS stands for | |
Keep It Simple Stupid, meaning make your software easy to understand | |
and not try to make it smart. It works most of the time but after you | |
reach your goal with your software, you may be tempted to add features | |
over it, or make it faster, or make it smarter, it usually doesn't | |
work. | |
# Over-engineering | |
In the opensource world, we have many bricks of software that we can | |
put together to build better tools, but at some point, you may use too | |
many of them and the service is unbearable in regards to maintenance / | |
operating, the current trend is to automate this by providing those | |
huge stacks of software through docker. It may be good enough for | |
users, it does certainly the job and it works, why should we worry? | |
# Failure and reversibility | |
When you use a complicated software, ALWAYS make sure you have a way | |
out: either replace product A with product B or make sure the code is | |
easy to fix. If you plan to invest yourself into deploying a complex | |
program that will store data (like Nextcloud or Paperless-ng), the | |
first question you should have is: how can I move away from it? | |
Why would you move away from something you are deploying right now | |
because it's good? Software can be unmaintained after some time and you | |
certainly don't want to run a network based obsolete program, due to | |
dependency hell it may not work in the future because it relies on some | |
component that is not available anymore (think python2 here), you may | |
have bugs after a long use that nobody want to fix and prevent you to | |
use the software correctly (scalability issue due to data growth). | |
There are tons of reasons that something can fail, so it's always | |
important to think about replacements. | |
- are the data stored in a way you can extract? data could be saved as | |
a plain file on the file system but could also be stored in some | |
complicated repositories format (ipfs) | |
- if data are encrypted, can you decrypt it? If it's GPG based, you can | |
always work with it, but if it's custom made chunk encryption like | |
Seafile does, it's a lot harder without the real program. | |
- if the software is packaged for your system, it may not be forever, | |
you may have to package it yourself in a few years if you want to keep | |
it up to date | |
- if you rely on external API, it may be not able indefinitely. Web | |
browser extensions are a good example, those programs have tightened | |
what extensions could do over time and many tricks had to be used to | |
migrate from API to API. When you rely on a extension, it's a real | |
issue when the extension can't work anymore. | |
# Build your own replacement? | |
There are many situations in which you may prefer to build your own | |
service with your own code than using a software ready on the shelf. | |
There are always pros and cons, you gain control and reliability over | |
features and ease of use. Not everyone is able to write such scripts | |
and you may fail and have to deal with the consequences when you do so, | |
this is something that must be kept in mind. | |
- backups: you could use rsync instead of a complex backup system | |
- "cloud" file storage: rsync/sftp are still a viable option to upload | |
a file "to the cloud" if you have a server, a simple https server would | |
be enough to share the file, the checksum of the file could be used as | |
an unique and very long file name. | |
- automation: a shell script executed over ssh could replace ansible or | |
salt-stack to some extent | |
There are many use case in which the administrator may prefer a | |
home-made solution, but in a company context, you may have to rely on | |
that very person instead of relying on a complex software, which moves | |
the problem to another level. | |
# Conclusion | |
There are many reasons a software could fail, be abandoned, not work | |
anymore, you should always assess such situations if you don't want to | |
build a fragile service. Easiest ideas have less features but are a | |
lot more reliable and resistant to time than complex implementations. | |
The more code you involve, the more issues you will have. | |
We are free to use what we want, in open source we are even free to | |
make changes to the code we use, this is fantastic. Choice always come | |
with pros and cons and it's always better to think before hand than | |
facing unwise consequences. |