I hate almost all software (2011)

The older I get, the more I agree with this rant. I used to be that guy putting cute unicode checkboxes in his test runner, telling myself I was making the world a better place because my software was nifty and clever. Now, I realize that, while that's nice to see, my time was better spent just solving the problem and then moving on to the next problem. Nobody was dying for animated tick marks and I probably ruined someone's experience because their terminal emulator or multiplexer had shitty unicode and escape code support.

It's a delicate balancing act, of course. The tinkerers are often the ones pushing tech forward with their incessant fiddling. But it comes at such an incredibly high cost. I mean, how many human lifetimes have been consumed by the shitty intricacies of dynamic linking alone. And for what? To solve a class of problems we haven't really had since 1992?

What a waste.

There's ample space in the software world for all kinds -- and arguably the industry is fueled by the blood of well-intentioned innocents -- but my increasingly jaded self just wants the shit to work so that I can close my laptop and get outside with my kids. The guy who spent 15 hours a day obsessing over The Right Way and code purity and ecosystems has aged into a man who firmly believes that less is much more, cuteness is a code smell, and solutions should be as self-contained as humanly possible.

I share this sentiment. As a user, I have found some relief by switching to a very simple setup with just a WM (XMonad), a browser (Firefox+vimperator), Emacs and a terminal (urxvt, which I only use occasionally).

Previously, even though I used Emacs as an editor, the idea of moving functions that correspond to applications (like mail reading) into an editor looked clunky and even dirty to me.

But I grew disillusioned of the Unix ethos. While it works well for composing very simple programs, it fails to deliver on most other things. For example, Mutt is a great mail user agent. But it is very difficult to customize beyond its author's original intentions using its own little configuration DSL. And scripting it from your shell does not lead anywhere. This happens with many other nice Unix utilities.

In contrast Emacs, understood as a text-mode Lisp machine, is at odds with this approach. The code you write is as first class as the code you run from whatever module you import. Everything is alive, integrated, and can be changed.

As a programmer, I am moving towards more and more abstract application domains for the same reason. Mathematica, PyMC or Scheme allow me to ignore all the horrid details the OP describes and work at a higher level.

