7 symptoms of insufficient traceability in your software project

With 25 years of experience, as a consultant, I help organizations in the .NET space to professionalize their entire software development efforts, from idea to production. During such visits, I get to scrutinize their development practices, quality standards, design principles, the tools they use, their deployment pipeline, the team dynamics, the requirements process and much more. In this series of short posts, I’ll share some of the most common pain points I run into.

In the previous post, we looked at the testability of your system, an aspect of software engineering of which nobody will challenge the necessity. But another part of what I call internal quality is the traceability of decisions, choices and considerations. This is reflected in a variety of symptoms that I will discuss now.

• I sometimes ask a team about the rationale for an architectural or technical decision. You’ll be amazed how often nobody remembers the reasons, even if the original developer is still available. And if they did capture that decision somewhere, it is often not clear which other options were considered and why the final option was ultimately chosen. A consequence of this is that often, technical choices are questioned over and over again, especially when new people join the team. If the thoughts behind that decision are no…