31–39 of 39 posts
Take his advice with a grain... or perhaps a quarry's worth of salt. This guy has written plenty of books and articles about the "agile" dogma, but most crucially, nothing about any of the software that he wrote. These days, it's even more obvious as the contents of this page feel like something an LLM could've generated. If you want a "software architecture guide", you'd be better off examining software written by t…
Earlier quoted context omitted.
We sometimes point to ISO25010 [0] if management or not so experienced devs are asking. It contains a good deal of the relevant "qualities" you keep an eye on for quality. [0] https://iso25000.com/index.php/en/iso-25000-standards/iso-25...
That looks like a whole lot of dimensions to measure without providing any clear way of actually doing so. Which I guess is the point? But what do management or less experienced devs actually do with the information in the standard after they’ve read it?
I want to suggest good design solves the problems you know. In which case can we say good architecture ensures good software.
I say this as a user of and developer of small businesses solutions. I expect SaaS products to make my job easier. And I’m greatly disappointed when I learn they don’t understand my job and fixes are impossible/forever on the horizon.
Take his advice with a grain... or perhaps a quarry's worth of salt. This guy has written plenty of books and articles about the "agile" dogma, but most crucially, nothing about any of the software that he wrote. These days, it's even more obvious as the contents of this page feel like something an LLM could've generated. If you want a "software architecture guide", you'd be better off examining software written by t…
But for enterprise software architecture, that's a different level and has a very different approach, because it is most about business processes, not the actual construction of software.
It's about designing a framework for those processes that adapts to a business as it changes or expands or has to integrate new infrastructure, it's about isolation of customer data, ensuring regulatory compliance etc.
Those are all constraints on the design of the software, not so much actual computing and other infrastructure.
I design systems, and then I build them. Sometimes I revise parts of the design while we're working on it, because of changing circumstances or new insights. The whole idea of an upfront design that only lives on paper is somewhat alien to me.
Earlier quoted context omitted.
So what would be a good architecture? How would I recognize it if I stumbled against it? My own inclinations here are that it would be good to have as few different technologies as possible. To run things on as few different machines as possible and to have automated tests for everything. The thing is that as soon as there are multiple technologies you get to have different people specializing in them and it is alway…
Good architecture reduces cost, while still achieving business goals. (E.g. If you have problems hiring for a weird stack, it increases hiring cost; you have problems with dependency zoo maintenance it increases costs; if it took a year to build a framework that could've been a bash script, it increased the cost) Every other architecture “metric” should be useful/convenient proxy towards reducing overall cost.
If writing code is tactics and the end goal is strategy. Is architecture operations?
If writing code is tactics, architecture is strategy. The end goal is just the desired outcome.
Strategy would be the use software to achieve business goals.
Essentially why are we doing this at all.
Earlier quoted context omitted.
I'm Iranian
Ahh yeah. I'm so sorry about my government. :(