Technical Debt: How to Balance Between the Velocity of Production and Code Quality?

Code quality and velocity of production are two crucial but sometimes conflicting factors for software development projects. It is not surprising that sooner or later each development team faces the issue “speed versus advancement”. No doubt that both code quality and delivery speed matter.

You may also like: What Technical Debt Is and How to Calculate It

Good code quality makes future development simpler, quicker, and more stable. At the same time, a high velocity of production makes the company more agile, and thus more interesting for the customers. But how can a software company find the right balance between short time-to-market and minimizing poor quality code?

What Is Technical Debt?

How can we define tech debt? Technical debt is the term used to describe code that was not written properly and can harm the ability to add new features in the future. We can think of tech debt as the work that should be done to improve the code in order to make it more efficient and clear. On the other hand, these improvements won't necessarily bring additional value to the business.

Originally the term Technical debt was coined by an American programmer Ward Cunningham, the inventor of the first wiki. The idea was to think about tech debt as an analogy to financial debt. If there is a debt — there is an interest that should be paid. In the case of tech debt, the interest is equal to the additional development work that it takes to add new features after sub-par code was used.

What can lead to technical debt? Tech debt may occur as a result of unreasonable requirements, misguided assumptions, poor communication, or unrealistic timelines. It is not uncommon that developers cut corners to meet the deadlines, but the question remains — should they always do that?

Speed vs Quality?

No one will argue that both code quality and velocity of production are important. For obvious reasons, different types of companies choose high-quality development at the expense of speed and vice versa. On one hand, we have a very natural desire of startups to move quickly, so they can release their product to the market as fast as possible. On the other hand, we have the logic of well-established companies whose profile is too high to produce low-quality products, so they usually lean towards the quality mode.

Moreover, the employees of the same company can have different and even opposite views on speed vs quality of development. Salespeople or product managers are usually considered to be advocates for speed as they see the success of the company in its ability to meet deadlines and generate income. They usually don't care about how to avoid technical debt. For the developers, designers, and QA-engineers success mean building a perfect product, so they would rather spend months on development and not think about velocity.

But is there a way to strike a balance between code quality and speed development?

“Prioritization is the key. You can't win everywhere. First of all, it's important to find the most critical variable and concentrate on it. It depends on whether you plan to throw away your product after product/market fit is found and re-write it, or your strategy is to grow it gradually,“
— Alex Gostev, Project Portfolio Manager at QArea.

If the company doesn't want to lose pace, the code quality should become its top priority from day one. “Code quality is multifaceted,” Gostev adds, “It starts with architecture. And with the right architecture, you'll have significantly fewer issues in the future.“

It is also important to create a road map of tech debt projects and evaluate the risks so the company can plan accordingly. According to Dmitriy Barbashov, the Chief Technology Officer at QArea, a service-level agreement might help as well. “I would say that transparent SLA established and agreed with developers would be a good reference point for them,” he notes.

It goes without saying that striving for perfection in development is not always the right choice. For example, if a startup is building its first prototype, quickly created MVP minimizes the risk of investing much effort into an idea that won't work. Developers should be very careful when trying to deliver features rapidly or make some quick fixes. On one side, investing time in a solid foundation may help build new features in the future. On the other side, some hacky fixes or some cheapest and fastest solutions may accumulate and turn into too much technical debt.

Like in many aspects, smooth communication plays an important role in finding and proving the balance between code quality and speed. Open conversation between executives and developers is crucial. And if the company has found the right balance it is important that every employee understands it. Whenever the circumstances change or organization makes any moves towards speed or quality, everyone should stay on the same page.

Further Reading

Technical Debt: What It Is, Why It's Important, and How to Prioritize It

The Three Secret Types of Technical Debt