3 ms·

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

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 3y ago
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 3y ago
  It is only dependency management.
victor106 3y ago
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 3y ago
  So this is visualizing software implementation then, as opposed to architecture?
  - junon 3y ago
    Yes, not sure why they're using the term "architecture" here. It's a code structure visualizer.
  - momirlan 3y ago
    Sure, architecture is the process of actively creating a blueprint, not passively rendering an existing piece of code.
- chrisjj 3y ago
  > 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.
nickdothutton 3y ago
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.
momirlan 3y ago
Very true. I would call this "code representation", not architecture. Architecture is a different discipline, at higher level than code.
gremlinunderway 3y ago
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.
ChrisMarshallNY 3y ago
I've found that architecture is an iterative process, in my experience. I write about it here: https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... I call it "Paving the Bare Spots": https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving 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.
j45 3y ago
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.

BoxFour 3y ago

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 3y ago
It is only dependency management.

victor106 3y ago

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 3y ago
So this is visualizing software implementation then, as opposed to architecture?
- junon 3y ago
  Yes, not sure why they're using the term "architecture" here. It's a code structure visualizer.
- momirlan 3y ago
  Sure, architecture is the process of actively creating a blueprint, not passively rendering an existing piece of code.
chrisjj 3y ago
> 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.

nickdothutton 3y ago

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.

momirlan 3y ago

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

gremlinunderway 3y ago

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.

ChrisMarshallNY 3y ago

I've found that architecture is an iterative process, in my experience. I write about it here: https://littlegreenviper.com/miscellany/forensic-design-documentation/ https://littlegreenviper.com/miscellany/forensic-design-docu... https://littlegreenviper.com/miscellany/evolutionary-design-specification/ https://littlegreenviper.com/miscellany/evolutionary-design-... I call it "Paving the Bare Spots": https://littlegreenviper.com/miscellany/the-road-most-traveled-by/#paving 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.

j45 3y ago

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.