X. We Will Not Let Our Devs Boss Us Around

Are you afraid of your devs?

Devs are expensive, hard to find, and harder to replace. Devs have a lot of control over your product and systems.

There are tons of features on the roadmap that need to get done, but your lead developer tells you that you have too much legacy code to continue working as is. The team won’t be able to make any progress unless your app is rewritten with a better framework.

They’re the lead dev and they know what they’re doing, so you probably shouldn’t annoy them with questions. Also, they seem to be pretty certain this is the way forward even though it’s going to halt all progress for a while. Even if you could tell them no, they may not take it well and leave. You’d be completely screwed if that happened. It’s best to bend over backward to make them happy, right?

Wrong.

Unfortunately, this is really common. In theory, the devs work for you, but because you don’t understand the technical details, you feel you need to go along with anything they say, even when it will clearly have a negative impact on your business.

It’s true that developers work on complicated problems that can require creativity. What’s not true is that they should be given a free pass on making decisions that can dramatically affect your timelines. Your devs must be accountable, and they must understand the business objectives.

We all want to make beautiful software built from well-tested, well-documented, beautifully designed, elegant code. Sometimes, we even get to.

However, this is not what makes a successful business. Successful businesses provide value to their customers. Customers will never complain that the codebase is legacy, that your database is uncool, or that you’re not using the newest framework. None of those things have any effect on your company’s ability to help them make more money, save them time, or otherwise improve their lives.

When your developers complain about these things, they’re thinking about themselves and not the customer. They’re thinking about saving their own time. They’re thinking about technologies they want to put on their own resume. They’re thinking about how fun it is to play with new tools.

Don’t allow your devs to equate their wants with your customers’ needs. Tech debt is real. Productivity gains from new tools are real. Increased user-facing bugs from lack of tests are real. Your job is to make sure that those benefits are real for your situation.

It might actually be the case that the best way forward is a total rewrite. However, that is extremely expensive from a business perspective. Time is the scarcest resource, and you should not halt progress on a whim. Do not allow a dev to bully you into making that decision. Make them prove that it’s the best way forward—for the business.

If they tell you that writing new features is slower with your current legacy approach, ask them how much slower. Does it make sense to have 10% velocity now to get a theoretical 110% velocity later? Is a total rewrite the only way to get an increase in velocity?

If they tell you that a rewrite would reduce the frequency of user-facing bugs, ask them why. They haven’t worked with the as-of-yet-unwritten codebase, so what makes them so sure it would have a lower and not higher frequency of bugs? Is a total rewrite the only way to get a decrease in bug frequency?

Remember: Your devs are not irreplaceable. They don’t need to be expensive. They don’t need to be hard to find. You should not rewrite your app without exploring alternatives. Your devs work for you.

results matching ""

    No results matching ""