|
|
|
|
|
by jes5199
432 days ago
|
|
I’m in the same boat, I really like the idea of it but the actual use of it eludes me. It’s like there’s a cultural gap, even when they’re talking about the practical applications of the system it’s incomprehensible; I eventually came to the conclusion that they are doing a lot of work to deal with situations that I have never even heard of people being in |
|
The problem we address is how to understand a situation about a software system without relying on reading code.
Reading code is the most expensive activity today in software engineering. We read code because we want to understand enough to decide how to change the system. The activity is actually decision making. Reading is just the way we extract information from the system. Where there is a way, there can be others.
In our case, we say that for every question we have about the system it's possible to create tools that give you the answer. Perhaps a question is why not use standard tools? As systems are highly contextual, we cannot predict the specific problems so standard tools will always require extra manual work. The alternative is to build the tools during development, after you know the problem. For this to be practical, the creation of the tools must be inexpensive, and this is what GT shows to be possible.
This might sound theoretical, but it turns out that we can apply it to various kinds of problems: browsing and making sense of an API that has no documentation, finding dependencies in code, applying transformations over a larger code base, exploring observability logs and so on.
Does this help in any way?