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.