> "How to organize software" I have recently had the thought that this is mostly what software architecture is...at some level. It's about where we draw the b

> "How to organize software" I have recently had the thought that this is mostly what software architecture is...at some level. It's about where we draw the boundaries around code to make it easy for humans to understand. Imagine taking an existing repo, and extracting every block of code into a function, and then moving them into their own separate file in one big folder. You could extend it to all the libraries of your code, and of those services we communicate with over the network too. This would look a bit like a debugger symbol table. It's closer to how the computer understands the program. The app still runs. It's just hard for people to understand what is going on. Software architecture is simply the grouping of these functions to some extent. It's not a foolproof analogy, because there are some decisions to be made about implementation details of things, but at some level of abstraction you would find the same operations need to be run. Just an interesting thought. > The question of how to architect such software is still an open one. I find a problem we face with architecture discussions is that its always about tradeoffs that are not immediately apparent. And it takes a lot of mental effort to remember why something is a bad idea. The way we discuss it is limited by plain text. It's hard to demonstrate a system evolving over time in a concise manner. Architecture should be evaluated by throwing a spec at it, and then changing every part of the spec (including adding perf requirements) and seeing how long it takes to make the changes, and how many bugs it has.