Can Devs be Held Solely Accountable for Bugs?

There is a trend in the industry towards minimizing operational costs by holding developers accountable for supporting production issues and minimizing the need for a legacy style Tier 3 team. This makes perfect sense from an accounting perspective. However when trying to go this route there are some challenges to overcome depending on the age of your code base.

For companies with legacy infrastructure and developer turnover, Tier 3 can play a role to fill the gap and keep developers writing new code.

The Ideal Model

---

Developer accountability. The fastest path to fixing an issue is to have the developer who wrote the code fix their own issues. They are usually intimately familiar with what they have written and can see where the issue is quickly. Using this method of support can drive better quality coding as developers don't want to fix issues with their code later on while they are facing deadlines for other projects.

Architectural / coding standards. Another mechanism to achieve this is to enforce strict architectural and coding standards across a company. This makes the code uniform and understood across the company, therefore enabling others to be able to pick up where others left off and easily understand a new code base.

Support Challenges

---

Here are some things I have seen gone wrong with the aforementioned model:

New product development deadlines. By far this is the biggest challenge to support: balancing the benefits of income from new development to the operational costs of correcting issues with the current system. To help out with this make sure you calculate out past costs, and if possible predict the cost of an issue over the next quarter. With these costs compared to new features you can have a decent argument to get production issues fixed.

Legacy applications can be difficult to support as developers who wrote them are not always with the company. The applications can be difficult to debug and understand except to those who have been at the company for a long time. This can stem from older application frameworks with limited debugging capabilities and difficulty in deploying to developer boxes. Legacy applications can have architectural deficiencies which make fixing some issues challenging without a rewrite. These will require a different kind of support model to be able to triage new problems / workaround and support them. Tier 3 teams can come to the rescue here as they usually have in depth application knowledge and know these legacy frameworks and even sometimes how to debug.

Use of contractors means you could have varying coding styles, more code, and lack of understanding of the business. With contractors while you have the benefit of not having to hire a developer, they come with their own coding experience and style. You may not have time to train them on your standards before they start writing. This can make their code more difficult to support in the future when they are not around. Some coding contractors get paid by the line of code, so you will have more code as a result of this model. This just means more code to debug in the future if something goes wrong. And lastly if these developers don't understand the business then they will have a much harder time being able to help out and support the code of a business they do not understand.

The size and capital of your company will impact the amount of resources you can spend to tackle legacy issues. Smaller companies will not just be able to throw a bunch of investment into re-writing legacy applications to remove these older harder to troubleshoot and maintain technologies. Companies need to make a decision about what they want their high paid developers doing: supporting production and / or writing new code.

Going Forward

---

Here are some approaches which I have found to work best in these situations to solve the aforementioned issues:

Use developer support for the first year of brand new application. Also when major releases go out developers should directly be involved in the support process for the weeks following. This stabilizes the applications and usually there will not be any continued need to developer interaction after this.

Only code what is your business. There is no reason to have custom in house coding for things such as deployments or the resources the cloud or application frameworks bring to the table.

Operations should be a part of the development processes. Operations should come to the table with their own standards to be met so the application is easy to understand, deploy and support.

Hire Tier 3 engineers who want to become developers or SRE's. This means the people in these support positions are working and training towards the areas where the development is coming from. This will give them impetus to dive deeper into the causes and therefore be better triage engineers for you.