Of course these activities could be placed under the two other categories, but I dare to claim that they are sufficiently different from "normal" coding and "normal" debugging that they can stand on their own.
"What's the fuss about? We have that already!" I hear someone mutter there in the back. Um, yes, sort of. There are tools to visualize the process structure, but IMHO they are far from what they can be. There are no tools to help with the architecture of the system and there are almost none to watch it running. Here are some examples:
- visualize and edit the supervisor structure as well as the links and monitors between processes. With a graphical tool, I mean something like right click and add a child, drag and drop from it to create a link to another process, mark the process as trapping exits, and so on. This would of course get saved into the appropriate code modules.
- freeze execution of all application processes and inspect them without fearing that timeouts will kill them
- "sandboxes" for processes, allowing all to be killed and the application restarted without affecting unrelated processes
- trace messages live, at full or reduced speed or step-by-step. This could also be done offline, from the logs, but then the processes' data can't be accessed.
I will explore this path further, I think we can get more developer productivity gains from this kind of tooling than from the usual coding and debugging support.