[chrisjj]

This is hugely misguided. Architecture comes before implementation, not after. A tool that encourages a view of the structure of the implemenatation to be mistaken for architecture is a tool for failure.

Whatever next?? Make your code edits on source accurately generated from the binary?? :)

[BoxFour]

Software architecture is an ever-evolving aspect, especially in large companies where multiple teams may concurrently modify it without coordination.

As a simple example: Predicting the downstream impacts of updating a module from c++11 to c++20 can often be a tedious trial-and-error process. Having prior knowledge of potential effects is a valuable starting point.

Though this leans towards dependency management rather than pure architecture, in practice, the lines can blur.

[chrisjj]

It is only dependency management.

[ChrisMarshallNY]

I've found that architecture is an iterative process, in my experience.

I write about it here:

https://littlegreenviper.com/miscellany/forensic-design-docu...

https://littlegreenviper.com/miscellany/evolutionary-design-...

I call it "Paving the Bare Spots": https://littlegreenviper.com/miscellany/the-road-most-travel...

For myself, I think that firm architecture diagrams aren't very good. I think that we need the ability to generate one "on the fly," and this is kind of doing that. Not sure that this is the solution, but it's in the ball park.

[victor106]

No, it’s not.

In some places the implementation deviates from architecture and it’s useful to know if it did and how it did.

Also, not all projects have the time and money it takes to layout an architecture before actual implementation.

[nonethewiser]

So this is visualizing software implementation then, as opposed to architecture?

[junon]

Yes, not sure why they're using the term "architecture" here. It's a code structure visualizer.

[momirlan]

Sure, architecture is the process of actively creating a blueprint, not passively rendering an existing piece of code.

[chrisjj]

> not all projects have the time and money it takes to layout an architecture before actual implementation.

IME that kind of project gains nothing from adding it after.

[momirlan]

Very true. I would call this "code representation", not architecture. Architecture is a different discipline, at higher level than code.

[gremlinunderway]

Not every project is a greenfield project. Very often you're inheriting a huge codebase of legacy production code, so you also need to account for that in your architecture as well.

Or at least you should account for that. I work with a dev team that is supposed to own a huge legacy codebase that we're dependent on a daily basis for using, but they are working on an entire new greenfield replacement and refuse to do any changes to it. Thanks guys, really glad you get to go off and have fun with new tech while I'm stuck in the stone ages.

[j45]

In domains that are understood, clever architecture often will beat clever coding, or avoid many headaches altogether.

In unknown domains that are learning their way, writing less code and complexity and not more.

[nickdothutton]

Sometimes I need to know that the architecture I requested/described is indeed the architecture I got from the development team. I often don't have the time to check the code.