Technical Debt Scenario #3: I don't care about the product.
Let us examine the third scenario "I don't care about the product." of how technical debt can cause.
If you are interested in the first and second scenario how technical debt can cause click on the link below 👇
Table of Contents
The scenario
👨🦱 Developer 1: Hey, I sent you a pull request for User Story X. Can you take a look at it?
🧑 Developer 2: Wow - you are fast. Okay, I will take a look.
🧑 Developer 2 looks at the pull request.
🧑 Developer 2: Okey, hmm...I see several problems:
- Why did you comment out the tests of feature y?
- There's a lot of duplicate code...
- ...and your code looks a bit hacky. There are a lot of different code smells.
👨🦱 Developer 1: OK, I see your points. But can you approve it? I will fix it later.
👨 Developer 2: Alright. I agree with it. Let us correct it later.
👨🦱 Developer 1 merges the Code of User Story X into the development branch.
Background info: The issues were never fixed.
What's the problem here?
This problem has two points of view. Let us outline the different aspects of this problem:
- Lack of techniques and tools to promote technical excellence no usage of basic engineering techniques, lack of state-of-the-art tools to help identify and make visible such hacky routes.
- No intrinsic motivation, no real or long-term interest in the product and/or the company.
Especially in the second problem "no intrinsic motivation" I see a huge unrecognized and therefore untapped potential. If you do not care about the software product and are only there to spend your time and get your salary, you will take shortcuts even as a developer. Without intrinsic motivation, there will never be true product ownership. Without true product ownership, there will be no technical excellence either. This is how technical debt is accumulated.
Any technical, methodological and organizational toolbox, no matter how good, is of no use if there is no intrinsic motivation and no long-term interest in the product and the company.
How can you prevent this problem?
According to the different aspects identified, I also try to answer two different approaches to avoid this problem: a technical approach and an organizational approach:
- How can you technically ensure that such shurtcuts are prevented or detected at an early stage?
- How can you promote intrinsic motivation and long-term interest in the product and ultimately in the company?
How can you technically ensure that such shortcuts are prevented or detected at an early stage?
First of all, I assume you already have version control and a CI/ CD pipeline. If not, you should start now.
Automated quality gates in your Git flow to avoid poor technical quality
For this particular problem, it is necessary to at least make these shortcuts visible. If you make these shortcuts visible, there is likely motivation to fix them. In addition to visibility, in my humble opinion, you should introduce some quality metrics as quality gate that are automatically validated by your CI/ CD pipeline. No code can get into a productive branch if the defined quality metrics are not met.
There are several metrics that are relevant in this scenario:
- Test coverage: in the above scenario, commenting out automated tests decreases test coverage.
- Code smells: Code smells can be caused by unclean code and disregard for best practises. Code smells are usually not bugs, but indicate weaknesses in the design and can slow down development speed and increase the risk of bugs.
- Code duplication: Code-Duplications is often the result of "copy-and-paste programming" where a section is copied because it works.
- Security vulnerabilities: Unawareness can lead to security vulnerabilities in code.
Related problems must be identified using these metrics. With a large codebase, these issues can only be identified automatically as part of your build and deployment pipeline. The following figure shows how you can protect your trunk with an automated technical quality check. If the technical quality check of a feature or bug fix branch fails, no one can merge it to the trunk. Each time a commit occurs, a report is generated with the above metrics.
There are a number of proven tools that provide this automatic quality check. All of these tools can be integrated into your build and deployment pipeline to prevent declining test coverage, code smells, code duplication, and security vulnerabilities in your codebase.
The following is one of my current favorite integrated cloud tool stacks for implementing automated quality checks:
- Sonarcloud: Static Code-Analysis
- jFrog Artifactory & Xray: Dependency Management, Vulnerability and license Check of 3rd party dependencies
- Snyk Code: Static application security testing
- Bitbucket Cloud / Bitbucket Pipelines: Version control with an integrated managed build system
Pitfalls with code quality reports
Each of these tools has its own reports. One pitfall is that these reports are often misused as a tool for blame and finger pointing. I often experience a non-technical person wanting to see some metrics, a prominent example being test coverage. A resulting message from such a person might be, "Hey, your test coverage is too low. Increase the test coverage, now!"
But there's quality in testing, too. For example, you can falsify test coverage and create useless tests, which on the one hand increases reported test coverage, but on the other hand does not improve technical quality.
The key message here is. Keep these reports within your team. Define useful metrics and quality gates within the team. Ideally, do not politicise these reports.
How can you promote intrinsic motivation and long-term interest in the product and ultimately in the company?
Disclaimer: This area is not my specialty. But I have often found that the lack of intrinsic motivation implicitly encourages the buildup of technical debt because many employees simply do not care. I am very interested in how to foster intrinsic motivation in demotivated team members. The following thoughts are not finalized.
Products over Projects
Building product teams is not as easy as it sounds.
Often companies suffer from a project-oriented mindset. I see this a lot, "Let start a project to build or to modernize a software product."
In my humble opinion, this approach is contradictory in most cases. Why is it contradictory?
- A project has a start date, an end date, a more or less fixed scope, and a fixed budget.
- A product usually has no known end date, its scope is flexible and end-user/customer-oriented, and it requires continuous investment. A product should offer the company and its employees (!) sustainable financial security.
Like the contradiction between project and product, the roles of project manager and product owner usually have conflicting goals:
- The project manager wants to achieve the project goals on time within the established scope and budget. He wants to meet the needs of the project stakeholders.
- A product owner wants his product to meet the needs of customers. He wants to ensure that customers continue to pay for product value.
When you move to product teams, you give your employees a perspective, a long-term commitment to a product team, and a way to identify with a product.
I believe that a long-term perspective with product teams can increase the intrinsic motivation of individual employees and thus reduce the implicit accumulation of technical debt.
See also the post "Products Over Projects" on martinfowler.com 👇
Offer autonomy with competence and responsibility
However, organizing into product teams alone does not solve everything. Once you have organized the company and its products, the next step is already done.
Give your product team autonomy with competence and responsibility.
Basic competencies for an autonomous product team:
- The team is able to talk to and engage the end-user to get feedback on the software product.
- The team is able to discuss with the paying customer to get feedback on prioritization.
- The product owner has the sole authority to prioritize the entire backlog along with the customer requirements.
- The team has the authority to define its own release cycles.
Basic responsibilities for an autonomous product team:
- The team is responsible for ensuring that the needs of the end-users of the software product are met.
- The team is responsible for ensuring that the paying customer does not jump off because of lack of features or dissatisfaction.
I am convinced that autonomy, fast and tight real customer feedback cycles and decision-making power can have a big impact on motivation.
Extra: Offer shares and support intrapreneurship
A software developer makes hundreds of micro-decisions every day. Each of these decisions has a small but important impact on the business success of the company.
If we take the example above:
If the developer temporarily comments out automated tests, the developer and the review risk that there will be a side effect, namely that a feature will no longer work after this merge. If a buggy feature goes into production and the end-user can not use the affected feature that solves an important problem, the paying customer could bounce. This, in turn, negatively impacts the economic efficiency of the company. Roughly speaking, they risk a negative economic impact for the entire company by making this micro-decision.
To increase engagement with a company, as an employer I would suggest offering shares to your employees. But of course, I realise that not every employee wants to be a shareholder in the company. But if an employee declines a shareholder's offer, you should ask him why. I am convinced that if he's honest, he'll give some very interesting reasons that can only move the company forward.
To get good product engineers today, it's no longer enough to have a coolness culture, a foosball table, and a fridge full of beer in the office.
Only effective incentives promote long-term intrinsic motivation and sustained commitment to a company.
Summary
If your development team is moving too fast and constantly breaking things, there are often two problems:
- Lack of technical excellence
- Lack of interest and low intrinsic motivation to build a long-term relationship with the software product and the company
To address the first part, introduce basic techniques like continuous integration and continuous delivery with built-in technical quality checks as merge gates.
To address the second part, provide organizational support by forming autonomous product teams and offering additional shares to your product engineers to enable and encourage long-term commitment to the software product.