This post was originally published on November 21 2017. It was last updated on September 7 2020 (7:45 pm).
Reading time: 2 minutes
Introduction
Modern software is often quirky and hard to use. Users and usability professionals have high expectations, and often product developers blame the technology for a poor experience.
P2P
In the software development industry, we often put the onus on the technology, using a Software-to-Customer model.
But, if, as a developer, you think of the Customer as a person, the Developer as a person, and the Software or delivery mechanism as something that a developer created, then you can drop the middleman and reframe this as a human trade, Person-to-Person, or P2P.
Shifting the blame
This is an important differentiation. When we refer to digital products and services in the third person, we can shift any blame from ourselves, projecting our very human issues onto their cold binary exteriors.
| Developer quirk | Software quirk |
| I’m under pressure, tired and irrational | It’s buggy |
| I’m saving time by cutting corners | It’s limited |
| I’m using frameworks to build things quickly | It’s slow and bloated |
| I’m working long hours but am well paid | It’s too expensive |
If we could see past our blinding egos for a second, we might see that we created this beast. We, or people like us, created the finished product and the frameworks it relies on and the coding languages themselves. We created their capabilities and their limitations and quirks.
Taking ownership
Moving the focus from the software, back to the people who created it can be very empowering. Because if we broke it, then logically we can also fix it.
It can also be quite embarrassing. Many’s the client who has scolded their developer: Stupid developer! Why is it broken?? The inference is that the software is inferior because you are. But the developer is only a cog in a machine and is affected by many other (human) factors too.
Nevertheless, in our P2P relationships, if the person at the other end can’t work with the software that we’ve provided, then we should not be afraid to look them in the eye and say, yes, we broke that and yes we can fix it.
Or maybe, we don’t want to change. If not, it’s still on us.
Breaking the cycle of suffering
Which leads us to human suffering. That old chestnut.
Too often, the person at the other end of the software takes on the role of martyr, blaming themselves for usability issues.
| Developer quirk | Software quirk | User quirk |
| I’m under pressure, tired and irrational | It’s buggy | I’m exhausted, I’m not smart enough to figure this out |
| I’m saving time by cutting corners | It’s limited | I’ll use something else |
| I’m using frameworks to build things quickly | It’s slow and bloated | I’ll buy a new phone |
| I’m working long hours but am well paid | It’s too expensive | I’ll work more hours to afford it |
There’s a running theme here. The person suffering at one end is very similar to the person suffering at the other end. And when you factor in that the developers of software are often also the users of it, it all becomes very self-fulfilling.
I think this says a lot about our situation right now, and about our potential. Maybe we feel obliged to maintain the status quo and to keep running on this mad hamster wheel. But ignoring the forces at work won’t bring us happiness, unlike the hamster.
Things could be immensely better than they are right now. We just need to take ownership.