“Stupid light software”
Martin Tournoij wrote about “stupid light software”. When you try to be a bit too minimalistic with your software, it’s probably “stupid light software”.
There’s also the concept of stupid light: when you save weight to the point of stupidity. You won’t be comfortable, you’ll miss stuff you need, your equipment will be too fragile and break.
With software I most often go from “heavy” to “light”. First, I try to realize the features I need and then I try to optimize where possible. First, I will use many libraries and after I got everything working, I will see if I really need all those libraries and may replace a whole library with a custom more simple implementation that still fits the needs.
A case for “stupid light” software is probably trying to use a static website when an optimized dynamic site is much more appropriate. You start to over-engineer a complex build workflow, when all that’s really needed to speed up a site is better caching.
It’s a good idea to avoid a database if you don’t need one; often flat text files or storing data in memory works just as well. But at the same time databases do offer some advantages: it’s structured and it deals with file locking and atomicity. A younger me would avoid databases at all costs and in hindsight that was just stupid light in some cases. You don’t need to immediately jump to PostgreSQL or MariaDB either, and there are many intermediate solutions, SQLite being the best known, but SQLite can also be stupid light in some use cases.
I have some experiences especially related to this point. When I developed Android apps, I tried to use flat text files too. But recently I discovered how awesome SQLite is. In some cases flat files are great, but especially when you need to parse those files or retrieve specific information from them, SQLite might be better than flat files. But in many cases SQLite could replace complex PostgreSQL or MariaDB databases, especially when concurrent writing isn’t needed.
Tags: Software SQLite