Skip to content

Instantly share code, notes, and snippets.

@cookrn
Created November 5, 2012 05:04
Show Gist options
  • Save cookrn/4015437 to your computer and use it in GitHub Desktop.
Save cookrn/4015437 to your computer and use it in GitHub Desktop.
Ryan Dahl on Software

I hate almost all software. It's unnecessary and complicated at almost every layer. At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems. The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved.

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.

Those of us who build on top of these systems are adding to the complexity. Not only do you have to understand $LD_LIBRARY_PATH to make your system work but now you have to understand $NODE_PATH too - there's my little addition to the complexity you must now know! The users - the one who just want to see a webpage - don't care. They don't care how we organize /usr, they don't care about zombie processes, they don't care about bash tab completion, they don't care if zlib is dynamically linked or statically linked to Node. 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.

Those of you who still find it enjoyable to learn the details of, say, a programming language - being able to happily recite off if NaN equals or does not equal null - you just don't yet understand how utterly fucked the whole thing is. If you think it would be cute to align all of the equals signs in your code, if you spend time configuring your window manager or editor, if put unicode check marks in your test runner, if you add unnecessary hierarchies in your code directories, if you are doing anything beyond just solving the problem - you don't understand how fucked the whole thing is. No one gives a fuck about the glib object model.

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

@mattgreen
Copy link

It is a bitter rant. But I've seen similar rants elsewhere, from smart devs. Hard to pin down whether it's 'just' burnout or other issues, such as cultural influences. Software tends towards entropy, and, IMO, industry pulls it there faster due to it's insatiable demands for 'productivity.' But Dahl is right when he advocates for only the absolute minimum of complexity. I don't really want to understand your library, I want to plug it in, try it out, and move on.

Idealism is a double-edged sword: you can see how reality and how things should be. At the same time, you can try to reconcile the two, only to realize that it's a lot of work, there may be technical restrictions, and (worst of all), people may not be ready for it.

@padolsey
Copy link

To the rant: If this game of software development was all about the user and nothing else then I wager a vast bulk of us would drift off, because for me at least it is the joy of puzzle solving and abstracting complexity that makes it all worth it. And yes, those abstractions may be leaky and those puzzles half-solved but it's still a fun process, or at least more fun than bending to the will of the deified user.

@millermedeiros
Copy link

UX is very important, specially when you are getting paid to write code to solve real user needs; but most people don't become great devs by thinking only about the "client" needs, they get great by exploring new ways of doing the same thing, and by studying their fields deeply.

As @padolsey said, puzzle solving and abstractions is what motivates people; and these people are the ones who makes big leaps that change the course of the craft in ways that wouldn't be possible otherwise. Sometimes the process is more important than the short term result.

"Immeasurable harm is done by the assumption that only measurable outcomes matter." - https://twitter.com/DrJohnLTaylor/status/391560387755130881

We shouldn't focus too much just in one side of the spectrum; there must be a balance between UX, tech, complexity and fun.

@davidpfahler
Copy link

@padolsey @millermedeiros You miss the point of the rant. In the author's opinion, software is here to solve problems for humans. That's it. Not to enjoy writing it, not to enjoy abstraction, nothing like this. You can disagree with that, of course, but it's not like the author missed that or didn't think about that aspect. He is 100% rejecting it.

@devn
Copy link

devn commented Oct 31, 2013

  = You
  = Make
  = Some
  = Interesting
  = Points

@m5rk
Copy link

m5rk commented Dec 2, 2013

Software is not the only field where this occurs. It's a human malady. In general, we tend to optimize the wrong things.

@teknomath
Copy link

I just had a conversation with similar overtones with an investor of a startup I work for. There are two phenomenon that conflate to cause the type of frustration that Ryan appears to have experienced. The first is that people start writing clean code because it solves a problem internal to the act of software development -- that is, of the code becoming so messy no one can anticipate the side-effects of their edits anymore -- but inevitably this ends up becoming a goal in unto itself. The second phenomenon is that the writing of sloppy code, the use of deep abstraction, the build-up of technical debt...these things inevitably happen because the software industry as a whole benefits from it -- it keeps people employed. That said, it is very, very important to keep in mind that no one does this intentionally...it is a byproduct of the commoditization of software, and commoditization is an inevitable pattern in a free-market economy.

I used the word "inevitable" multiple times, for a reason: these phenomenon that I am calling out are capable of causing such deep frustration (and, ultimately, depression) because their causes lie far outside the power of one person to influence and they are virtually certain to happen. I have felt some of what Ryan seems to have felt, and I took a 10-year hiatus from development to repair myself. Now I'm back, and my assessment is that the center of gravity in the software world is HTML+CSS+Javascript+JSON -- and the center of that is node.js. That node.js's author has experienced the existential frustration of fighting against the inevitable degenerative patterns of our industry means that node.js has passed its infancy. And that gives me hope that I'm betting on the right horse.

Copy link

ghost commented Apr 25, 2014

Thank you for providing this text (from a google+ post). I remember... he basically said this (also) in a video (must be somewhere online). If anybody finds it please leave it in the comments!

