A Development Team Experience: How Dependency Mapping Could Have Saved Us (Part 2)

If you haven’t already, check out Part 1 of this blog series to learn about my experience working in a development team with a big decision to either refactor or rewrite.

Looking back on my experience from Part 1, my team needed an objective approach to evaluating our application and underlying codebase. Our team was making decisions based on gut reactions versus tangible data, which caused unnecessary confusion and cycles spent on the wrong approach. Dependency mapping could have enabled our development team to measure, quantify, and visualize complex and highly coupled areas of code, resulting in data points and visualizations that we would have used to inform discussions about rewriting the code.

Measure and quantify

Knowing what we know now, we would have benefited from dependency scanning capabilities that could have provided objective insights by surfacing data derived from the application itself. By gathering data points directly from the application, discussions would have been focused on objective findings rather than subjective tribal knowledge and human frustrations.

If we had used dependency mapping we could have taken those data points and applied a quantitative system to make them useful. For example, when our team was evaluating a specific feature and determining if it could be refactored, we often struggled with where to start. We didn’t have a way to rank which areas of the code would have the biggest impact on our project. All we had were the experiences of individual developers and their “best guess.”

Dependency mapping would have supported a more pragmatic approach by empirically scoring code complexity and usage. Surfacing attributes such as complexity and usage enable teams to identify problematic areas in their code so they can estimate impact and avoid unnecessary break/fix cycles. Dependency mapping would have provided us a place to start. Our team could have saved several weeks of research by using dependency mapping to automatically identify high-risk problem areas.

Visualize

A picture says a thousand words. More importantly, a picture saves the time otherwise spent saying those words. For several weeks, our team discussed problems with the code. We researched options. We drew pictures. We spent too much time debating and not enough time doing.

To make matters worse, we relied on tribal knowledge to draw diagrams and hoped they were accurate enough to make wise decisions. What we didn’t realize at the time, was that our “diagrams drawn from memory” were too simplistic to adequately describe the complex web of dependencies we would have to untangle when we attempted to rewrite the code.

Visualizing dependencies is not new. But visualizing dependencies via automatic real-time scans is a game-changer. Visualizations would have enabled engineering to demonstrate their frustration and pain points to non-technical participants such as the product and management teams. Just as important, if our development team had access to dependency maps and visualizations, the conversations would have centered around the actual areas of the code that needed to be refactored, not rewritten. In other words, our project approach would have been clear and known.

Conclusion

Dependency mapping would have offered our team a data-driven alternative and helped us make important project decisions. It’s clear to me now that the code assessment format my team utilized was informed more by emotion rather than fact, which ultimately led us to rewrite the code. In retrospect, our decision should have been to refactor the product, but we were missing the objective insight that could only be provided by dependency mapping and visualization. Moreover, it would have saved us weeks of research, months of frustration, and two years of development time and money.