Just Enough Software Architecture (2010)

https://www.georgefairbanks.com/book/

by teleforce • 2 years ago

327 173 2 years ago

georgefairbanks.com

Sakos• 2 years ago

So is this a good book? Are there any other software architecture books that are recommended reading?

hemantv• 2 years ago

Game Programming Patterns was one which had a big impact on me.

Other was Effective Engineer

vendiddy• 2 years ago

Is Game Programming Patterns relevant to those who are not building games?

smnplk• 2 years ago

Is GPP relevant if you don't want to do OOP ?

yashap• 2 years ago

Haven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.

jojohohanon• 2 years ago

I am very interested in learning more / honing my design skills,

But

Like everyone else my time is extremely limited. Could you say a few words about DDD stood out for you and what other books you might compare it to?

globular-toast• 2 years ago

One of my favourite books. Some people seem to prefer "Implementing Domain-Driven Design" by Vaughn Vernon. I have both on my shelf but I've never been able to read much of the latter.

Clean Architecture by Robert C. Martin has a lot of the same stuff distilled into more general rules that would apply to all software, not just "business" software. It's a good book but overall I prefer DDD.

mbb702• 2 years ago

Designing Data-Intensive Applications by Martin Kleppmann. It's my "this is the book I wish I read when I started programming"

adamors• 2 years ago

When you started? I mean it’s a good book but it would be wasted on beginners.

pragmatic• 2 years ago

We’re about due for a new edition with some updates. I read it again just recently and in certain sections I would love some updates. Many things have changed in 7 years.

JackMorgan3• 2 years ago

An absolutely excellent book! I learned so much going through it slowly with a reading group I started at my job.

notduncansmith• 2 years ago

I read this book in the first few years of programming professionally, and in my naïveté I was so eager to apply the patterns therein I missed out on many opportunities to write simple, straightforward code. In some ways it really hindered my career.

I don’t blame this on the book, of course; ultimately the intuition it helped me build has been very helpful in my work. With that said, as a particular type of feisty and eager young programmer at the time, I can now say I would have benefitted at least as much from a book titled “Designing Data-Unintensive Applications” :)

mehagar• 2 years ago

Clean Architecture and Fundamentals of Software Architecture: An Engineering Approach.

GiorgioG• 2 years ago

Ugh enough with clean architecture. So much boilerplate. Uncle Bob please retire.

srid• 2 years ago

Juval's "Righting Software" comes to mind.

In particular, this article "Volatility-Based Decomposition" is a good introduction:

https://www.informit.com/articles/article.aspx?p=2995357&seq...

(Note the electricity analogy)

ChrisMarshallNY• 2 years ago

Writing Solid Code, from 30 years ago, by Steve Maguire, was a watershed, for me.

Many of the techniques, therein, are now standard practice.

It also espoused a basic philosophy of Quality, which doesn’t seem to have aged as well.

throwaway81523• 2 years ago

AOSA, https://aosabook.org/en/index.html is good. Also, study the code of lots of different systems.

JackMorgan3• 2 years ago

I learned a lot about good software design from Structure and Interpretation of Computer Programs. It's free and has 350+ exercises. I just committed to doing one a day for a year.

I learned so much from that book it's like I aged ten years in that one year. Revolutionary for me.

I also loved

- Designing Data-Intensive Applications

- Design Of Everyday Things

I've got a list of other influential books with my thoughts here:

https://deliberate-software.com/page/books/

My controversial takes are that the whole series of Domain Driven Design books are pretty poor. I've seen several teams fall into a mud pit of endless meetings arguing about entities vs repositories. Same thing with Righting Software. The books are all filled with vague statements so everyone just spends all this time debating what they mean. It turns teams from thinking critically into religious bickering. Same for all the design patterns books.

matt_lo• 2 years ago

Great book. I think it’s more ideal for folks who solution design day-to-day. Better when you have experiences to relate back with.

gfairbanks12• 2 years ago

Better when you have experiences to relate back with.

100% this. I've been teaching software design since the 1990's and it's so much easier when the audience has enough experience that I can wave my hands and say "you know when things go like this ... ?" and they do, and then we can get on with how to think about it and do better.

Without that, it's tedious. Folks with less experience have the brainpower to understand but not the context. I try to create the context with a synthetic example, but (again, waving hands...) you know how much richness your current system has compared to any example I can put on a page or a slide.

pbnjay2• 2 years ago

Published in 2010? Curious how much of it has survived since then?

I like “Design It” because of some of the workshop/activities that are nice for technical folks who need to interact with stakeholders/clients (I’m in a consulting role so this is more relevant). Also it doesn’t lean hard on specific technical architectural styles which change so frequently…

zeroCalories3• 2 years ago

Process at my work is heavily influenced by this book, and I think it gives a pretty good overview of architecture and development processes. Author spends a lot of time in prose talking about mindset, and it's light on concrete skills, but it does provide references for further reading.

jeremyjh• 2 years ago

I can't think of many things that have changed in architecture since 2010. I'm not talking about fads but about actual principles.

CuriouslyC5• 2 years ago

Things are changing now, pretty fast. The architecture that is optimal for humans is not the same architecture that is optimal for AI. AI wants shallow monoliths built around function composition using a library of helper modules and simple services with dependency injection.

pbnjay2• 2 years ago

I mean shared hosting certainly existed but "the cloud" as we think of it today was much simpler and not nearly as ubiquitous. It doesn't really change the principles themselves but it certainly affects aspects of the risk calculus that dominates the table of contents.

zmmmmm• 2 years ago

probably containerisation is a big one, and also serverless computing

they aren't principles as such, but they certainly play into what is important and how you apply them

kqr• 2 years ago

Since 1970, to be fair... The people at the NATO Software Engineering conferences of '68 and '69 knew quite a bit about architecture. Parnas, my house-god in the area, published his best stuff in the 1970s.

gfairbanks12• 2 years ago

Keeling's Design It book is great [1]. It helps teams engage with architecture ideas with concrete activities that end up illuminating what's important. My book tries to address those big ideas head-on, which turns out to be difficult, pedagogically, because it's such an abstract topic.

Which ideas have survived since 2010?

Some operating systems are microkernels, others are monolithic. Some databases are relational, others are document-centric. Some applications are client-server, others are peer-to-peer. These distinctions are probably eternal and if you come back in 100 years you may find systems with those designs even though Windows, Oracle, and Salesforce are long-gone examples. And we'll still be talking about qualities like modifiability and latency.

The field of software architecture is about identifying these eternal abstractions. See [2] for a compact description.

"ABSTRACT: Software architecture is a set of abstractions that helps you reason about the software you plan to build, or have already built. Our field has had small abstractions for a long time now, but it has taken decades to accumulate larger abstractions, including quality attributes, information hiding, components and connectors, multiple views, and architectural styles. When we design systems, we weave these abstractions together, preserving a chain of intentionality, so that the systems we design do what we want. Twenty years ago, in this magazine, Martin Fowler published the influential essay “Who Needs an Architect?” It’s time for developers to take another look at software architecture and see it as a set of abstractions that helps them reason about software."

[1] Michael Keeling, Design It: From Programmer to Software Architect, https://pragprog.com/titles/mkdsa/design-it/

[2] George Fairbanks, Software Architecture is a Set of Abstractions Jul 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...

rowls66• 2 years ago

I found 'A Philosophy of Software Design' by John Ousterhout to be useful. It contains alot of solid easy to understand advice with many examples.

gchaincl• 2 years ago

Great book, I've learnt a lot from it

evmar• 2 years ago

I don't know this book in particular, but I know the author from their writing about "Intellectual Control", which is extremely insightful:

https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...

chanux2• 2 years ago

Good read. Thanks for sharing.

I feel that this article goes really well with it.

https://johnwhiles.com/posts/programming-as-theory

gfairbanks12• 2 years ago

Some folks read Peter Naur's Programming as Theory Building [1] and become zealots. I'm that kind of person. His ideas are woven through my recent talks [2]. Via years of essays, I've been building to a vision of how to build software that I'm calling Continuous Design that's partly stitched together in this overview [3].

[1] Gwern on Peter Naur's Programming as Theory Building, which includes Naur's essay and related comments. https://gwern.net/doc/philosophy/epistemology/index#naur-198...

[2] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

[3] Continuous Design, https://www.georgefairbanks.com/ieee-continuous-design/

ysofunny2• 2 years ago

software architecture is like regular architecture but civil engineering does not exist because there hasn't been an Isaac Newton of software. I'd say the closest so far is Claude Shannon

nine_k2• 2 years ago

While I agree with the general idea of your comparison, I must note that traditional architecture also involves a lot of deliberation and choices not dictated by formulas. Say, the Westminster Palace certainly involves some bits of civil engineering proper, but its defining features (the ornate texture, the iconic clock tower, the internal layout) are dictated mostly by functional and aesthetic choices.

Same applies to much of software.

JackMorgan3• 2 years ago

No software engineering practice, architecture, language, or tooling is known to be more effective because we don't even have units of measurement. We are still in the "hope it doesn't fall down" stage of software engineering.

This has profound effects for self reported productively.

For example, biking feels faster than driving 30mph with the windows up down a small suburban road with lots of stop signs. But typically the driver will still get 20 blocks away much much faster.

However if we had no units of measurement, everyone would be arguing the bike was faster.

This is where we are with software engineering.

viraptor5• 2 years ago

Also: We don't repeat the same thing enough times in the open to be able to compare. The things we do repeat stay private.

The only companies that really have enough data are the consulting giants. And they have enough perverse incentives that I would be extremely sceptical of their data.

danielovichdk• 2 years ago

Great analogy with the bike and car. I will use that in the future

dgb232• 2 years ago

We have or rather could have data and metrics. We just tend to ignore them outside of specific domains.

For example, from glancing at this summary and table of contents, it seems like there’s no to little mention of performance metrics. What is architecture good for if it doesn’t account for what the computer actually does?

Even in terms of development productivity or UI: why don’t we have mathematical models to decribe the mental stack one needs to develop, change, extend and more importantly use software?

Why are compute resources (human or machine) rarely a consideration when they have a real, measurable impact on interacting with software as developers or users?

gfairbanks12• 2 years ago

it seems like there’s no to little mention of performance metrics.

The book uses the jargon from the architecture community. Chapter 12 section 11 on Quality Attribute Scenarios is what you're looking for. But [1] seems to be a summary of Michael Keeling's treatment on qualities and scenarios, which I like better.

My thinking on this has been greatly influenced by Titus Winters who I've been teaching with in Google for the past couple years. He's tied together the ideas of quality attribute scenarios, compile-time tests, monitored metrics, and alerts in a way that is, in hindsight, completely obvious but I've not seen elsewhere. Maybe we can get him to write that up as an essay.

[1] https://dev.to/frosnerd/quality-attributes-in-software-1ha9

[2] Titus Winters, Design is Testability, May 8 2024. https://on.acm.org/t/design-is-testability/3038 (note: video doesn't seem to be posted yet)

jillesvangurp• 2 years ago

This is actually the whole mistaken premise that underlies the notion of software architecture and design. Building software is not at all like building a bridge or a sky scraper. It's more similar to designing those.

With big architecture projects you first design them and then build them. This is a lot of work. You have to think about everything, run simulations, engage with stakeholders, figure out requirements and other constraints, think about material cost, weight, etc. Months/years can be lost with big construction projects just coming up with the designs. The result is a super detailed blueprint that covers pretty much all aspects of building the thing.

It's a lot like building software, actually. These design projects have a high degree of uncertainty, risk, etc. But it's better than finding out that it's all wrong before you start building and using massive amounts of people, concrete, steel, and other expensive resources. But when have you ever heard an architect talk about making a design for their design to mitigate this? It's not a thing. There might have been a sketch or a napkin drawing at some point at best. SpaceX has introduced some agile elements into their engineering, which is something they learned from software development.

