Each line of code a developer writes has a cost.
And I don’t think we (developers) are naturally good at estimating it.
So whenever we want to make a code change, we really need to ask ourselves whether it’s worth it.

A few notes:

• Being worth it
  It’ll depend on the team, the time, the situation.
  I’ll touch on this in a later post.
  Here I’ll focus on the things that happen when one does a code change.

• Code change
  I refer to code change as anything that’ll lead and follow a modification to your code base (e.g. a new feature, a refactor).

Making a code change is similar to baking a cake 🍰

There’s more to a code change than writing code.

Similarly to:

There’s more to baking a cake than mixing the ingredients.

When you bake a cake, you first think about your cake. What type of cake you’re gonna bake, the ingredients you need.
Dev thinking about that refactoring work they’ve been wanting to do for a while
Then, you make your cake. You weigh flour, eggs, milk, you chop almonds, cut bananas.
Dev writing code
You learn how to use your new egg mixer, you read the manual, figure out what speed to use.
Dev learning a new tech/library
In-between you get interrupted to answer an urgent friend’s call.
Slack message, system alerts
Once done you go back to baking, spend time remembering where you left off.
Then, you put it in the oven, check on it regularly, make sure it’s not burning.
Checking in after deployment
In the meantime, you clean up and do the dishes.
Follow up code change to clean some leftovers todos
Finally, you invite your friend to eat it.
Sprint review, demo to colleagues
You share your recipe and your tips for making it a success.
Maybe you even write down the tweaks you made or the things you’ve learnt.
Write documentation

It turns out writing code is (un?)surprisingly similar. Even very trivial code changes go through a similar (although shorter) version of this.

What’s the hidden cost of a code change?

With this (great) baking analogy in mind, let’s take a look at what’s involved in making a code change.

🤔 Thinking & brainstorming

The cost behind a code change starts with the person thinking about it.

New features are likely to come from data analysis, user research or an innovation project.
Other changes like performance improvement or introducing a new library come from a dev thinking and researching the idea: they think, they read, they experiment, they chat to colleagues. Even a tiny change often involves these steps.

And this is not free.

🤓 Learning

Next cost is learning.

It can be very small: for instance you read a part of the codebase you weren’t familiar with.
Or it can be big: you need to get familiar with a new library or tech you’ve never used before.
It’s very rare not to learn anything at all when making a code change.
Copy change or config change might be the only time when you really don’t learn anything.
And so you spend time up-skilling and learning.
(That’s one of the beauties of our job. We never stop learning)

But, again, not free.

✍🏾 Writing

Writing is the most obvious one.

But even when we talk about writing, we write more lines of code than strictly necessary.
You write a new feature, you refactor code.
But you also write tests: unit tests, integration tests, end-to-end tests. Since you want to make sure what you write is robust and won’t break in the future.
You may also write documentation.
Maybe you’ll also create new monitors/alerts to make sure all is working as expected.
There are various bits that may need refactoring or updating.

Many code change, no matter how small, will have this overhead.

Review & Peer learning

That cost is super interesting. It involves other people.
Some sort of lateral cost.

You’re the one making the code change but it needs to be reviewed and understood by a minimum number of your teammates.
They switch context, they read your code, they ask questions.
Maybe they need to learn about this new tech or library you’ve introduced.
It’s possible you’ve even set up a quick meeting to introduce them to this new thing you’re writing.
This cost can be exponential.
I’ve seen cases where a new cool library was introduced and we all had to learn how to use it, etc… and honestly for no valid reasons other than somebody decided it was cool ⛔

👩‍⚕️ Future & Care

Once something is written and deployed 🎉, it’s gonna need care.
It may need maintenance.
It’ll be read by many other devs.
They may have to up-skill and learn that new library you’ve added.
You may have introduced bugs that need fixing. Or things will have changed and will need to be adjusted.
And finally one day a dev will have to decommission/migrate/delete your change.

Any code change has an ongoing cost.

Conclusion

I believe it’s our duty, as developers, to ask ourselves whether what we do, suggest, propose is really worth it for the team and the company.
And not just for the present but for the future too.
The code you write will be your legacy. It’ll very likely outlive your time at the company. Make it count.