Fast-food vs Home-cooked Software

#engineering

Can you believe the pyramids have had 100% up-time with no human maintenance? If the pyramids can do it, why can't your notes app?

There are two very distinct ways of developing software:

  1. Fast food
  2. Home cooked

Fast Food

Here, we develop in "agile" sprints. Working software is developed at the fastest pace possible, and all bugs are to be fixed later. Do this forever until you can't. Testing is absolutely critical, and is the only way you can dare touch the code later. Documenting is a side-hustle.

Here, dependencies are added like seasoning. Hundreds of packages. Thousands of foreign lines of code make their way onto your software routinely.

Problems are expected and fixed on the fly, somewhat haphazardly:

The end result? A patchwork of barely strapped together code that requires endless man hours and actual human suffering to maintain and keep alive. Literally the entire project is tech debt. Yet most of the above qualifies for "best practice" today, so it feels good doing it.

My tone is quite cynical, but please take no offense - I do this everyday.

Home-cooked

Here, things are slower, more thoughtful. More waterfall-y.

This is where minimalist software is built. Not deliberately so, but by nature. No build process, no outside dependencies, and all lines written carefully to a predefined spec. Software magically guaranteed to just work a decade later, after all it's only a translation of your docs. Docs are the source of truth.

Testing isn't as critical (even if still necessary). There's no need to be constantly refactoring things, since everything was designed up to spec beforehand. A different spec is different software altogether.

The catch? Writing such a spec costs you over 80% of your engineering time, and you'll have nothing to show for it until day 100. The thing is, most humans are laughably bad at architecting software without actually writing it first. A bit of a paradox, but you don't know what you don't know. Agile development "fixes" this. You get to discover your spec on your user's time and end up releasing faster. In the end (and oddly so if this were the 90s), fast food is indeed faster to make. But is it worth it?

To me, this all stems from a certain greed software developers have. Just because we can, we do. I collect features like Pokemon and it's addicting. Meanwhile other engineering fields are far more humble. Your house doesn't require a team of agile developers to stay upright. Mechanical watches can run forever with no maintenance. Even your measly human body doesn't need weekly patches (well, this is could be a counter point).

Sadly, a good home-cooked meal is hard to find nowadays. Fast food is just too good to beat. Unlike fast food though, bad software doesn't kill you (usually), and so no one cares about writing healthy software. Maybe other engineers can appreciate it, but that's all. Who wants something significantly harder to make that you can't even market to normal, well-adjusted humans?

My hunch is users notice this. Most software today just feels bloated and trashy, even if the experience is drug-like. The UX dark patterns wear off. For me, using older software that wasn't designed to be updated just feels good. Maybe serene even. I don't know if it's just nostalgia, but that's my home cooked meal.