Software visualisation techniques for getting in touch with the root (cause)

When something’s going a little awry, it’s quite natural to want to turn your nose the other way in a bid to avoid bracing the hard truth of the matter. Luckily, there’s no choice with a software map, as the areas of code causing problems are so obvious for the way that they stand out against their peers. Root-cause analysis is often hailed as an ideal for the way that it avoids the irritating tackling of problems on a surface-level, only treating them symptomatically and thus preserving the chance of them reoccurring: not the most desirable heirloom.

Root-cause analysis finds a home in the software map, as those code units that are throwing around the most influence manifest as the elephant(s) in the room:

Tall, red buildings draw your attention, while the dashboard provides an overview of best or worst performers for a number of preselected metrics to further guide your evaluation. Bringing the code back into easy, communicable territory, the map brings it down from its aloof abstraction and realigns it with its intended purpose; with the clear metrics and illustration, it’s very easy to evaluate and create an onward strategy with this information that defines exactly which code units aren’t pulling their weight, particularly when it comes to the managing of resources that is so often so essential to a team of developers.

With the power to take into its care the sum total of your past code repositories, analyse them, synthesise them, and present them to you in a form that allows you to draw a consistent line between the behaviour of one code unit and another, the software map can be your code clairvoyant; not only are you able to understand the immediate impact of changes, but able to devise what they would spell for the future evolution of your code. Mystical indeed, and the cornerstone of its importance as an innovative presence in the world of software visualisation.