The cover image for this post is by Jon Tyson
This blog post was written by Jamie.
Imagine the situation: you’re using some mission critical software, and it breaks at the worst possible moment. Perhaps you were creating a report for the big meeting with the investors; perhaps you were filing your taxes at 11:59 on the day before they are due; perhaps you are applying for a job, or insurance, or a mortgage.
As the user, how would you feel about the software breaking at the most critical moment?
That’s how your users feel when the software they are using breaks.
The User Matters
More than anything else, the user of your software matters. Without them, there was no need for the software. And without the software, there was no need for the project. Without the project, there was no need for you to work as hard as you did.
Unless you are working entirely in open-source software, your users pay your wages
technically, they can still be paying your wages in OSS too
So why do a large swathe of developers treat users with contempt?
I, personally, don’t think that the theory that developers expect perfect systems with flawless logic to exist outside of their computers holds any water. Partly because that reduces us developers to a two dimensional caricature, but also because it relies on old stereotypes of nerds with black rimmed glasses, pocket protectors, and no social skills
you know the type - almost every hollywood comedy film from the 80s has one
It’s important to note that I said “large swathe of developers” not “all developers everywhere”, as the tide is turning and we’re becoming a more empathetic industry. I can see why some people might think this is related to the “old guard” retiring or moving into management, but I don’t think that’s it either. I think that we’re becoming a more accepting, diverse, inclusive, and empathetic industry. This is great, but we have a long way to go.
I know that there are developers within our industry who have contempt for their users. In fact, there is precedent for it. In his book “Hackers: Heroes of the Computer Revolution” Steven Levy talks about how early software developers at MIT referred to users with “a silent l”. This is backed up by both The Jargon File and Wikipedia:
when a user first walked up to a terminal at MIT and typed control-Z to get the computer’s attention, it printed out some status information, including how many people were already using the computer. A patch to the system was then written to print "14 losers" instead of "14 users", as a joke… For a while several hackers struggled covertly, each changing the message behind the back of the others; any time you logged into the computer it was even money whether it would say "users" or "losers"
I’ve actually worked alongside developers who have referred to users with a silent l, those same developers have also called users “stupid” and “morons”. So I know that it’s still an issue present in our industry 53 years after those early developers began referring to users with a silent l.
In every case where a developer I have worked with has referred to user with a silent (or not silent, in most cases) l, the users where not to blame.
Perhaps it was the influx of bug reports from users which upset these particular developers.
Bug Reports Are A Fact Of Life
It’s a given that there is no such thing as bug-free software. If that’s so, then we do some developers get defensive when they receive bug reports? It’s my opinion that a lot of developers see a bug report as an affront to their ability to turn the specification into working software - after all, they turned the spec into “perfect” software, right?
Whereas I like to think of bug reports as fitting into one of two categories:
- Legitimate issues with the application
- A user misunderstanding what the application or feature does
Both of which are opportunities for everyone to learn.
If we take Hanlon’s Razor and alter the final few words:
never attribute to malice that which is adequately explained by lack of knowledge or a failing of documentation
Then we can see that it’s not always the user’s fault - in fact, it’s almost never the user’s fault. It’s never someone’s fault if they don’t understand you.
Either the documentation surrounding the application or feature is poorly written (otherwise it would have been understood by the user), or we misunderstood when we implemented the feature. Specifications (from multi-page design documents to user stories) are written in human language, which is full of hidden (or non-obvious) nuance and actually lacks crucial details, and it’s our job to convert them into logical, analytical code without any nuance.
In a (at the time of writing) future episode of Tabs and Spaces, I actually make this point when I say:
So here’s a concrete example that I think Zac will attune to:
Zac, explain the nuances of professional wrestling in less than an hour. And I know it can’t be done, because this time two years ago I interviewed a guy who was building a brand new pro wrestling arcade game, and he had to explain to his developer why sometimes when a pro wrestler slaps another across the chest, while he’s in the corner of the ring, the crowd does "woo!", but not all the time.
It is not possible to explain all of the nuance of a business or industry…which is required to be communicated in order to facilitate the digital exploration of your business in an hour or less. It is not possible.
And this was a reference to episode 75 of The Waffling Taylors where I interviewed Michael Hermann about his game: RetroMania Wrestling. He shared a story about having to explain the “logic” behind a number of tropes in professional wrestling, ones which don’t make sense outside of the pro wrestling world. Things like why the crowd will go “woo!” after some manoeuvres, and why an “Irish Whip” makes sense in the context of a pro wrestling match even though it defies the laws of physics and logic.
And this inability to communicate the nuance of an industry is why things like Agile, SAFe, and Scrum exist. We need to be able to react to misunderstandings in the specification with agility.
Whereas unclear documentation provides a chance to communicate with the user and see where their misunderstanding came from. We can then use that knowledge to alter the documentation and make it clearer for everyone. Perhaps some tooltips or context-based documentation, screenshots, or a screen-cast would be better than throwing the application over the wall and leaving the user to figure it out.
If we have misunderstood the requirement, or if we believe that it has been poorly communicated to us, it’s up to us to go back to the source of truth
perhaps the PM, BA, or the client
and ask for clarification.
Rather than digging our heels in, crossing our arms, and saying that we implemented the feature matching specification, we should be open to communication and correcting our assumptions.
Empathy For The User
When I interviewed Dylan Beattie for episode 48 of The .NET Core Podcast, we talked about situations where people’s entire careers are placed in jeopardy because of badly implemented software. One of the examples he gave was the software used by law students to apply for internships at Solicitor firms: there is a very small window of opportunity to apply for these positions - usually around 48 hours - and if the application software breaks, that puts the applicants in a position where they can’t possibly get the internship
"internship" here is quite possibly the wrong word, but you get my meaning
And this means that you could have users who are literally crying at 2am, because your software is broken and it’s putting their career on hold for a whole year.
There’s a line in an episode of the Fox TV show Firefly where a character asks:
You oughta be shot. Or stabbed, lose a leg. To be a surgeon, you know? Know what kind of pain you’re dealing with. They make psychiatrists get psychoanalysed before they can get certified, but they don’t make a surgeon get cut on. That seem right to you?
The line itself is rather dark, but imagine if we developers had to use terribly implemented software to achieve some non-trivial task before we could be “allowed” to build software of our own. Would that make us more likely to empathise with a user in the same situation?
Perhaps it would.
In Closing
What I’m trying to get at is that it’s almost never the user’s fault, and that we developers should make a point of being more understanding and empathetic to what the user is trying to do, how not being able to do it will affect them, and approach their pain as a chance to better understand the systems we are building.
So the next time that you hear of a user having a bad time with your software, try to understand how you and your software are getting in the way of them achieving their goals.