I really liked this article. Very concise, clear, and I like the systematic thinking of “what are we really DOING here?”. If the author(s) read this: make sure

I really liked this article. Very concise, clear, and I like the systematic thinking of “what are we really DOING here?”. If the author(s) read this: make sure to define your acronyms in the TLDR up top, since it pops up first. Tiny thing but might help engagement rates - I almost clicked away thinking MVA was some business school concept, not knowing this was part of a series. I’ve been reading a lot of Kant recently and he has two ideas I think could be helpful to modern software engineering: 1. Using the word “architectonics” to describe the science of structures. Now it’s only used for the brain (Cytoarchitectonics) and some other small academic fields, sadly. I think that would be an awesome evolution for the slowly-outmoded agile coaches of the industry: “Architectonic consultants” or “architectonics”. 2. He thinks an important principle of Architectonics is not to just collect a bunch of components until you have a system that works, but rather to start with the top level, deduce the divisions within the structure that are necessary, and only then start filling in the details. In the practical world of engineering this isn’t always necessary, but I’ve found it really helpful, for the exact reasons discussed in this post (scoping, not getting ahead of yourself, allowing for growth without doing unnecessarily early work, etc)