Projecting human quirks on to software

Sunlit windows are projected onto accessibility car parks.

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 quirkSoftware quirk
I’m under pressure, tired and irrationalIt’s buggy
I’m saving time by cutting cornersIt’s limited
I’m using frameworks to build things quicklyIt’s slow and bloated
I’m working long hours but am well paidIt’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 quirkSoftware quirkUser quirk
I’m under pressure, tired and irrationalIt’s buggyI’m exhausted, I’m not smart enough to figure this out
I’m saving time by cutting cornersIt’s limitedI’ll use something else
I’m using frameworks to build things quicklyIt’s slow and bloatedI’ll buy a new phone
I’m working long hours but am well paidIt’s too expensiveI’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.

Leave a Reply

Your email address will not be published. Required fields are marked *