I know this isn’t something most developers like to hear, but I think it’s true.

I blame developers for not pushing back hard enough to defend their number one asset. The most important part of any piece of software. Code quality.

And I do understand the balancing act that needs to happen in order for the business to compete in the marketplace, but I stand by my conclusion. It’s the developer’s fault.

I don’t say that to make anyone feel guilty or anything. I say it because I want to empower all development teams to do better.

Why do software projects slow down with time?

All projects start out as this nice flow of ideas, that materialize beautifully into extraordinary applications that users love to use.

Adding features is a breeze, and it happens almost at the speed of thought. And everyone’s happy.

But as time goes by, and more and more features get added, something interesting starts to happen behind the scenes that brings development speed down to a grinding halt.

It’s the turf wars

Managers need to be managers. They fight for the speed team.

That’s their job. And they defend it with everything they’ve got.

If the project keeps moving forward fast enough, that means managers are doing a good job. Boss is happy. Taps on the back are in order.

But code doesn’t grow linearly. Moving faster and faster or even at the same rate is not sustainable for long periods of time.

And that’s where the war starts.

Managers want graphs that go up and to the right, and developers could not care less about it.

So to keep the speed up, something or someone’s got to give.

And that someone is usually the weakest link in the chain. The worst at dialog. The developer.

Developers have a choice

The main reason good projects go south is deprioritizing code quality.

But code quality is a slippery concept. It’s hard to define and measure.

Even more so, because it’s hard for developers to tackle, it’s even harder for non-technical people to understand why it’s essential.

So that’s a challenge because, in order to keep the quality up, developers need to push back. And to push back, they need a compelling argument.

Code quality should be non-negotiable. But ultimately the developer has to choose between pleasing people and doing his job the best way he knows how in order to keep code quality up.

It’s the developer’s responsibility to defend quality with everything he has. I don’t care if management agrees or not. But they should.

So then, how come so many projects fail in this regard? Why don’t developers fight for quality?

They’re afraid

The obvious reason developers shy away from defending their turf is because they worry too much about losing their job.

And obviously, that’s always a possibility.

But as scary as that thought might be, it’s probably never going to happen.

You know why?

Because the best developers do not take orders from their boss, nor do they focus on making managers happy. The best developers focus on the success of the product.

When you give everything you’ve got to make the project a success, and the boss decides to fire you anyway, it’s time to celebrate. You stood up for what you believe, you’ve done your job right, and your professional life will get a lot better because of it.