Code Quality

4 min read Original article ↗

Your powerful ally

Piotr

Investing in code quality takes skill, time and effort. It’s difficult to write and maintain healthy codebase but in the end, it really pays off. Quality is usually compromised by trying to save time, but ultimately, poor code quality slows everything down.

While the code is not a goal in itself, quality of codebase can be a deciding factor for a product’s success or a failure.

Bad Code Hurts Business

Imagine worst case scenario: you have to work with the ugliest code you’ve seen. Huge files, god objects, intertwined dependencies, inconsistent pattern usage, no modularity and zero test coverage. Project owner doesn’t allow you to refactor it, he just demands new features coming in week by week.

Do you already feel the pain?

You will.

The navigating project structure is hard. Method names and comments are misleading. Everything is against you. But you try anyway and modify a piece of code to fix a bug. After testing everything manually, you push it to the repo. Later you discover that your fix caused even more problems. So you go back and get bogged in this mess for good.

In poor quality codebases, adding new features is ridiculously slow, bug fixing eats up more and more time. Customers are annoyed by bugs and by inevitable poor performance.

The company struggles to evolve and it’s too slow to adapt to the ever-changing environment. People start abandoning the ship.

Good Code Helps Business

Now let’s imagine the opposite scenario: healthy well-managed software project.

Its code structure is readable and poses no surprises. Tests are comprehensive so it’s possible to refactor with confidence. Bugs happen rarely and are quickly fixed. New features are added with ease and the product is fast — because it’s easy to measure performance and optimize.

The team is confident, happy and the company outperforms competitors.

Middleground

In reality, such extreme examples happen rarely (but they do!) — most startups are somewhere in between. Usually, they start with the happy case when their project is still small and simple. However as the project grows in complexity, lack of proper care slowly moves the project closer to the hellhole scenario.

Naturally, your next question is…

How to Create Good Code

It’s about taking care to improve code quality. You should follow Single Responsibility Principle, Don’t Repeat Yourself, Keep It Simple Stupid cause You Ain’t Gonna Need It. Don’t mix different levels of abstractions, use descriptive variable and method naming and, of course, write tests.

Even if you follow those are guides for writing Clean Code, you can still end up with messy codebase if you forget about refactoring it on regular basis.

Project requirements change and evolve with time. So even if the code originally solved a problem perfectly, it needs to be updated to adapt to new requirements. The original structure no longer fits like a glove but it works so you move on. Tech debt accumulates slowly but if you are only focused on adding new features it won’t go away.

To avoid this you need to regularly refactor your codebase. Enforce consistency, extract modules and eliminate duplication.

When to Stop

Of course, it’s important to know when to stop. Code perfection is not a goal in itself but merely a way to satisfy business goals. Meeting customer demands is ultimately what matters the most — clean code is just a powerful tool to achieve it.

Don’t obsess with patterns and getting 100% test coverage but take project priorities into consideration. For prototypes and startups struggling to get product-market fit, initial development speed demands tradeoffs in code quality. Just be sure to pay off that debt once you are stable or you’ll lose the long game. Luckily, at ProFinda, we know it matters.