A Rant from the Old Forge: On the State of Software Development

“Not every innovation is progress. Not every dependency is help. Not every platform string is a limitation.”

There was a time, not so long ago, when building software meant just that - building software. Not downloading half the internet. Not praying for some server halfway across the world to be up so your build script doesn’t die. Not wondering which of the 73 versions of leftpad got pulled into your tree. No, software development used to be straightforward.

As someone who has coded in Assembly, ANSI C, C++, Java, Erlang, Forth, Fortran, C#, QBasic, Visual Basic, JavaScript, Python and having touched Rust - I remember when one had distinct, minimal toolchains. Visual Basic or Visual C++ for Windows in the old ages, gcc (or later clang) and make for Linux and the BSDs and later on of course also on Windows. Except on Windows everything built from source, and if it didn’t, you wrote the tool that did.

• The Age of Simplicity
• Then Came the Flood
• The Rise of Binary Artifacts
• What We’ve Lost
• Where We Need to Go
• Final Thoughts

The Age of Simplicity

Makefiles. They just worked. Clone a repo from SourceForge via cvs or svn, type make, and within minutes your software was built - on Linux, on FreeBSD, on Solaris, sometimes even on Windows. Sure, you had to write a few ifdefs but the underlying principle was: source goes in, binary comes out. If you needed helper tools, they were built as part of the process - also from source.

Java had it even better: javac worked everywhere. Java’s portability was real. One jar to rule them all. Even Maven, when used sparingly, brought order - not dependency hell.

And yes, DLL hell on Windows existed. But it got solved. Mostly. Over time.

Then Came the Flood

Then the hellfire came.

Package managers. First came pip, then npm, then yarn, then cargo, then gradle (with artifactories), then the N-th flavor of “build orchestrator with plugins that download more plugins to build plugins that fetch binaries from the cloud”.

Want to build a simple application? Now you need to install 32 packages, 5 virtual environments, and 3 different versions of a JavaScript bundler - each one fetching their own version of the world.

Even worse, exact-version dependency pinning became the norm. You’re not declaring compatibility anymore. You’re saying, “This version and only this version will work, everything else will break.” So now every project drags with it its own sealed time capsule of the entire dependency tree. It’s like every applications developers believe it’s the only application running on the system - forever.

The Rise of Binary Artifacts

It wasn’t enough to fetch gigabytes of source. We started pulling binaries. Precompiled toolchains. Obscure shared libraries. Platform-specific artifacts. And surprise - if you’re not on Ubuntu LTS, good luck.

Trying to build an Android app on FreeBSD? Forget it. Not because it’s impossible - but because Gradle insists on downloading precompiled tools, and none are built for your platform. Even though you already have built the whole toolchain on your platform as native executables, gradle ignores them. The same applies to a huge number of Node, .NET, and even Rust projects - despite the fact that the code could run just fine if built locally.

And don’t get me started on string-matching OS names in build scripts. “Darwin”, “Linux”, “Windows” - as if this crude taxonomy is the reason your code compiles or not. We’re back to “This web page works in Internet Explorer 6” levels of idiocy.

What We’ve Lost

Today, people marvel at how quickly they can get a prototype running - and don’t get started with vibe coding “results”. But they don’t see the rot under the surface.

• Security: Dependency chains are untraceable and unauditable. Binary artifacts could be anything - yes we have some kind of code signature but that’s not protecting you from corruption the way it’s used.
• Maintenance: You can’t update a library without breaking half the world to fix bugs for all installed components at once.
• Portability: Software runs on a handful of well-supported OS/distribution combinations and fails everywhere else. Remember people discussing which exact version of their Linux userland they are using and what is compatible and what not?
• Reproducibility: Even version-pinned builds can fail when servers go down or packages vanish - especially in case dependencies have evolved over time and their old versions vanished. Breaking a huge number of dependent packages. It requires exponentially growing work-hours to keep this up and running.

Where We Need to Go

If we want a sane future for software development, we need to steer the ship back to stability. Here are some commandments to consider:

• Thou shalt minimize dependencies. If you can write it in 30 lines, do it. Don’t pull 3 libraries to check if something equals to true or false (hey, have you noticed there is even an AI enhanced is-true on npm?)
• Thou shalt not rely on binary artifacts in builds. Build everything from source, or make it optional. Never rely on binary artifacts. Not for the toolchain, not for parts of the application. Never.
• Thou shalt not require 14 package managers for one project. Keep it simple. Even when using different languages.
• Thou shalt not pin exact versions. Use minimum version constraints and test forward. When developing libraries do not break old code using old APIs and ABIs. Be downwards compatible (keep in mind this is one thing that helped Microsofts Windows growing for a long time).
• Thou shalt aim for portability. Write POSIX-compatible code where possible. Avoid unnecessary platform checks. If it builds on Linux it should build on all BSDs and on Solaris without any hassle. If it does not you are doing it wrong.
• Thou shalt not treat unsupported platforms as second-class citizens. If it builds on FreeBSD, Solaris, Linux, Darwin - don’t artificially block it.
• Thou shalt remember that software should be flexible, not fragile.

Final Thoughts

We are building brittle sandcastles of software on shaky shores of dependency hell and version madness. The illusion of rapid development hides a future of painful maintenance, platform fragility, and security nightmares.

Let’s not forget the lessons of the past. Good software isn’t just fast to write - it’s also stable, portable, maintainable, compileable and useable in 5, 10, 20, 30 years. We should aim for that.

Not just for ourselves, but for the poor souls who will come after us - be it in the same company having to keep software alive or having to work with our software years after we even stopped programming.

This article is tagged: