4 ms·

Architecture for architecture's sake is the worst thing you can do because it unnecessarily increases complexity. The ultimate goal of good architecture is cos

Architecture for architecture's sake is the worst thing you can do because it unnecessarily increases complexity. The ultimate goal of good architecture is cost reduction. If your architecture is causing you to spend more time developing and maintaining code then the architecture has failed.

nine_k 2y ago
Some architectures are very cheap to implement initially but are more expensive to maintain and evolve. Some are the other way around, require higher upfront expenses but allows to operate and evolve the product easier. It's always a balancing act. The corollary us that there is no one right architecture, the choice depends on circumstances, and should sometimes be re-evaluated. Another corollary is that flexibility is extra useful, because it allows to evolve and tweak the architecture to.some extent, maintaining its efficiency in changing circumstances.
- flowerlad 2y ago
  Over engineering is the result when you focus too much on “future” needs.
  - sverhagen 2y ago
    And under-engineering is the result when you don't sit down at the beginning of the project and plan for the known scope and requirements of that project. They are both bad ways to go about it. So, like the title says: "just enough", so not more, but also not less. It also doesn't always have to be a dedicated architect in a proverbial ivory tower. It can be an informal meeting of developers around a whiteboard. Don't get scared by the word "architecture".
    - mainde 2y ago
      While I agree that under-engineering can be a problem, it's generally very easy to fix by doing what's now clearly identified as missing/needed. Fixing over-engineering is always a nightmare and rarely a success. IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently. Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.
      - gfairbanks 2y ago
        > throw imaginary problems in the mix Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back. Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt. I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3]. [1] https://news.ycombinator.com/item?id=40616966#40624446 https://news.ycombinator.com/item?id=40616966#40624446 [2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1... [3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."
  - gfairbanks 2y ago
    In my own gut, I have a sense of the right amount of time to spend on design. Assume (falsely) for a moment that I'm right: How can I transfer that gut sense to you or anyone? Chapter 3 of the book is my attempt to share that gut feel [3]. Even if you clone us, our gut feel doesn't transfer to our clones. So, we can recognize under- and over-engineering in our guts, but how can we help someone else? Is there a better way than the risk-driven model? 1. Identify and prioritize risks 2. Select and apply a set of techniques 3. Evaluate risk reduction [1] JESA Chapter 3: Risk-Driven Model. https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
- serial_dev 2y ago
  It's not always a balancing act, it implies that everything has a good side and you just need to know what to focus on. It's not true, there are architectures that are a waste of time today, and a waste of time in 5 years, too.
  - SgtBastard 2y ago
    If that architecture has no value in any circumstances at the beginning of a project and no value once the code base has matured, it’s an anti pattern.
    - metaltyphoon 2y ago
      Most devs / architects which initially designed the system then to not stick around and find out if what they did actually worked.
- j45 2y ago
  Pre-mature optimization and over-engineering are a greater issue than the opposite. Generally, clever architecture at the right stages can beat clever code and leave flexibility to pivot.
javaunsafe2019 2y ago
The ultimate goal or SA is to fulfil the quality goals. Cost reduction can be one.
- flowerlad 2y ago
  Good architecture reduces cost of achieving quality.
- CraigJPerry 2y ago
  The goal of software architecture is >> cost reduction > fulfil the quality goals I’d word it as “keeping the cost of changing software low over the long term”. I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals. I don’t think you can say it’s just cost reduction, but that is closer. It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.
  - gfairbanks 2y ago
    For typical web / IT systems I largely agree with focusing on modifiability as a heuristic because on those kinds of systems it's typically the biggest risk. But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks. Meta-commentary: This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems. Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.
- banish-m4 2y ago
  The category is nonfunctional requirements.
banish-m4 2y ago
Big grand architecture invariably leads to an elitism culture where there are overpaid technical architects who don't do much but insist on terrible patterns for software engineers to solve under unreasonable constraints including deadlines.
- gfairbanks 2y ago
  One of my main goals with the book was to "democratize" architecture, to make it accessible and relevant to every developer. As the cover blurb says: "It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects." In hindsight, my book hasn't been very good at that but perhaps it was a stepping stone on the path. Michael Keeling's book Design It: From Programmer to Software Architect does a better job of saying how developers can engage with architecture ideas. I'm a personal friend of his and a huge fan of his work. His experience report [2] on how to democratize architecture is what I aspire to do. [1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/ https://pragprog.com/titles/mkdsa/design-it/ [2] Keeling and Runde, Agile2018 Conference. Share the Load: Distribute Design Authority with Architecture Decision Records. https://web.archive.org/web/20210513150449/https://www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/ https://web.archive.org/web/20210513150449/https://www.agile...
gfairbanks 2y ago
How much architecture is enough? Chapter 3 Risk-Driven Model [1] guides you to do as little architecture as possible. It says: "The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?” The risk-driven model can be summarized in three steps: 1. Identify and prioritize risks 2. Select and apply a set of techniques 3. Evaluate risk reduction You do not want to waste time on low-impact techniques, nor do you want to ignore project-threatening risks. You want to build successful systems by taking a path that spends your time most effectively. That means addressing risks by applying architecture and design techniques but only when they are motivated by risks." An example of "architecture" is using the Client-Server style, where servers never take initiative and simply respond to client requests. That might be a good or bad fit to the problem. [1] https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
jefffoster 2y ago
Not just cost reduction but allowing more investment. A good architecture can enable more people to work on your product.
- gfairbanks 2y ago
  Agreed. See: Scale Your Team Horizontally [1]. "I’m not ready to argue against Brooks’ Law that adding people to a late project makes it later. But today, when developers are working on a clean codebase, I see lots of work happening in parallel with tool support to facilitate coordination. When things are going smoothly, it’s because the architecture is largely set, the design patterns provide guidance for most issues that arise, and the code itself (with README files alongside) allow developers to answer their own questions." [1] Scale Your Team Horizontally, George Fairbanks, IEEE Software July 2019. https://www.georgefairbanks.com/ieee-software-v36-n4-july-2019-scale-your-team-horizontally https://www.georgefairbanks.com/ieee-software-v36-n4-july-20...

nine_k 2y ago

Some architectures are very cheap to implement initially but are more expensive to maintain and evolve. Some are the other way around, require higher upfront expenses but allows to operate and evolve the product easier. It's always a balancing act. The corollary us that there is no one right architecture, the choice depends on circumstances, and should sometimes be re-evaluated. Another corollary is that flexibility is extra useful, because it allows to evolve and tweak the architecture to.some extent, maintaining its efficiency in changing circumstances.

flowerlad 2y ago
Over engineering is the result when you focus too much on “future” needs.
- sverhagen 2y ago
  And under-engineering is the result when you don't sit down at the beginning of the project and plan for the known scope and requirements of that project. They are both bad ways to go about it. So, like the title says: "just enough", so not more, but also not less. It also doesn't always have to be a dedicated architect in a proverbial ivory tower. It can be an informal meeting of developers around a whiteboard. Don't get scared by the word "architecture".
  - mainde 2y ago
    While I agree that under-engineering can be a problem, it's generally very easy to fix by doing what's now clearly identified as missing/needed. Fixing over-engineering is always a nightmare and rarely a success. IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently. Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.
    - gfairbanks 2y ago
      > throw imaginary problems in the mix Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back. Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt. I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3]. [1] https://news.ycombinator.com/item?id=40616966#40624446 https://news.ycombinator.com/item?id=40616966#40624446 [2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1OAJv5H4jew https://www.computer.org/csdl/magazine/so/2023/04/10176187/1... [3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."
- gfairbanks 2y ago
  In my own gut, I have a sense of the right amount of time to spend on design. Assume (falsely) for a moment that I'm right: How can I transfer that gut sense to you or anyone? Chapter 3 of the book is my attempt to share that gut feel [3]. Even if you clone us, our gut feel doesn't transfer to our clones. So, we can recognize under- and over-engineering in our guts, but how can we help someone else? Is there a better way than the risk-driven model? 1. Identify and prioritize risks 2. Select and apply a set of techniques 3. Evaluate risk reduction [1] JESA Chapter 3: Risk-Driven Model. https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...
serial_dev 2y ago
It's not always a balancing act, it implies that everything has a good side and you just need to know what to focus on. It's not true, there are architectures that are a waste of time today, and a waste of time in 5 years, too.
- SgtBastard 2y ago
  If that architecture has no value in any circumstances at the beginning of a project and no value once the code base has matured, it’s an anti pattern.
  - metaltyphoon 2y ago
    Most devs / architects which initially designed the system then to not stick around and find out if what they did actually worked.
j45 2y ago
Pre-mature optimization and over-engineering are a greater issue than the opposite. Generally, clever architecture at the right stages can beat clever code and leave flexibility to pivot.

javaunsafe2019 2y ago

The ultimate goal or SA is to fulfil the quality goals. Cost reduction can be one.

flowerlad 2y ago
Good architecture reduces cost of achieving quality.
CraigJPerry 2y ago
The goal of software architecture is >> cost reduction > fulfil the quality goals I’d word it as “keeping the cost of changing software low over the long term”. I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals. I don’t think you can say it’s just cost reduction, but that is closer. It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.
- gfairbanks 2y ago
  For typical web / IT systems I largely agree with focusing on modifiability as a heuristic because on those kinds of systems it's typically the biggest risk. But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks. Meta-commentary: This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems. Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.
banish-m4 2y ago
The category is nonfunctional requirements.

banish-m4 2y ago

Big grand architecture invariably leads to an elitism culture where there are overpaid technical architects who don't do much but insist on terrible patterns for software engineers to solve under unreasonable constraints including deadlines.

gfairbanks 2y ago
One of my main goals with the book was to "democratize" architecture, to make it accessible and relevant to every developer. As the cover blurb says: "It democratizes architecture. You may have software architects at your organization — indeed, you may be one of them. Every architect I have met wishes that all developers understood architecture. They complain that developers do not understand why constraints exist and how seemingly small changes can affect a system’s properties. This book seeks to make architecture relevant to all software developers, not just architects." In hindsight, my book hasn't been very good at that but perhaps it was a stepping stone on the path. Michael Keeling's book Design It: From Programmer to Software Architect does a better job of saying how developers can engage with architecture ideas. I'm a personal friend of his and a huge fan of his work. His experience report [2] on how to democratize architecture is what I aspire to do. [1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/ https://pragprog.com/titles/mkdsa/design-it/ [2] Keeling and Runde, Agile2018 Conference. Share the Load: Distribute Design Authority with Architecture Decision Records. https://web.archive.org/web/20210513150449/https://www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/ https://web.archive.org/web/20210513150449/https://www.agile...

gfairbanks 2y ago

How much architecture is enough? Chapter 3 Risk-Driven Model [1] guides you to do as little architecture as possible. It says: "The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?” The risk-driven model can be summarized in three steps: 1. Identify and prioritize risks 2. Select and apply a set of techniques 3. Evaluate risk reduction You do not want to waste time on low-impact techniques, nor do you want to ignore project-threatening risks. You want to build successful systems by taking a path that spends your time most effectively. That means addressing risks by applying architecture and design techniques but only when they are motivated by risks." An example of "architecture" is using the Client-Server style, where servers never take initiative and simply respond to client requests. That might be a good or bad fit to the problem. [1] https://www.georgefairbanks.com/assets/jesa/Just_Enough_Software_Architecture__Fairbanks_2010-demo.pdf https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...

jefffoster 2y ago

Not just cost reduction but allowing more investment. A good architecture can enable more people to work on your product.

gfairbanks 2y ago
Agreed. See: Scale Your Team Horizontally [1]. "I’m not ready to argue against Brooks’ Law that adding people to a late project makes it later. But today, when developers are working on a clean codebase, I see lots of work happening in parallel with tool support to facilitate coordination. When things are going smoothly, it’s because the architecture is largely set, the design patterns provide guidance for most issues that arise, and the code itself (with README files alongside) allow developers to answer their own questions." [1] Scale Your Team Horizontally, George Fairbanks, IEEE Software July 2019. https://www.georgefairbanks.com/ieee-software-v36-n4-july-2019-scale-your-team-horizontally https://www.georgefairbanks.com/ieee-software-v36-n4-july-20...