[chrisandchris]

Maybe it's just me, but I would never like to pay such an amount for a subscription of a service (they charge >300 if you use C#, as I do). I maybe want to analyze my architecture on this level a couple times a year. Why do I have to pay each month? I'm missing usage-based pricing today, everyone sticks everything into a subscription.

[danielvaughn]

Maybe on an individual level it wouldn't make sense. But for instance, in my current company we have a fairly complex distributed architecture that's difficult to grok for new engineers.

Their middle-tier pricing option is about $350/month, so if you spend more than ~4 developer hours per month documenting/explaining/analyzing your architecture, then you've saving money with their product.

We definitely spend more than that so it would make sense for us. However, I'd want to see it visualize the infrastructure as well (we use k8s and terraform so in theory this should be possible).

[pengaru]

> if you spend more than ~4 developer hours per month documenting/explaining/analyzing your architecture, then you've saving money with their product.

Except this is a false equivalence.

Not once have I documented something I was part of creating, in sufficient detail to explain it completely, without uncovering bugs/inconsistencies/oversights that otherwise would likely go unnoticed. Furthermore the practice refreshes the mental model in the minds of those documenting/explaining/analyzing, which otherwise atrophies and becomes out of sync with reality through the work of others.

[chrisandchris]

I don't think that would be my preferred use-case for visualizing code or infra. I would use it when looking for issues (like to tight coupling, recursion, ...) but not for documenting or similar.

Also, regarding architecture, why is more important than how (2nd law of software architecture, see Mark Richards), but such a tool especially provides the how and fails to explain the why at all - making it not a perfect for a software architect.

The difficulty in documenting code is not creating a diagram of it, but rather simplyfing the things enough so that one can understand it quite "fast" while not omitting important details. I'm fairly confident that this task requires some sort of intelligence a tool can only provide to some degree.

[bryanrasmussen]

Sounds like it would be useful for a company with consultants that work on other companies' solutions - for one.

But yeah >300 sounds like something that will have to come down to succeed.