FOMO? YAMO.

A whole new way of seamlessly “hydrating” and building “reactive” webpages, proclaim the dozen new Javascript frameworks that offer slightly different ways of manipulating DOM; new stacks for generating static webpages from templates; new ways of deploying “no-code” apps to “serverless edges”; memory-safe languages that enable error-free programs; NoSQL databases that offer unlimited scalability; CSS frameworks that forever change how webpages are styled; new paradigms of visualizing programs as containers and not processes, container orchestration and not process management; functional programming over imperative over object oriented; “AI/ML” for whatever one pleases … magic bullets for everything.

The year is 2022, a software developer has infinite choices, all software problems have been solved, and all technology paradigms have been shifted. Except, a couple of months ago, a bug in log string processing caused global panic^[1], and the largest social networks and communication apps disappeared from the internet after an incorrect config push^[2], amongst many other similar incidents that continue to transpire regularly. So, all problems have not really be fixed and trivial changes in software can have massive repercussions.

If one were to go by the promises and hype around certain software and the vigour with which their creators and their adherents push them, the zeal with which the evangelists berate “old school” ways of doing things (like running ./program instead of docker-compose up program; styling a single webpage by hand instead of using a certain utility-class CSS framework; rsyncing a file to a destination instead of pushing it through a CI/CD “pipeline”—all witnessed firsthand), one would wonder why, after an infinite series of paradigm shifting, silver-lining, edge cutting, magic bullet software releases, there are any problems left in software at all, let alone the millions of CRUD apps that slow down daily for unquantifiable reasons, or bad config that cause massive outages at the world’s biggest tech companies, or log string evaluation bugs in software maintained by a couple of people, create global repercussions. Maybe, because hype is just that, hype, and most software marketing and promises are hollow, intentionally or otherwise. Maybe that’s because half a century of software history trivially shows one—if one cares to look—that things seldom change fundamentally and conceptually anymore, and most software just offer marginal advancement (or deterioration) over others.

Drowning in the great cacophony of incessant marketing hype of new software releases by people and organisations that seek to profit, be it by selling courses, consulting, SaaS subscriptions, or hosting, how can a developer, a beginner at that, make objective software decisions, given they lack historical context and hands on experience with many different avatars of said software. This lack of experience sows the seeds of FOMO, and in a vicious cycle, FOMO induced decisions in high likelihood re-inforce more poor decisions and more FOMO in turn.

What could I say to that one developer who could publish a website with “Jamstack” on a CDN via a Git hook, but could not comprehend writing an index.html and copying it to a directory linked to a webserver? The reductio ad absurdum argument “but no one writes assembly anymore either!” isn’t comparable. The developer who only knows how to publish a Jamstack webpage on a CDN and who has never rsync’d an index.html somewhere, will obviously perpetuate their only way of publishing a webpage, until they actually write an index.html and rsync it, which is unlikely to happen in an environment where there are similar developers. A developer whose foundation is an SQL-killer NoSQL database is highly likely to dismiss SQL databases and inadvertently reinvent shoddy SQL-like behaviour in their software when attempting to generate reports with simple aggregates and JOINs. And because this foundation is likely based on claims of magical simplicity and scalability, there is a high likelihood that when a new database comes along touting simpler simplicity, there is higher odds of compulsion to switch. Marketing hype and drivel play a key role in perpetuating confusion and FOMO. Again, things I have witnessed first hand several times.

Of course, on the other extreme is the absolute reluctance to change, thanks to ignorance and incompetence. Developers who still write PHP 5 and deploy MySQL 5.6.10 to RHEL5 servers and use “double encryption” schemes that became obsolete a decade ago. That is a different discussion altogether.

FOMO (fear of missing out)

As the Google Books n-gram graph for the word FOMO below shows, the term took centre stage in the last decade, apparently fuelled in all its might by the proliferation of pervasive social media connectedness^[3]. It is the fear and regret of missing out on events, lifestyle, financial investments, experiences … and for developers, software. The fear of being stuck in old school ways of solving problems, being left in the dust using uncool or older software while the world advances rapidly to cutting edge technologies, while software job requirements shift to seeking expertise in the bleeding edge. The fear of being left out when one’s peers are all coding away in bleeding edge technology, creating rapid, sustained innovation. Why record transactions in a database when it can be recorded in a private two-node blockchain? Here though, one is not like the others; software. Software is a tool for solving problems that can be swapped and replaced freely any time in the future (given that it is used and developed sensibly in a replaceable manner^[4]) unlike a past event that cannot be re-lived. Software can be reused and re-lived.

So, what does it mean to miss out on software? To understand this question objectively, one must peel back all the layers of the usecase onion. What is the crux of the matter in building a website with Jamstack using Git triggers to publish it to a CDN? That there is information to be disseminated and that a website is the medium chosen to do so (could have been a PDF that is e-mailed, or a god forbid, an info-only mobile app) is the crux of the onion. Now, how many pages does the website have? How complex is the layout? How often will it be updated? How many people will update it? These are really the factors, the onion peels, that need to be objectively evaluated when picking the means of achieving the goal, disseminating information as a website.

