Posted by: lrrp | May 26, 2017

How do you balance code quality and development speed?

Code quality and development speed are two essential – and sometimes conflicting – factors for software development teams.

Proper development requires careful design, solid implementation, and testing. Tight deadlines may compromise this process. On the other hand, applying the best overall solution may stand in the way of delivering speedily.

At Codementor, we believe that both code quality and shipping speed are important. Shorter ‘time to market’ makes us more agile as a startup, while good code quality makes future development easier, faster, and more stable.

Here’s what we do to achieve these goals:

  • Make sure all team members from our dev, design, and product teams know why we are building features
  • Identify which features are essential for each release

If there is one thing worse than shipping a feature slowly, it’s definitely to ship the wrong feature. Most of the times, a few lines of description on a Github issue are far from enough in order to explain the context of a feature.

Not knowing and understanding the “why”, developers will build features like they’d construct a house with only part of the plan. They might be able to build something that meets the immediate needs, but they will not structure the code taking into account future changes. After several iterations, things will become slower and slower, it’ll take more and more time to release features that could otherwise have been shipped fast.

If developers are aware of the context of a feature, they can build it while keeping possible future changes in mind. If the project falls behind schedule, they’ll be able make the necessary adjustments only if they know the “why”.

There are always unknown unknowns in the development process. This may delay the shipping. When this happens, we always ask ourselves:
Are all these features essential to test the market? If not, what are the features that can be cut?

Most of the times, we can find features that can be cut or built in a “reduced” form.
Sometimes, the same business goal can be achieved with a simpler technical approach or by introducing a tolerable amount of technical debt into the system. But only when developers know the context of features can they make the acceptable and reasonable trade-offs.

How do you (or your team) balance code quality and development speed?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: