Managing Technical Quality To Ensure a Five-Star Product
In the current landscape, it is crucial to prioritize the delivery of exceptional products and services to our customers. To do so, we must learn quickly from our users and do our job as an engineering team. The quality responsibility is, in most cases, being addressed by some people from the team, the leader, some more senior engineers, or those with more time at the company, but, this could result in a lack of knowledge sharing and opportunities for people to grow. So, by focusing our energy on the core business and collaborating as a team, we can achieve the finest craft of engineering.
In order to achieve that, rotating team members through different roles and responsibilities (inside the engineering universe) ensure that every aspect of a project is tested and examined.
According to the book, Staff Engineer: Leadership beyond the management track, is the responsibility of the leadership/engineering team to advocate for a high-quality product. In addition, it brings some steps over in how we can manage technical quality:
- fix the hot spots that are causing immediate problems
- adopt best practices that are known to improve quality
- prioritize leverage points that preserve quality as your software changes
- align technical vectors in how your organization changes software
- measure technical quality to guide deeper investment
- spin up a technical quality team to create systems and tools for quality
- run a quality program to measure, track and create accountability
It is evident that having a clear understanding of the issues pertaining to domains/organizations is imperative to establish a process that fosters technical quality outcomes. The diagram presented below outlines a proposed procedure for managing technical quality, starting with an engineering quality guardian assuming responsibility for the process.
To support it, the main pillars are bug reports, code quality, operability, tech debts, and developer experience. Below we can understand each one of them and the complete process overview.
High-Quality Engineering Pillars
Bug Reports
The first pillar is bug reports. The team’s priority is to listen and learn from users (stakeholders, final clients). At Inventa, we have some dashboards that the engineering team could access in order to see the major problems. This helps to ensure that every team member is familiar with the product and its functionalities, making it easier to identify and fix any issues that arise.
Bug checking can be time-consuming and require a lot of effort, but it is a crucial step to ensure that the product works as intended. So, a good alignment with the product team/stakeholders is important to understand the criticality of the report to address the root cause. However, be aware that some quick fixes could help the team to move forward.
Code Quality
To improve our code readability and maintainability, we should use some tools in order to help us with this process. Sonarqube is a tool used to detect technical debts in code. It helps identify issues that could potentially cause problems down the line, such as code duplication, security vulnerabilities, and coding standards violations.
With the help of coding standards like Klint, DeteKt, and the use of Sonarqube we can deliver clean code, but, this tool is only useful if we keep track of issues and keep enforcing patterns along the way. Considering this a pillar of software quality, engineering should focus on checking it regularly for projects with ownership. Not only code quality tools + CI/CD pipelines could help in this process.
The image below is an example static code analysis pipeline here at Inventa, using Github actions.
So, to keep your code with a clear architecture and code writing those tools helps. Rotating leadership to check these tools helps to deliver a better product.
Operability
Operability in software engineering refers to the ease and effectiveness with which software can be operated and maintained, in a simple way it means to look at how things are running. The dashboard below contains some metrics related to a Spring Boot application at Inventa.
The Google SRE book introduces a concise set of key performance indicators known as golden signals. These signals, including latency, traffic, errors, and saturation, provide valuable insights into the health and performance of your application; if your team is looking where to start the reference link can guide you there. Keeping track of those numbers aims to deliver a better user experience, retention, and cost implications. To sustain long-term success your team/company should involve this as a pillar of quality.
Other important mechanisms to smooth the operation and success of a business are service level objectives, error tracking, and incident management.
SLO defines the level of reliability and performance that a business aims to provide to its customers. Establishing targets and meeting them builds customer trust. So, having a close look at those numbers is extremely relevant to build better products.
Curious why we have adopted the following tools in our operational engineering? Check the following article written by Marcos Gomes.
Tech Debts
According to Philippe Kruchten, in Managing Technical Debt: Reducing Friction in Software Development, a simple analogy of technical debt could be related to mechanical devices:
the more friction a device experiences due to wear and tear, lack of lubrication, or bad design, the harder it is to move the device, and the more energy you have to apply to get the original effect.
Bring this to a software engineering world, Technical debts can result in the accumulation of outdated software, inefficient coding, and outdated development practices and as mechanical devices, if we don’t manage it things tends to fail. A simple way to keep track of it inside your organization is to write issues inside the repository project. Since those debts are technically related, is very important that the engineering team give visibility to stakeholders of the immediate impact and backlog created.
Developer Experience
Investing in a positive developer experience has many benefits for organizations. It improves productivity, helps attract and keep talented developers, encourages teamwork, makes onboarding easier, and boosts developer satisfaction and morale. When organizations prioritize the well-being and success of developers, they create an environment that promotes innovation, speeds up software development, and leads to long-term success.
At Inventa, we have adopted Backstage as our tool to address developer experience. Currently, we are using the service catalog, API Docs, and Tech Docs features that come from the main backstage functionalities. To get this process running, we should not limit this work inside platform teams, all the engineers should participate in searching for solutions to get our work more effective and funny. So, during the prioritization process of selecting a work to be done, we must consider DevEx prioritization. To start simply, the team can think of solutions related to this[source]:
- Create — Improve project setup and infrastructure definition
- Build — Verify that changes are free of syntax errors and compile.
- Test — Verify that all automated tests pass.
- Start — Launch end-to-end to simulate execution in a deployed environment.
- Debug — Attach debugger to start solution, set breakpoints, step through code, and inspect variables.
Which implies:
If effort is invested to make these activities as easy as possible, the returns on that effort will increase the longer the project runs, and the larger the team is. [source]
So, thinking about the long-term success of high-performing teams the developer experience is a must, considering it on a daily basis certainly changes the business impact.
Prioritization is the key
So far, we have talked about some pillars when searching for technical quality. If your team decides to dive deep into each topic, the team duties and backlog will multiply ad infinitum 🤯. Therefore, the art of prioritization comes in handy.
To effectively prioritize product issues, several key steps should be followed. Firstly, it is essential to define and align product goals, establishing a framework for evaluating issues that align with the product’s strategic direction. Next, assess the impact and urgency of each issue, considering factors such as customer satisfaction, revenue impact, and technical feasibility. Collecting stakeholder input from different company areas ensures a broader understanding of challenges and effective prioritization. Also, it is crucial to estimate the effort and resources required to address each issue, considering development time, dependencies, and available capacity. Lastly, prioritize is an iterative process, requiring continuous re-evaluation and adaptation based on changing circumstances, user feedback, and new insights gained during development. Being able to adjust and adapt helps you focus on important problems and create successful products.
A simple overview of each step over prioritization:
- Define and Align on Product Goals
- Assess Impact and Urgency, and find a useful framework 🙂
- Gather Stakeholder Input
- Estimate Effort and Resources
- Continuously Re-evaluate and Adapt
Getting the Job Done and Assessing Impact
Throughout our discussion, we have explored the advantages of effectively managing team quality and identified key pillars that contribute to the development of a high-performing product. It is essential to emphasize that these pillars should be tailored to meet the specific needs of your team and company. Each organization will find inspiration in these pillars as they adapt them to their unique context.
Once your backlog is populated, the next crucial step is prioritization. Given the fast-paced nature of our work in product development, there may be instances where our focus is solely on addressing bug reports or resolving technical debts. This is a normal occurrence. However, it is imperative to remain prepared for the moment when the opportunity arises to enhance the architecture, refine the code style, and improve the overall developer experience.
By continually evolving these aspects, we can ensure that our products are built on a solid foundation and foster an environment conducive to growth and innovation.
As part of the process, it is important to assess the impact of measuring the results, some metrics are:
Bug Resolution/Tech Debts
- The number of bugs reported; Bug resolution rate; Mean time to resolve (MTTR)
Code Quality
- Code coverage; Code complexity, use Sonarqube for it
- Architecture: https://medium.com/quintoandar-tech-blog/software-architecture-analysis-25bd0274d837
- Explore more metrics in [source]
Developer Experience
- Read Measuring an Engineering Organization [link]
Operability
- To start simple: latency, traffic, errors, and saturation
- Latter: Mean time to detect (MTTD) and mean time to resolve (MTTR), Availability, and uptime
- Advanced: SLOs
Finale
To achieve a five-star product, as a team we must be extremely connected and communicate in a high standard way. From the perspective of engineering, it is important to give visibility to issues and solutions that may not work long-term /or are scalable. With this visibility, the product, designer, data, and engineer can come together to decide the next steps. Listing, acting, and measuring results with consistency will lead to great results. A diligent team achieves more.
If you want to know more about us, add me on LinkedIn or apply to one of our open positions! Let’s learn together and build something bigger and better than we could do individually!