I don't think this is a software problem. It's a general legacy systems problem. Think of self-driving cars. It seems plausible that one day all cars on the street will be self-driving, at which point the existing system -- which was designed for humans -- is a legacy system that is not efficient for the current users. If you were to design an autonomous transportation system from the ground-up I doubt, for example, you'll put in stop signs that cars have to read via machine vision. You'd probably have that information somewhere on the internet (or better yet, design something from the ground up that doesn't require stopping).

You can see how this translates to computing. The reason why I still have to deal with a `document` object while building apps in JavaScript is because we built an application distribution platform on top of a document viewer. There is no centralized planning here -- we're just riding a wave of distributed innovation and making the best out of it. (Nor should you expect centralized planning in technology to emerge unless a superintelligent AI system takes over).

Much of what he's complaining about is a failure to obey a rule that appeared in the original Macintosh User Interface Guidelines.

"You should never have to tell the computer something it already knows."

For example, users should never have to type in a pathname. The user should, at worst, be offered a list of workable alternatives from which they can select. Expecting the user to manually typing in a value for "$LD_LIBRARY_PATH" fails this test.

The original Macintosh software had applications which were one file, with a resource fork containing various resources. This kept all the parts together. UNIX/Linux and Windows never got this organized. Hence "installers", and all the headaches and security problems associated with them. The Windows platform now has "UWP apps" with a standard structure, but they're mostly tied to Microsoft's "app store" to give Microsoft control over them.

Sounds like someone had a bad day.

Software developers are in a strange position in that they create the world they live in, so any warts seem magnified and self inflicted. But any significantly advanced discipline is going to be complex. Physics, chemistry, and biology does not have the same luxury of being "rewritable." They operate in the natural world, so you curse God and not Man.

Rewriting a software system from the ground up is nearly impossible. Also any sort of system will need to maintain some level of backwards compatibility, which induces complexity. Thinking about an operating system as something that was built according to a grand design is wrong. They evolve over time, written by different people with different styles solving different problems.

A counterpoint to this argument, "It’s harder to read code than to write it."

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

In my workspace sometimes people think I'm off to kill their buzz whenever they bring up the topic of introducing another library into our stack because it solves a specific section of our problem-space.

The real value and fun imho is solving complexity in your head, and then coding down a solution that is simple and uses the least number of moving parts as possible.

And yes, we programmers are also humans and we sometimes like to cherish our creations in non-productive ways, so if you code something simple and well thought out, it will be almost always come out elegant and concise, and you'll be able to pat yourself on the back at the end of the day for building something solid.

I don't believe solving something is all about the user experience because there are humans on the back pulling levers and making that solution happen, so there's that.

I live in a VS .Net bubble and avoid this Linux, C, native etc. stuff like the plague. No environment variables, no scripts, no dependencies except things that have a real and obvious purpose, all native interop isolated to its own small ugly files that I don't touch.

Sometimes I want to use an open source library or something and it's honestly days of fighting with compiler flags and environment variables and versions of compilers. There's always undefined symbols or other mystery failures. Last time I did this, the makefile failed because I was getting a source file from a badly configured web server that caused the downloaded file to get corrupted with some downloaders but not others. So there's learning about idiosyncrasies of the HTTP protocol too. It's a complete clownpants nightmare of wasted time.

I both agree and disagree with this. We're not paid to create new things, we're paid for our suffering - to drag ourselves through the nails and glass shards of previously existing code to accomplish a thing. In that respect, I don't see learning the details of a programming language or a tool as a waste of time - it's an investment to make sure I get less glass stuck in my body next time.

It's crazy to think from this came NPM and from that came left-pad. I can't reason about this, I can't understand the evolution in any other way than Chaos.

Is this the best we can offer as engineers. We launch our beautifully crafted boat into the ocean only to watch with despair as is taken and swamped by the waves and the enormity of the sea?

> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with. The complexity was not contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and SMF and signals and volatile variables and prototypal inheritance and _C99_FEATURES_ and dpkg and autoconf.

The next step is to understand that file descriptors and processes orchestrated with C are a substrate that would make everyone reimplement most of what they want from scratch each time. Part of the list describes system services that we have come to expect from an OS: DBus = interprocess communication; signals = process control; volatile variables and ioctl = hardware control; /usr/lib and dpkg = software packaging and distribution. There are more to be added. at+cron = scheduling. syslog/journald/systemd = monitoring; wall = alerting; cgroup = process and process group control; bash = orchestration from a repl; systemd = orchestration not from a repl; lots of stuff = security; every developer's own file format = configuration; every developer's own plain text protocol = data encoding for IPC. The list goes on from here. Even in the early days of Unix, mature systems like VMS had these capabilities.

The problem is not that these exist. It's that they were all built piecemeal instead of being standard system services accessible from a programming language like processes and file descriptors.

Except for bash. That's the result of an old mistake: the job control language on OS/360. That's when we got the idea of a command language distinct from a programming language, and we've been building it back towards a programming language ever since.

Autoconf, though, is purely penance for the sins of the past.

"The only thing that matters in software is the experience of the user." is going on the wall in the office. And I'm mailing one to Android development team.

So we are against perceived complexity and learning new things now?

To elaborate a bit: At work I use OLAP functions to simplify the business layer and focus on the data, moving much of the complexity to sql statements. Others get the data in it's list form and complicate the data layer or the business layer by transforming the inconveniently-structured data there. Yet I am the one who is told to tone it down and think simple.

Much like the author of this article, no matter how senior he is, they seem to divine a vague notion of "simple" when they face perceived complexity. And they always seem to associate this complexity with a real life example of something which could have been simplified (like how angry Linus Trovalds got when he tried to set up a printer on linux) which is unfortunately a red herring.

So is NaN equivalent to null? Does that question even make sense? Perhaps the real question is, how do I represent an optional entity without incurring additional runtime costs? C++, one of the most lamented languages for it's terrible template complexity, has no null problems. Most values are copyable, moveable or re-constructable and most code throws when faced with fatal situations where e.g. the OS runs out of allocatable memory to the point where returning null simply vanquishes and you won't see it in production code anymore. Did that solve your complex null problem? Absolutely yes. Did that come with a bunch of baggage you have to learn and implement? Yes it kinda did.

So the complexity is there for a reason. Go is shameless when it comes to nil. Yet Go is mostly called out for it's lack of generics. Ah, how ironic.

Anyway, if it is there in programming, it is probably for a reason and alternatives introduce their own baggage. Usage of POKE or sprite DATA segments did not suddenly dawn on me when I first started to learn me some programming. I did not say it was unnecessarily complex, or question why it didn't work like legos. I just opened the book and reduced the complexity by learning.

I was with it until the last paragraph. One reason for the mess is nobody thinks of downstream developers as users.

Twenty-six years of developing software for different organizations yet I still struggle with the desire for simplicity in the face of conflicting needs.

The tendency is to think of a "user" as a lone person in front of a screen using a UI of some kind. This idea of user is incomplete. In addition to people using a UI, for say a university financial aid system, a management chain exists with the need for applications to be modified as quickly as possible with new requirements and with no interruption of service. They need applications to communicate with one another. To meet those needs, developers utilize libraries, frameworks, etc. for modularity and reusability. To insure that nothing gets broken while modifications are made, regression testing must occur. Adding test suites increases the likelihood of uninterrupted service. To help with module interdependencies, developers use package managers. And so the stack of software grows.

I'd call it accidental complexity, but it's not an accident. We are dealing with complex software stacks, often with interdependent modules, because we are trying to meet many different needs simultaneously. I don't see an easy way out of the situation.

Over the years, I've become better at determining when to abstract problem solutions in order to provide for future needs and when to do the minimum possible to get the problem solved. I don't think there is a rule or formula for making that determination. You just have to make mistakes and learn from them.

You know what software I like? Video games. It's a model we should all be striving for. There isn't another category where the experience of the user matters more than anything else.

I think dev-ops are often overly complex ... Although most people want too simple programs/computers, if they would just invest some time in them, they would become more productive.

This is a bit of a rant so either ignore it or consume the frustration and empathise.

Good enough is a turd in disguise, your desire to deliver enough working software to justify your existence and salary is egotistic and myopic.

Build sustainable software, that will work, for you, your predecessors and successors.

The constraints of the domain are fine and dandy, that's what matters, that's the problem deadlines, delivery and all of that is superficial. Keeping the business afloat for now is a band-aid on cancer if you can't write software in a a way that you in 10 months, 1 year, 3 years will be able to maintain.

Here's the reality, you screwed up, you buckled and allowed the pressures of institutionalised shittyness to constrain you capacity to deliver real value.

Please, everyone lets stop acting like software is some ephemeral joke that we can half-ass, and start being serous about the implications of our actions.

> The only thing that matters in software is the experience of the user.

While ultimately true, it's a bit too simplistic, because it presents user-experience as a constant. Done deal. Delivered or not. In reality the user experience is something which will change over time, as the software is updated and evolves to accommodate the additional needs of the users.

If you can't keep your code clean over time, your code will start suck, needless complexity might sneak in, and so will the user-experience start to suffer as well.

A good user-experience, just like the code, needs to be maintained. And thus comes the need to organize the code. And for a developer to bother maintaining the code, and for him to be efficient at it, he should work with tools and within an environment which fits his needs (and accommodates his requirements for a good user-experience). And thus comes fiddling with editor-settings. Etc etc.

Basically this rant highlights a real problem: Software complexity is out of control. But the conclusion does not support the arguments given. Rather his conclusion drives all the things he rants about being wrong in the first place.

I think, in the end, to get clean code, to get rid of needless complexity, there's one simple thing which trumps everything else: You need someone empowered to make the required changes. And you need that person to care.

Without that, it's all just us waiting it out, until it starts heading into the abyss. We can already see that with lots of the bigger open-source projects which once fuelled the (small) Linux desktop revolution a decade ago.

So how do we cope?

> There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one. When that happens all of this shit will be trashed. We can flush boost and glib and autoconf down the toilet and never think of them again.

Maybe we will. But I don't believe for one second that we're going to break the cycle this time around, because finding and keeping someone caring enough for decades to come is a pretty tall order.

Best blog article I've read on HN in a very long time.

That dbus was turned from the Desktop BUS to the de-facto system bus is me an eternal puzzle.

Developers are users too.

In my opinion, he hates the fact that documentation of stacking things up is very poor. Which is true.

Most technology is useless. Its not a product of necessity, but a product of our chosen economic system.

Yes, you hate technology because is hard to build it.

The author has not articulated beyond - you don't understand how fucked the whole thing is. Terrible writing.

I see the reason for the complains, but I do not agree with the basic premise. It should not be "I hate almost all software", it should be "I hate my employer and the job I am stuck in".

I mean, this person is writing for Solaris/Illumos (judging by SMF references and autoconf complains). Yeah, running modern stuff on solaris sux, unless you have a sysadminny mindset. This is clearly not for him. Fine -- different people like to optimize different things: user experience, internal code beauty, maintainability, code robustness, number of platforms supported.

No one should be forced to work on stuff they don't like. There are lots of jobs, and most of them do not require SMF, DBus, /usr organization, or volatile variables.

Maybe you should stop thinking of code as solving problems and more like painting a picture. It doesn't matter if there are mistakes or if you've done everything perfectly, as long as you've created something cool.

It's like telling a room full of artists that you hate almost all art because the tools available etc etc over complicate painting a simple picture whose purpose is to fulfill a client contract, etc.