Managing Technical Quality in a Codebase

I am a senior engineering manager for machine learning in a large ecommerce company. As an engineering manager, all of my stakeholders do not care or consider code quality or tech debt. Period. At all.

I have to burn bridges, cash in hard won favors, and be generally super pedantic and unpopular any time I have to defend technical quality as a worthwhile goal. I have to give presentations, scour months worth of incident postmortem data and exhaustively lobby for every single millimeter of leeway to protect technical quality. It is universally viewed as the number one thing “getting in our way” and preventing us from having greater delivery speed or agility to experiment with new features.

This article seems to describe a fantasy world where technical and product leaders care about code quality and are supportive of the efforts required to maintain it.

I have never encountered any place of business where this is remotely true.

This write up covers a lot of ground from specific issues around language and protocol transport layer choice to general advice that organisational change without a strong senior sponsor is hard. If you feel that quality needs to be increased the first question you need to ask is whether that is a widely held view. People have different expectations of trade-offs and may even benefit from noisy failures - which can grant headcount and greater focus. It might really not make sense to improve something that will be retired soon.

In this video https://www.youtube.com/watch?v=DpO1Tfa4IZ4 keynote, Amin Vahdat explains how he led a transnational approach to reliability in a huge complex system. In response to a question about whether hiring should be changed to increase reliability he says no - just that it needs to be measured and emphasised as a priority.

Great write up. Rushing to institute a new org-wide process as a solution to every problem makes productivity eventually grind to a halt. And at that point it can become a vicious cycle of continuous process changes in an attempt to increase quality and productivity.

One understated thing related to code quality is the social dynamic. People really do not like being told what to do. This is a reality anywhere in life, and requires a deft hand. Knowing when to push, what to push for, which hills to die on, etc.

Code style and linting should be an easy win. I think locating a few examples of a bad pattern in the codebase that multiple people repeated is a good way to make certain quality improvements sustainable. But you can’t do that every time otherwise people will think that’s all you do. You also can’t keep hounding one person in code reviews, you’ll lose their morale as well. It’s a balance, and almost more of a social issue.

Sometimes it great to point out stuff being done right too. It’d be great if it was a team effort so it there isn’t one word of god out there.

Do people find that leverage points, as described here, are well known for large code based, or are they difficult to identify, track and manage?

“... three most impactful points are interfaces, stateful systems, and data models.”