@teknomath: Nice comment, the worst thing is that YOU can almost do nothing about it and that's it and it will happen the same way on every IT project. Probably awareness (of the problem, which leads to depression :) may help. I live in Germany and not the US or the valley and I think things are worse here. We almost don't have cool IT (the startups I see here are not really cool, I am so sorry), so we have just enterprise IT and the problems are very strong within enterprises (see "the expert in a marketing meeting"). I have studied computer science and I can't just switch (to e.g. being a doctor) since this would take much time (6 to 8 years ;). So I am stuck. People tell me how bad people's live is in whatever country, but you know what... it's not that we flush down all this software soon. It's also my live which is ... it actually is... it just is... in the trash can. There are other factors: My specialization requires me to move somewhere where they use my "product" (IBM Message Broker) and the government tells woman "to live their own live" and so my wife just won't move with me to the new location ... and there are all terms for it... it's called "contracting" and "a project" ("you won't stay long there") and "consulting" and I call it: "a live in the trash can". And ofc "love it, change it or leave it"... ofc, BUT... it is the same everywhere. It's human nature. It repeats everywhere. And people with a different job will just say "oh I do this and that and you do software". Yeah challenges (I didn't know they are intrinsically unsolvable). I thought it's about a (subject) matter and not human psychology and ultimately... human failure

And we are all happy, right? I am not allowed to be unhappy (to raise critique). Everything is so great. Everyone loves everybody and we live in the greatest times ever. And in any doubt, we must "sharpen" our understanding of our roles (the roles we have on the project)

And psychologists, they can't help you. They just make money out of your misery ("hey I am a psychologists it's my job and you know... I mean you decided to do software"). What is the first/second highest cause of death among people aged 20 to 40. It's suicide. And each and every one of them means that our society has failed. I am alive because I see other's die ("ah, they must have had problems too").

Thank you if you don't delete my post but leave it for other's to read

@bburrough
Copy link

I'll just leave this right here... Joel Spolsky in 2000, "Things You Should Never Do, Part 1."

http://www.joelonsoftware.com/articles/fog0000000069.html

Ryan's sentiment doesn't reflect reality. Joel's understanding is a much better representation of the real nature of software development.

You cannot both make a programmer's life simple and easy, and make the user's life simple and easy. Those two things are inversely proportional to each other. If you want to solve more problems for an end-user, the programmer has to do more work. If these two things were not inversely proportional, a programmer could make the user's life easier by simply not doing any work!

Look, fundamentally, computers are hard. They're weird, esoteric machines that aren't like anything humans are naturally familiar with. Just think about the fact that a computer executes millions upon millions of instructions every second. Now imagine the number of instructions you execute to bake a cake. Those are many orders of magnitude different from each other. There are weird natures between the human scale and the computer scale that are dealt with through all of the things that Ryan is complaining about. If you eliminate those, what are you going to do, write your own libs? Write your own compiler? Write your own assembler code? Good luck getting a simple hello world application written, let alone a web server, a browser, or an operating system.

The idea that Unix is a house of cards that, at some point will be more easily replaced than understood is foolishly wrong.

Computers are hard. Programming is hard. You're not doing yourself any favors by sitting there bitching about it. You need to knuckle down, dive in, and start dealing with that complexity on your user's behalf. Isn't that what they're paying you for? The more you founder and delay, the longer it's going to take to achieve some real, valuable outcome for an end user.

@stevemao
Copy link

@hansman
Copy link

hansman commented Aug 20, 2017

"This is a common pattern that has been repeated in many well-established sciences: not just medicine, but physics, mathematics, chemistry, and others. The fields start out monolithic, with just a few deep ideas. Early experts can master all those ideas. But as time passes that monolithic character changes. We discover many deep new ideas, too many for any one person to really master. As a result, the social structure of the field re-organizes and divides around those ideas. Instead of a monolith, we have fields within fields within fields, a complex, recursive, self-referential social structure, whose organization mirrors the connections between our deepest insights. And so the structure of our knowledge shapes the social organization of science. But that social shape in turn constrains and helps determine what we can discover. This is the scientific analogue of Conway's law."

@hansman
Copy link

hansman commented Aug 20, 2017

@ORESoftware
Copy link

Bottom line is - someday I hope someone writes a better OS than Unix. I pray to God everyday that my Ubuntu Desktop machines boots up, because it's not a given lol. I think ultimately open source software mostly sucks, but that's another thing altogether.

@amiteshore
Copy link

If builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization.

@workingjubilee
Copy link

While it is pleasant to imagine our world is made of sterner stuff than software, I've stepped through enough buildings with lead-laden plumbing and asbestos-lined walls, yes, even in the 21st Century, and no, they weren't condemned, that I do not believe the two disciplines are all that far off. They merely both have the ability to construct a pleasant-seeming facade.

@alevosia
Copy link

alevosia commented May 5, 2020

What about developer experience?

@terraboops
Copy link

the computer revolution hasn't happened yet.

@lastmaj
Copy link

lastmaj commented May 27, 2021

I think this is painfully true (and hard to swallow)

@KulaGGin
Copy link

KulaGGin commented Jun 6, 2021

Uncle Bob disagrees:
https://youtu.be/SVRiktFlWxI?t=1807
https://youtu.be/qnq9syXUuFE?t=3400

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

That's not the only thing that matters. There are many other things that matter: how long does it take you to deliver this software, how clean the code is, just 2 examples.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment