Why make software better?
Reintroducing Process to Processes
Hello! It’s been a while. I’m Ben Christel, and you’re reading Ben’s Guide to Software Development.
I haven’t worked on my book, Process to Processes, for a couple months. I lost steam because it just felt pointless. I kept asking myself “who is going to pay (in time or dollars) for this? To hear people in the industry talk, most software companies don’t seem to care about making better1 software, so where’s the market?” I’d convinced myself that if value didn’t flow through, end-to-end, from software buyers to sellers to programmers to me, there would be no audience for the book.
And the next thought after that was, “do I really want to help random software companies make more money, given how exploitative most of them are?” The answer is no, I don’t.
I recently realized that this framing is self-defeating and silly. Moreover, it just buys into the capitalist myth that says that money is the be-all and end-all of what we do and how we do it. That’s just not true.
The problem I’m trying to address is not that software companies aren’t making enough money. The problem is…
Software development is stressful!
It’s stressful for everyone involved, in all kinds of ways:
Managers: The project is late, and QA found 150 bugs in the last build!
Programmers: The code makes no sense! Tests are failing and you can’t tell why. Your progress is delayed by handoffs, dependencies, clunky tools, and endless meetings.
Users: The new UI is impossible to navigate! And it’s ugly!
Stress comes from unpleasant surprises. These surprises happen whenever our mental models of the system don’t match reality. The problem is, when mental models and reality fight, reality always wins.
People often react to this by trying harder to control reality. This is the origin of Gantt charts, elaborate design documents, and fear-driven defensive programming. But these techniques just create frustration and busywork — and surprises often continue to happen anyway.
Fortunately, there is a better way. By building more accurate mental models, we can reduce the frequency of surprises, and equip ourselves to deal with the remaining ones in less-stressful ways.2 The techniques in Process to Processes focus on modeling systems and keeping them easy to model as they grow.
Maybe you’re not in the market for stress-reducing techniques. Maybe you’re one of the lucky few. “My job isn’t that bad. I clock in at 9 and clock out at 5. I get my work done. My boss likes me.” That’s great! But you might still be missing out, because…
Software development can be joyful
For me, joy in software development comes from a few different sources:
seeing my own thoughts reflected back to me
being the conduit for a smooth flow of information, from intention to action to result to feedback
mastering a new skill
giving others the same opportunities for joy.
I’ll never forget the thrill of writing my first program (well, “writing” — my dad helped a lot). All the program did was display a button that printed “It Worked” when you clicked it. But seeing that message appear caused me to literally jump for joy.
There is something incredibly reassuring about explaining your thoughts to a chunk of silicon, and having the chunk of silicon repeat them back to you as objects that change color and move and dance. It makes you feel smart, like you are not deluded, like your thoughts make sense. They must make sense, because you just taught a system made out of math how to think them.
Learning to program is hard. Learning to program professionally is even harder. But once you’ve practiced the relevant skills long enough, software development becomes a virtuosic improvisational performance. It’s almost effortless. Most of the time, you can just go with the flow, responding gracefully to whatever happens.
That sounds nice, but how can we get there? There’s no secret, really: just keep using the techniques for low-stress software development and gradually improving on them day by day. It’s like we’re climbing a mountain: there’s no magic trick that will get us to the top. You climb by taking a step, and then taking another step, over and over.
It works better this way
Some party poopers might find all this talk of joy a bit heretical. They don’t pay us to have fun! But joy in programming is not about goofing off, nor is it some extra, tacked-on activity that costs net time or money. Joyful programming is simply effective programming. We do it because it works. It is more efficient than the alternative.
The kind of people who become programmers and developers have ‘fun’ when the effort they have to put out to do a task challenges them, but is just within their capabilities. ‘Fun’ is therefore a sign of peak efficiency. Painful development environments waste labor and creativity; they extract huge hidden costs in time, money, and opportunity.
If Unix were a failure in every other way, the Unix engineering culture would be worth studying for the ways it keeps the fun in development — because that fun is a sign that it makes developers efficient, effective, and productive.
—Eric S. Raymond, The Art of Unix Programming
That said, getting to a place where joyful efficiency can happen does take some upfront investment — e.g. giving teams space to learn and practice. I’ll talk about strategies for managing that in the book. For now, let me refer you to my thoughts on getting out of the “alignment trap.”
In the next post, I’ll give a high-level overview of the qualities of code that enable low-stress, joyful software development. Stay tuned.
I’ll talk about exactly how I define “better” in the next post.
For example, although my code sometimes has bugs, it’s rare that someone finds one that I can’t diagnose on the spot. The fix usually follows shortly afterwards.