The RRP Manifesto

Too many good people are being held back by bad software. Very likely, you are one of them.

You care passionately about your work, and took it up because you wanted to make a difference.

But every day, in a thousand little ways, the technology you have to use to get that work done sabotages you. You’re spending time fighting with programs to make them work the way they’re supposed to, tearing apart your shiny new web site to figure out why it doesn’t look right on your boss’ iPad, wondering why you can’t get the tech people to understand your problems. By the time you’re done with it all, the day is over, so you get to come in tomorrow and do it all over again. And even if you’re diligent and careful and always on top of all these little things, inevitably something slips through the cracks, something that comes back to bite you.

But that’s not the worst part. The worst part is that, when you ask the tech people why things have to be this way, the tech people tell you that it’s all your fault.

“You should have read the documentation.”

“You should be using a different browser.”

“You should have explained that more clearly.”

All of these responses have one thing in common: they assume that it’s your job to contort yourself to fit your software. That it’s natural for software to be sharp-edged and dangerous, like a loaded gun; and, like a gun, the only way to mitigate the risks it presents is for the person holding it to be extremely careful and responsible. And if you aren’t — if, despite your best efforts, you ever slip up… well, you end up with a bullet in your foot, or somewhere even worse, while a bunch of people stand over you clucking about how you deserved it.

This is the way technical people have presented software to users for as long as there has been software. And it’s wrong.

Software exists for one purpose only: to aid the person using it. It is, at root, a tool to amplify human potential — what Steve Jobs called “a bicycle for the mind.” That’s what makes it so exciting.

Yet, for the vast majority of people, the actual experience of using software feels anything but empowering. It’s an endless cycle of tiresome warnings, restrictions and limitations; of worrying before every keystroke and every click whether that simple action will cause something, somewhere, to blow up. It’s never knowing whether your tools — tools you paid good money for — will simply refuse to do what you bought them to do, or lecture you for wanting to do it, or force you to do it in some different, less-than-ideal way just because that way was easier for the people who wrote the code.

And that’s what all of this boils down to. Software doesn’t exist in a vacuum; no computer program was ever the product of immaculate conception. Software is an expression of the values of the people who created it. And too often, those values place the ease and convenience of the programmers of the software above the ease and convenience of its user.

That’s what’s wrong.

People shouldn’t have to contort themselves to fit their software. Software developers should design their software to fit people.

We believe the ease and convenience of the user of software should always, always, always come first.

This is not an abstract principle. It informs every aspect of how we do our work.

• It is our responsibility to do the legwork to understand the goals, desires and problems of our clients, not our clients’ responsibility to learn a bunch of tech jargon in order to explain them to us.
• It is our responsibility to design software whose function is effortlessly understandable to the user, not our clients’ responsibility to wade through manuals, Web sites and trainings to learn to see the world the way we do.
• It is our responsibility to think proactively, see problems that could arise down the road, and address them before they happen, not our clients’ responsibility to have to micro-manage the development of their software.
• It is our responsibility to create things that empower our clients, not our clients’ responsibility to get used to not being empowered.

If we fail at any of these tasks, we have failed at all of them. If we do not listen to our clients and adapt ourselves to their needs, we have failed. If we make software whose design is obtuse or unintuitive, we have failed. If we content ourselves to only do what’s needed right this moment and stop thinking ahead, we have failed. If engaging with us makes our clients feel condescended to, dismissed or ignored, we have failed.

It is our responsibility to live up to these principles. It is our responsibility not to fail.

We take up this responsibility with a light heart and good cheer, because to us it doesn’t feel like responsibility at all. It feels like being of service to human beings. And being of service to human beings is what good software — and good software developers — are, or should be, all about.

April 2, 2015
Alexandria, VA