Bad code quality is like clutter; a little bit here and there won't affect your productivity, but if you do not clean your workspace, eventually, it will slow you down until you can declutter your space. Yet, many teams fail to find a a good balance between decluttering their space and meeting new deadlines. But what is stopping them to achieve that code quality?
Mindset
From the point of view of a single change, some people can perceive quality as something that slows you down. From the point of view of the velocity of an organization, code quality is required to go fast. You need to be great at quality if you want to go fast at scale:
- If you want to have the possibility to do daily releases, you need to have an automated process to validate, release, and roll back your product.
- If your product breaks on every release, your customers' experience will suffer, and your team's operations will suffer due to unplanned quality work.
- Even if you don't do daily releases, you need the ability to integrate and validate changes to provide feedback to developers as soon as possible.
But that same people usually perceive the scope of the work as something smaller than it usually is. Ask this question. What's the job? Is it to merge the code or to have a product that works in production?
Plan for quality
Once you think that your job is to have a working product, then you can start avoiding Management mistakes that are detrimental to having a quality code base, such as only planning for development time and not planning for the time it takes to do other activities required to go to production: testing, writing automated tests, documenting, rolling out features, and setting up new alarms and metrics.
Flexibility
Experimentation and big changes must be flexible about all policies (quality, security, performance, etc.).
Doing a significantw big feature or service that passes all of the customer quality, security, and performance checks deploymentsmight require a lot of effort and impact your ability to deliver things on time.
It's ok to reduce the quality as long as you don't enable that thing to all customers (which might disrupt operations and customer experience)
You can start small with one or two customers, setting expectations (alpha/beta release) and iterating on what's valuable as you build your quality capabilities (continuous integrations, automated tests, infrastructure as code, metrics and alarms, documentation, etc.,)
