TLDR for “Managing Technical Quality”

Some notes from https://lethain.com/managing-technical-quality/ – most of the comments are copy/pasted, so ‘I’ is the author… In italic some more C4DT-specific notes.

  • Technical quality is a long-term game. There’s no such thing as winning, only learning and earning the chance to keep playing.
  • Do the quick stuff first!

Hot Spots

  • Before defining new processes, measure the problem at hand, identify where the bulk of the issue occurs, and focus on precisely that area.

Maturity Evaluation application, work on red boxes of column I

Best Practices

When you’re rolling out a new practice, remember that a good process is evolved rather than mandated. The handful that I’ve found most helpful to adopt early are version control, trunk-based development, CI/CD, and production observability (including developers on-call for the systems they write), and working in small, atomic changes.

Maturity Evaluation, yellow boxes, needs buy-in from the lab and regular follow-ups.

Leverage Points

  • As you look at how software changes over time, there are a small handful of places where extra investment preserves quality over time, both by preventing gross quality failures and reducing the cost of future quality investments.
  • I call those quality leverage points, and the three most impactful points are interfaces, stateful systems, and data models.

This is probably the last point that we can influence as the C4DT Factory. This requires that the lab is OK with us working on the software artefact in question.

Technical Vectors

One sure-fire solution to align technical direction is to route all related decisions to the same person with Architect somewhere in their title. This works well, but is challenging to scale.

More decentralized approaches include:

  • Give direct feedback.
  • Articulate your visions and strategies
  • Encapsulate your approach in your workflows and tooling
  • Train new team members during their onboarding

Measure Technical Quality

My experience is that it is possible to usefully measure codebase quality, and it comes down to developing an extremely precise definition of quality.

After you’ve developed the definition, this is an area where instrumentation can be genuinely challenging, and instrumentation is a requirement for useful metrics.

Technical Quality Team

When spinning up and operating one of these teams, some fundamentals of success are:

  • Trust metrics over intuition
  • Rotate with developers

Quality Program

Operating organizational programs is a broad topic about which much has been written

  • Identify a program sponsor
  • Identify program goals for every impacted team and a clear path for them to accomplish those goals
  • Build the tools and documentation to support teams towards their goals