Table of Contents
Table of Contents |
Healthy Codebase | Unhealthy Codebase |
|---|---|
| 
|
| 
|
Technical health does not happen automatically
A codebase starts small, but grows fast. When you start adding developers, scale the code, and create differentiated teams, complexity and its burdens come to dominate
Unfortunately, there is nothing about good processes (such as Agile) that cause good architecture to happen. In fact, many Agile practices promote the creation of bad architecture.
A well architected systems is a highly ordered system. Complexity (the breakdown of architectures) emerges in complex systems naturally, in a process similar to entropy. Work must be done to keep codebases healthy.
Your code needs to go to the gym
Our philosophy at Silverthread is to focus on metrics that matter. There are 1000s of software metrics captured by various tools, but most suffer from a lack of evidence that improving them will improve your outcomes. If developers are asked to focus on 1000 things, with 950 representing only busywork, nothing will get done. Technical health improvements should be focused on a small subset that impact developers' lives and business performance.
Metrics matter when:
Theory - We have a theory as to why the metric captures an important facet of technical health
Evidence - We have statistical tests or data that tells us that the metric correlates strongly with business outcomes - such as productivity and quality
Actionable - We believe the relationship is causal - I.e. If you fix this thing, it will make the codebase better and improve organizational effectiveness
Benchmarked - Where is your code relative to comparable systems? If you are already at the 90th percentile, you’ll get limited returns. If you’re at the 30th percentile, you have a lot of opportunity for improvement and gains.
Your goal should be to align technical leadership and business leadership around improvements that drive organizational effectiveness.