If the website is just a couple of pages that is unlikely to change periodically, then writing an index.html and dragging and dropping it to a CDN’s or webhost’s UI would be the quickest, most efficient way to do it. If the pages are likely to change, perhaps at the hand of multiple people, then bringing in version control makes sense. If there are a number of pages, a templating system or a static site generator starts making sense. If there are all of these things and more, then something like a version controlled Jamstack setup that automatically deploys to a CDN starts making sense. If there are many non-technical editors, then a CMS may make more sense.

Similarly, when writing software, the crux, its dependencies, external orchestration etc. should be layered on top. A simple CRUD app with a handful of users and basic admin is probably best written in Django (given the developers know Django) before straying into evaluating more sophisticated or trendy ways of solving the small problem.

What is the point?

The point is, the decision to use software, any software, needs to be carefully and objectively constructed, with peels (means, methods, tools—Jamstack, Git, containers, rsync, CI/CD, “AI/ML”, whatever …) carefully layered on top of the crux, the actual goal, creating the onion that is the cohesion of many a software that solve problems meaningfully. When there is a requirement to build a website, the first response should not be “let’s use Jamstack! and Tailwind! and GitHub actions! and Netlify!”. It should be along the lines of “Why? What is it for?”. Similarly, the first response to a requirement to build server software should not be the contemporary “microservices or monolith?”.

When one wants to drink tea, no one asks whether they prefer the water boiled on a gas stove, or in an electric kettle, or in the microwave, or with a solar heater. It is irrelevant. People use common sense to pick whatever is available and what fits the job to make drinkable tea, the ultimate goal. Then why is it that in software, there are numerous kettles looking for problems other than boiling water? NoSQL DBs that are the solution to all data problems; container technologies that are the solution to all deployment problems; Javascript frameworks that are the final frontiers to web development—ad infinitum.

Carl Sagan’s quote, “If you wish to make an apple pie from scratch, you must first invent the universe”, is most pertinent in software when one deconstructs software and its goals.

But what’s all of this got to do with FOMO, a psychological phenomenon that transcends feelings for software. True, it is extremely difficult to quantify like any other psychological phenomena, but the ability to resist FOMO and disarm FOMO attacks in software, is far easier to attain than in other areas of life. It starts with the exercise of objectively deconstructing goals like in the aforementioned examples and asking simple questions. “Why? Why not? What’s the point?”. Some real examples of poor FOMO induced choices and scenarios that I encountered in the recent past.

• Why is the file being rsync’d instead of an S3-Ansible-pipeline? — Why not?
• Why is there a full fledged Node build environment for a page with a form?
• Why is the CSS hand-written (for a single page site)? — Why not?
• Why is there no K8s manifest for the project? — Why should it?
• Why was this desktop application (200 MB) with two buttons written in Electron?
• ElasticSearch instance to make 100k items searchable. — What? Why!?
• “AI/ML pipeline” for detecting anomalous (deviations from baseline prices) transactions. — What? Why!?
• Why not rewrite it in Rust to make it safe? — …

When software decisions are based on critically thought out objective answers to questions such as Why? Why not? What for?, it gradually helps grasp the fundamental first principles that underlie most software and software decisions irrespective of the industry, which in turn increases the odds of making better decisions and seeing through any feelings of FOMO. It’s important to remember that the burden of answering such questions objectively is on the decision maker or on the FOMO inducer. That does sound like the case with life in general.

YAMO (you ain’t missing out)

Really though, with software, I’ve come to realise that it is actually hard to miss out. Between meatware, hardware, and software, software is the most malleable, ephemeral, and cyclical. Decades old software can be brought up in an instant. It can be used, scrapped, reused, changed. Fundamentally, the concept of missing out on something so transcendental does not make sense. If one somehow does manage to “miss out” on software and their FOMO comes true, it is possible to just catch up and adapt.

This website has been online since 2001 in many forms. Written in Perl/CGI, PHP, plain HTML, published via a web hosting UI, a Java applet, FTP, SFTP, to the current static site generated from simple templates and rsync’d to a VM somewhere. All along, the site has been online and has transitioned from one technology to another with time (many things need not transition so many times). The Olam dictionary has been running the same few scripts and database for 12 years, and is used by millions of people regularly. Or the numerous unfashionable FOSS tools that we self-host at work (Zerodha) saving the us many millions of dollars every year^[5]. Over the last nine years, not once have we felt that we have missed out on any software trend. We have freely scrapped and swapped out pieces as warranted by various situations, but never by what is trendy. Our aversion to SaaS dependencies and our practice of self-hosting FOSS wherever remotely possible has enabled this. If one’s stuck with proprietary software, it could be different through.

Software trends come and go. You ain’t missing out. Really, with FOSS, one can’t miss out on software. It just doesn’t make sense.