Why some software development tasks feel impossible

Have you ever sat down to fix a “small” bug only to find yourself embattled in a seemingly endless war with some “legacy” code (that you yourself wrote 6 months ago)?

If so, you’re running head first into the hidden force that affects nearly everything we do as software developers.

In a second we’ll explore exactly what that is, and why it matters.

First, three seemingly unrelated quick stories.

See if you can spot the connection.

Video game challenges#

I recently sat down to play the remastered version of Horizon Zero Dawn.

I don’t play video games nearly as much as I used to, so I left the difficulty at normal.

But, a few hours in I realised, gleefully, that I’d underestimated my abilities!

I was actually doing pretty well defeating the hordes of machines the game was throwing my way.

So I upped the difficulty level.

Now the enemies took a bit more damage before they were defeated.

There were more enemies to contend with per encounter.

Enemy AI improved (the machines were far better at hunting me down, and attacked more quickly when they did).

In all cases, the game became a little bit harder.

Frustrating processes#

A few years ago I worked for a small company who got bought out by a much bigger company.

In the small company I was responsible for the IT and Software Development team.

We had the trust and leeway to make changes to our production environment as needed.

Very soon after the takeover was completed, that all changed.

Every change now had to be reviewed and approved by the IT Director before it could be pushed out to prod.

Deploying anything become a nightmarish process of completing the world’s worst Sharepoint form, then waiting until the Director found time to review and sign off (or reject) the change request.

We nearly deleted everything#

Last week a friend of mine was working late on a SaaS app we’d built together.

He was working in the early hours, trying to complete a feature which would ensure users data was deleted at a set interval after they cancelled their subscription.

He executed some code only to realise, with horror, that his instruction to delete data wasn’t limited to a single customer, and he was pointing at production data.

It’s one of those mistakes that happens when you’re under pressure and working late.

In a flash he thought he’d just deleted the data for every customer in the system.

As it turns out, he hadn’t, and the process failed in such a way that nothing was lost.

So what’s the connection?#

There’s a hidden force in play in each of these situations.

In the case of the video game, adding more of this force made the game more challenging (and therefore enjoyable).

In the case of the change approval process, too much of this force made it way too hard to deploy changes to production, and disincentivised everyone from changing anything.

And in the case of nearly deleting everyone’s data, a little more of it would have helped prevent potential disaster.

That hidden force is friction.

If you’re struggling with something at work, chances are there’s friction in the process.

If deploying to production is onorous, time consuming and risky, you’ll avoid doing it too often.

Implement Continuous Integration and Deployment, with resilient tests, and you can deploy multiple times a day.

If your boss hides in their office all day, with the door closed, and looks annoyed when you walk in to ask them something, you’ll avoid turning to them for help.

They’ve added friction (whether they meant to or not).

If cancelling your Netflix subscription required a phone call to the head of Netflix, a lot of people would just keep paying for their subscription.

Add friction, and people are likely to take the easier path.

On the flip side, sometimes you want to add friction.

If there’s a chance you might delete production data because your developers have direct access to the prod database, add the friction of requiring separate usernames/passwords.

Or have a process that means no-one can write SQL statements directly against production.

In one company I worked for they created a tool for making those kinds of changes.

It took snapshots, checked SQL statements for dangerous statements (like missing where clauses) and warned if a command was going to affect a large number of records.

Whether you’re working by yourself, in a team, or leading a team, you can affect real change when you learn to spot friction.

Add friction if you want to do something less.

Reduce or remove friction if you want to do something more.

Here’s your challenge.

Next time you’re frustrated by something, and feel like it’s harder than it needs to be…

Think about what friction there is in the process.

Find a way to reduce that friction, even just a little bit, and see what difference it makes.