Treat software as data

Suppose I tell you that the data depicted in the graph below comes from a productive database and it shows the connections between some tens of thousands of nodes and some hundreds of thousands of edges.

Now suppose that I would ask you every day to investigate the impact of modifying some variables from this graph, how would you approach the problem? The problem is obviously complicated and holds too many variables. Thus, you would likely not want to do it by manually inspecting textual descriptions because it would not scale in the long run.

Instead, you would probably want to rely on a tool that enables you to extract and browse the meaningful information. And if you do not have this tool, it would likely be better to build it first, especially if you are a software engineer.

Now, I tell you that the data does not come from an insurance database. It comes from a software system and it depicts a fraction of the connections in that system (classes, methods, and attributes as nodes; containment, inheritance, and calls as edges). If I now ask you to investigate the impact of modifying some methods from this graph, how would you approach the problem?

The problem is obviously complicated and holds too many variables. Thus, you should not want to do it by manually inspecting textual descriptions.