Productivity is a by-product of quality

The story goes like this. On Wednesday, Bill, the Project Manager, approaches you and asks for a couple of new features for that app you’ve been building.

He then tells you that it needs to be finished by next Friday.

Sometimes, there wasn’t even a meeting to estimate the amount of work needed. Other times, there was one in which you gave a bigger estimate and now he’s asking for a shorter amount of time. The bottom line is, you know it’s not possible.

What do you do?

Work faster

You say ok. I’ll try to finish it by Friday.

You start coding as fast as possible. No time to grab a piece of paper and think about proper design.

You just cut to the important parts: what’s the minimum that you can do to finish on time? That means asking for a coworker to code review your PRs in a rush. No time to write unit test. Just merge the damn thing ASAP. You tell yourself you’ll clean this up later.

So you finish. Barely on time.

Code quality

This affects the quality of the code you’re producing. You wanted to refactor the code that you had just rushed, but your schedule is slammed for weeks. Before you know it, another engineer is building on top of your hacks.

Since you’re not shielding your code with unit tests or proper code reviews, the quality of the output suffers, which leads to more bugs in production.

IBM System Science Institute Relative Cost of Fixing Defects

And fixing bugs in production is a whole lot (100x according to that IBM study) more costly.

Not thinking about how you’re building something doesn’t lead to a lack of software architecture, it leads to bad software architecture.

Contributing to bad architecture doesn’t have an immediate effect on how productive you are. But we’ve all worked in a codebase where we don’t quite understand what’s going on. Trying to develop on top of that is not only slow and hard, it’s also very error-prone.

That means that you have less time to implement new features. Even worse, if this rapid cycle of development keeps happening where you keep pushing code out of the door without considering code quality, this will make you, by the end, move slower and slower each release cycle.

Uncle Bob says this in a study done for Clean Architecture:

Clean Architecture: A Craftsman’s Guide to Software Structure and Design
They started out at nearly 100% productivity, but with each release their productivity declined. By the fourth release, it was clear that their productivity was going to boom out in an asymptotic approach to zero.

This is why it takes developers longer to develop the same feature in a codebase that is 1 year old than in a fresh, new project.

The less you think about your code quality, the slower you move.

Work longer

But there’s another, more common, option. Sacrificing personal time. You don’t completely feel comfortable rushing and not thinking about how to design the feature. So instead of just running to the goal, you take more time. You start getting earlier to the office and leaving later.

You cancel on your friends and spend your nights with your laptop trying to complete everything by next Friday.

Photo by Abbie Bernet

Quality of life

I’ve seen this a lot. Especially with young developers starting their career. I’m not sure if it’s because they want to prove themselves and feel like a hero at the end of the day, or if it’s a misplaced sense of pride on working late at night and being tired the next day. But let’s state this right now, burnout is not a joke.

When you’re burnout you’re not only tired. You’re probably closer to depressed. Or at least, that’s how I felt.

It took me months to finally come back and start feeling good about everything again.

Burnout is not only bad for you. It’s also bad for the work you’re producing. When you’re burnout you move a lot slower, because you’re not motivated. When you feel constantly tired you don’t get a lot of pleasure in hitting keys on your laptop.


A couple of months ago I went to the dentist before UIKonf. I wanted to remove all my 4 wisdom teeth. My dentist told me that was not possible and that he could only remove 2 of them right away, and he could remove the other 2 a couple of weeks after, still fitting with my timeframe.

I took 2 off and then I went back to the dentist a couple of weeks after. I could barely open my mouth still and it was really hurting. I had to travel in a week to UIKonf.

My dentist, unfortunately, told me that he couldn’t do it. That I’ll have to wait because removing my other 2 wisdom teeth immediately was going to cause me a whole lot of problems. I really wanted to remove them, but I listened to reason and waited because it was the right option in the long run.

The only real option

There’s another option we haven’t discussed. The option is just to say no.

Photo by Andy Tootell

When Bill approaches you with that impossible deadline. You say no.

When he tells you about all the business issues that will happen when you don’t comply with finishing on Friday, you really need to say no.

Be professional

The same as my dentist told me it wasn’t possible to remove my wisdom teeth, I’d argue that the only professional option for us as developers is to say no.

But at the same time, you need to explain why. You need to discuss all the issues this will cause in the long term.

If you immediately say no, that’s actionable. You can then discuss with your PM and with the stakeholders and try to find an alternative. Maybe you can reduce the scope. Maybe you can incur in technical debt, and find out how to pay it after the release date.

By writing fast code without thinking about the future you’re being unprofessional. We’re not here to build fast features. We’re here to bring value to the products we create to help the clients that will use them.

If you’re saying yes just to get your boss off your back you’re failing in acting professionally. Fight for a better product. That’s what you’re being paid for.

By focusing on quality first, you’re giving yourself the gift of future productivity.

This article is heavily inspired by both Uncle Bob writings and a talk I gave at UIKonf.

This was originally published in The Human In The Machine.