The Code Quality Advantage: How Empirical Data Shatters the Speed vs Quality Myth by Adam Tornhill

Code quality is an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for new features. The resulting technical debt is estimated to waste up to 42% of developers' time, causing stress and uncertainty in the process. Yet it's hard to build a business case for code quality: how do we quantify and communicate the benefits to our non-technical stakeholders?

In this talk, Adam takes on the challenge by combining innovative code quality metrics with analyses of how the engineering organization works with the code. We then take those metrics a step further by connecting them to values like time-to-market, customer satisfaction, and road-map risks. This makes it possible to a) prioritize the parts of your system that benefit the most from improvements, b) communicate quality trade-offs in terms of actual costs, and c) identify high-risk parts of the application so that we can focus our efforts on the areas that need them the most. All recommendations are supported by data and brand new real-world research. This is a perspective on software development that will change how you view code. Promise.

[mattgunter]

This was the same conclusion that Capers Jones came to in his research on software development (from the 70s, 80s, and 90s)

[zandark]

If I understand it correctly, the indicator of bad code was lines of code per file? If so it’s naive measure. Red code could be hard to maintain cause the problem this code is solving is complex in nature and error prone.