However, this makes me wonder about the premise of this tool.
Have systems gotten so messy and complicated that we build them without knowing they're actually doing, until after they're built?
In other words, UML diagrams (including sequence diagrams) were intended ways to clarify and reason about systems during design time. This project seems like it could be a reverse engineering tool, but it isn't presented that way.
I can think of a few use cases that aren't really reverse engineering. Documenting legacy systems that weren't properly documented up front. Documenting/identifying divergence from design time documentation. Documenting a microservice stack where each service is individually well documented but the totality is not. Generating documentation from a prototype to use a starting point for a more structured design process.
Generally, I've seen very few projects that have architecture documentation which is kept up to date past the first release. So it's not an insane idea given the on the ground reality, but yes it does seem a bit like shutting the barn door after the horse is already out.
> Have systems gotten so messy and complicated that we build them without knowing they're actually doing, until after they're built?
Oh, hey, you've just practically described one popular implicit formulation of Agile. :)
Detailed and coherent design documentation is rare in my experience, even at organizations that are staffed at a level including dedicated staff ostensibly for this purpose. I can think of precisely one place I've worked for that had a design process that produced documentation effective for specifying the project ahead of time and as a reference from then on out. A culture committed to this plus dedicated technical writers who regularly met with a team of a domain expert, tech lead, and UX/UI folks for the purpose of producing project documentation helped a lot.
Other organizations may have had individuals producing documentation but it was a lossy process, magnified when they moved on from the project.
Working in secops, we aren't always the ones building the tools, and the products we're required to support never come with this kind of documentation.
Jeez Louise I worked with the Oracle BI stuff once and it was so poorly documented that using Wireshark was the only to figure out what all pieces did what and how it all worked. I'd imagine other such enterprisey stuff that's been hobbled together over the years through acquisitions may be similar and these companies are always rather terse or ask you to put in a ticket and wait a month to find out.
In 30 years of doing consulting on 'systems' work, it's astoundingly rare to see documentation of any sort that accurately & completely represents the current running state of the system. Sometimes it's close, but more often than not it's whatever was presented to get budget before any development has started.
Occasionally, the folks involved actually believe their doco does represent reality. They are invariably wrong, sometimes in small details, usually in large ones. Tools like this are an invaluable check on reality.
> Have systems gotten so messy and complicated that we build them without knowing they're actually doing, until after they're built?
Yes, in general, at least in my world (medium size to enterprise). Agile has made this in practice much much worse.
However, this makes me wonder about the premise of this tool.
Have systems gotten so messy and complicated that we build them without knowing they're actually doing, until after they're built?
In other words, UML diagrams (including sequence diagrams) were intended ways to clarify and reason about systems during design time. This project seems like it could be a reverse engineering tool, but it isn't presented that way.