Title: Simple solution VS over-engineering

	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.