With software, your finished blueprint is executable. The process of coming up with one is manual, the process of building software from the blueprint is typically automated (using compilers and other tools) and so cheap software developers do it all the time (which wasn't always the case). The process of creating that executable blueprint has a lot of risks of course. And there might be some napkin/whiteboard designs here and there. But the notion that you first do a full design and then a full implementation (aka. waterfall) was never a thing that worked in software either. With few exceptions, there generally are no blueprints for your blueprint.

Read the original paper on Waterfall by Royce. It doesn't actually mention waterfalls at all and it vaguely suggests iterating might be a good idea (or at least doing things more than once). He fully got that the first design was probably going to be wrong. Agile just optimized away the low value step of creating designs for your blueprints that becomes apparent when you iterate a lot.

xhevahir• 2 years ago

"Risk-dependent" would be a much better name for this methodology. (Why are programmers so fond of this "[X]-driven" phrase?)

canadaduane• 2 years ago

Personally, I've always thought of "X-driven" as a mechanically derived metaphor. This shaft drives that gear, which drives that wheel, etc. It's a short form for "what is the most powerful mechanism of this complex thought machinery".

breadwinner• 2 years ago

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_k2• 2 years 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.

flowerlad2• 2 years ago

Over engineering is the result when you focus too much on “future” needs.

serial_dev4• 2 years 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.

j45• 2 years 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• 2 years ago

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

flowerlad2• 2 years ago

Good architecture reduces cost of achieving quality.

CraigJPerry• 2 years 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.

banish-m42• 2 years ago

The category is nonfunctional requirements.

banish-m42• 2 years 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.

gfairbanks12• 2 years 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/

[2] Keeling and Runde, Agile2018 Conference. Share the Load: Distribute Design Authority with Architecture Decision Records. https://web.archive.org/web/20210513150449/https://www.agile...

gfairbanks12• 2 years 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_Soft...

jefffoster• 2 years ago

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

gfairbanks12• 2 years 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-20...

bjt• 2 years ago

We did a book club on this at work a few years back. I found it extremely repetitive.

refibrillator• 2 years ago

project management risks: “Lead developer hit by bus”
software engineering risks: “The server may not scale to 1000 users”
You should distinguish them because engineering techniques rarely solve management risks, and vice versa.

It's not so rare in my experience. Code quality and organization, tests and documentation, using standard and well known tools - all of those would help both sides here.

That's why I've had to invoke the "hit by bus" hypothetical so many times in my career with colleagues and bosses, because it's a forcing function for reproducible and understandable software.

Pro tip: use "win the lottery" instead to avoid the negative connotation of injury or death.

ollien• 2 years ago

I've heard that positive spin responded to with "this company is my biggest investment, I'm not going anywhere" :)

ajanuary• 2 years ago

Pro tip: use "win the lottery" instead to avoid the negative connotation of injury or death.

I very much appreciate the attempt to reframe it positively. But personally, if I win the lottery, I’m still doing a handover. The key thing with “hit by a bus” is, no matter what your personality, you don’t have any time to prepare. Thats why you’ve got to get the information out there today. Unfortunately I’ve yet to find a positive spin that has those same connotations.

devsda• 2 years ago

Depends on the other person, but "gets hit by a bus or abducted by aliens" or some other (movie) trope doesn't sound too bad if it's an informal discussion.

cryptonector• 2 years ago

"Key person risk" captures all the possibilities.

arendtio• 2 years ago

But personally, if I win the lottery, I’m still doing a handover.

I wonder why we talk about such rare events. People get sick, and burnout is very common, too. Some people look for a new job, and when they find it, they call in sick just to not have to handle all the stress of their old job.

There are plenty of more likely examples of not having a handover.

crabmusket• 2 years ago

"Taken by the Rapture"?

DanHulton• 2 years ago

"Doing a handover" won't save a lot of companies. There's no level of "handover" that will save some of the shops I've been in, that just 100% rely on one team member to handle _everything._ Even if they took a _month_ to try to pass along along their accumulated knowledge, there's ingrained engineering practices and processes that all boil down to "Go ask Chris."

Honestly, I'd say that if you're able to do a handover in two weeks, and that covers everything it needs to cover? Well, then probably the handover isn't _actually_ necessary, and anything you cover in those two weeks could probably be figured out by a reasonably competent teammate. Knowledge is rarely the issue, being a person-shaped load-bearing component for your team _is._

(But also, good on you for taking a bit of time to make sure your old co-workers aren't left in the lurch. It probably also gives a bit of time to consider what you _really_ want to do with the winnings, so as not to blow it all in the first year like a lot of lottery winners do.)

coldtea3• 2 years ago

But personally, if I win the lottery, I’m still doing a handover.

How much time are you devoting to it? Enough for the project to ship, which could take months or a year, or merely enough to hastily give some other devs a breakdown of the thing, and "so long suckers" / hope for the best?

And, while you might (still do a handover), would others?

ijidak• 2 years ago

- Kidnapped to paradise

- Abducted by beautiful aliens

RadiozRadioz• 2 years ago

I don't like "win the lottery" because it implies that the sole reason for the person staying is money; it devalues their loyalty to the team.

Everyone's working for money in reality of course, but to me it doesn't feel team-spirited to call it out.

euroderf• 2 years ago

Good documentation will commit as much as possible to paper: to turn the implicit into the explicit. But then ya gotta keep it up to date.

foooorsyth• 2 years ago

“Win the lottery” doesn’t really work in tech. So many mid career engineers are deca-millionaires with 15-20 years of grants and refreshers. They’re working because they enjoy the work.

Even at “regular” companies that don’t have hockey stick stock graphs, lots of the senior engineering staff are quite well off by their 40s. One of my division leads sold his last startup for 10s of millions of dollars. He still send emails late on Friday nights.

IshKebab• 2 years ago

Maybe in silicon valley. Not in the vast majority of the tech world.

Scarblac• 2 years ago

It's happened twice now during my career that important colleagues were literally hit by buses.

And both were back to work in about a week.

I need a different standard example disaster.

gofreddygo• 2 years ago

  > Pro tip: use "win the lottery" instead to avoid the negative connotation of injury or death.

Win the lottery is still quite an euphemism for a more common outcome - getting laid off.

I use "the next person" more often to drive the point.

And there's the worse situation of "burnout" where you still have headcount but they've mentally checked out.

skeeter20203• 2 years ago

How about "takes a 3 week vacation"? I've seen lots of companies that can't survive that let alone a permanent departure. Or "increase bus count" which refers to removing a single point of failure and focuses on the motivation vs the cause of why you're in trouble. If you were doing root cause analysis you shouldn't stop at "because Larry got hit by a bus / won the lottery" because that's not the issue.

rixed• 2 years ago

using standard and well known tools - all of those would help both sides here.

What if standard tools become unnecessarily complicated and are poorly designed ?

__rito__• 2 years ago

Is this a good resource for someone starting a non-trivial OSS? Or something a solopreneur will derive value from? Can you suggest me some books/other resources that will be of value to solo developers?

revskill• 2 years ago

I'm tired of reading "arbitrary terms" to try to standardize something seems to subjective.

Give me the mathematical model and that's it. No more vague, human-created terms to try to translate your own ideas, that's just a hack.

b1ld5ch1rm5por7• 2 years ago

Within my prior company they circulated this "Software Architecture for Developers" book by Simon Brown: https://leanpub.com/b/software-architecture.

It's still on my reading list, though. I've moved on from that company. But it came highly recommended, because they also documented their architecture with the C4 model.

Has anyone here read it?

gfairbanks12• 2 years ago

Simon Brown is another person who has done a far better job than me of "democratizing" software architecture for developers. His talks [1] and workshops on architecture are exceptionally effective and his C4 architecture modeling language [2] is getting real traction.

I have youtube videos too [3] but they aren't as effective.

[1] https://www.youtube.com/results?search_query=simon+brown+arc...

[2] https://c4model.com/

[3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...

RcouF1uZ4gsC• 2 years ago

“Bus factor” in my mind is one of ways engineers self-sabotage.

How much are they paying the CEO?

Don’t they consider their replacement costs in the hundreds of millions.

MBA management types strive to convince everyone they are irreplaceable.

Engineers proudly talk about how they are easily replaceable.

Guess who gets shit on?

It is actually good that losing engineering talent be extremely painful for a company. This helps prevent the slow loss of engineering culture like what happened at Boeing.

Just Enough Software Architecture (2010)

Related Stories