Bollı•nn.

Everything can be improved - but that doesn't mean it should be

Developers have this optimistic approach of "improving things." I felt the same most of the time - rebuilding, improving, and upgrading is part of a developer's foundation. We're hired mostly for that, so when we see such an opportunity, we're tempted to do it. We can show our skills, be useful, make things newer, more modern, fancy! Fame and glory! We just forget to ask ourselves a simple question.

Does this improvement actually matter?

This question is not about you - of course it matters to you to have the latest Next.js version or a nice, consistent codebase. Or you want to rewrite this old Shopify importer that was written in Go, and Go is for sure dead, or at least it's dead in 500 LinkedIn posts daily. Your manager, boss, and client all agree: yes, it would be great if we had that rebuilt.

All agree! Let's do it! But then, as a senior engineer, try to lower your ego and try not to think from your perspective. You'll see three approaches to the same work. Let's use the 2018 Go Shopify importer sample and assume it still does its job.

Should we rewrite it to Node, since our whole app is there?

You (developer)

  • Will our product be better?

    Yes! Nice codebase. Great success.

  • Will we have less to maintain?

    Yes! We could remove the Go service and save $10/mo.

  • Can it break anything?

    No, man, I'll do it the right way, trust me.

Client / Manager

  • Is anyone reporting problems with the tool?

    No, only the developer yells and screams every day.

  • Will it work faster or better after rebuilding?

    Possibly a bit faster if included in the main app. Like 0.1s or even more.

  • How much will it cost?

    It will take 6hrs, maybe around $300. The service is $10/month, so it's 30 months of Go service costs.

  • Do we have anything more important in the backlog?

    Actually, undelivered emails seem a bit more important.

User

  • Do I give a shit what handles my import function?

    No, leave me alone, it's worked nicely since 2018. But I still don't get the emails.

See how differently people ask questions when thinking about the same thing. Try to think from all three personas when considering improvements. You don't need any fancy spreadsheets or analysis when deciding on simple feature sets. Just a quick thought: "What value does it bring for all three of us?" will quickly set the right priorities.

What happens if we leave it alone?

That's another great question. Developers think quickly and do calculations right away, so it won't be hard. Imagine what can happen over some period of time if you don't do something. That's a cost too! Take our Go importer example again. What if we don't move it to Node this month? Probably nothing, but let's assume that either:

Refactor me please zombie GIF
  • The person who created it leaves the company next month
  • The Go service uses an old instance and needs a few functions upgraded to match a new package version
  • Two users reported problems with the importer recently - their tickets are in the backlog

That totally changes the situation and shows a very interesting thing (my favourite!). Knowledge of the background processes and general project state gives you more light and helps you make decisions. You need to know these things (read Go deprecation emails, track the HR channel, etc.), otherwise you'd stay in a pure development bubble and make wrong assumptions. Talk to people, read the news, check Slack channels - noticing somebody's 3-week PTO can help you choose what to do as well.

"While we're here..." problem

In the previous example, you probably thought of something like: "If we moved the Go script to Node, we could add CSV export too, and send automated exports to users." That's the common "while we're here" problem, when a developer wants to do more because the context allows it. If we entered the area, learned what the Go service does, migrated the service - why not make it better? The answer is simple:

Because nobody needs it. It will look good on the demo and be forgotten right after that.

Owners are also "while we're here" triggers

This is the funny part - because the biggest source of "while we're here" scope creep are clients / owners. They also dream of perfect software with a shiny codebase, buttons, and tons of features that get used. They also fight the internal battle of "Why shouldn't we do that?"

When they lose the battle, as a senior developer you should be able to judge and explain to them why we should NOT do things. The decision is theirs, but you can try at least to sound smart:

  • Did anyone ever ask for that? Do we have support requests on that? (Funny thing - I once had a client who lied "yes, several people" just to justify doing the feature.)
  • Do we have any data that confirms it's the right move? PostHog analytics? Web sentiment? (hint: we almost never have)
  • We have these 3 tickets in the backlog that are more urgent and quicker to fix - let's go for the low-hanging fruit first (and hope the priorities change after the weekend).
  • If we work on that this week, this [super fancy feature that owners love] will be delayed

Opportunity cost

I learned that phrase recently, so I'm showing off. In one of the paragraphs above, we stated a question: Do we have anything more important in the backlog? and I think it deserves a separate explanation. When thinking about doing some improvement, you are often thinking "doing this, or not doing this." In real life it's "doing this, or doing something else." Let's say you estimated the Go script improvement at 8 hours and it's approved. You are working on it.

During those 8 hours, you could fix email delivery. You didn't do that, and one client couldn't reset their password again, yells at support in frustration for the last time, and cancels the service they can't use. That's the opportunity cost - you lost a client because you chose the wrong (in this case) kind of work. This is real dollar loss, not just abstract value.

Trying to wrap up

When thinking about next steps, feature requests, and roadmap, think like a pro and ask yourself:

  • Who benefits if we improve that?
  • What will change and what are the risks?
  • How much does it cost?
  • What happens if we don't do it?
  • What are we not doing instead?
  • Would I still recommend doing this if I was the owner?
  • Would I still recommend doing this if I wasn't the person who gets to build it?