A curated list of books on Software Architecture(github.com)
github.com
A curated list of books on Software Architecture
https://github.com/mhadidg/software-architecture-books
59 comments
Ty for that :P
Anymore recommendations?! I read(not entirely) the cosmic python one from Percival and loved.
Anymore recommendations?! I read(not entirely) the cosmic python one from Percival and loved.
That's a great and pragmatic suggestion.
Pragmatic as in these are not generic solutions/patterns but actual working architectures.
Thanks.
Pragmatic as in these are not generic solutions/patterns but actual working architectures.
Thanks.
I'm currently reading Marianne Bellotti's Kill It With Fire, which is about upgrading and maintaining legacy projects. It's more about meta-software-architecture (how to think about choosing and replacing architectures) than about software architecture itself.
It's very well written and full of useful insights for practitioners, while using language and descriptions that would be approachable to the layperson. This seems like a book that an engineering manager and a product owner can read together to better understand the shared endeavour of upgrading a legacy service.
Halfway through Chapter 3, I haven't learned anything I didn't know... but on the other hand, I find myself in violent agreement with each one of the author's points. And though it's a book that's well written and could be a breezy read, I find myself stopping to ponder on he consequences of each paragraph.
One great aspect of this book is that Bellotti was trained as anthropologist, and she brings the analytical tools of her studies to the human aspects of software development. The book offers a vocabulary/framework for the software development process, legacy or not, and better models for framing our own professional experiences when approaching client work.
Heartily recommended.
It's very well written and full of useful insights for practitioners, while using language and descriptions that would be approachable to the layperson. This seems like a book that an engineering manager and a product owner can read together to better understand the shared endeavour of upgrading a legacy service.
Halfway through Chapter 3, I haven't learned anything I didn't know... but on the other hand, I find myself in violent agreement with each one of the author's points. And though it's a book that's well written and could be a breezy read, I find myself stopping to ponder on he consequences of each paragraph.
One great aspect of this book is that Bellotti was trained as anthropologist, and she brings the analytical tools of her studies to the human aspects of software development. The book offers a vocabulary/framework for the software development process, legacy or not, and better models for framing our own professional experiences when approaching client work.
Heartily recommended.
Can I be the "lazy person" and ask which are the author's points?!
> Can I be the "lazy person" and ask which are the author's points?!
Yes, you can, and I can be the hurried person with no time to summarise, and recommend you read the book yourself. It's not like those business books that have a single thesis, backed by 100 examples to support it, where the thesis itself can be written on the back of a stamp.
I can however try and describe to you what the book is about.
It's a book about how legacy software interventions are about the people as much as about the code and the machines, with advice for aligning incentives between stakeholders, developers and managers,
It's about prioritising competing goals under different sets of constraints, with useful advice for ensuring psychological safety in your team.
It's about measuring risk, and acting on the measurements.
It's about anthropology of software-using organisations, and about organisational design, and how those disciplines inform the job of recovering wayward software projects. It's not a book about computers, or about programming, or even about software management. It's about people in organisations doing all of the above.
It's about defining the right job to do lest you attempt to do the wrong job right.
It reads like an instant classic, like a "missing manual" for running software development operations in big organisations... but with advice that's also applicable at smaller scales.
I just finished reading it and I started on Chapter 1 again. It's that good.
Yes, you can, and I can be the hurried person with no time to summarise, and recommend you read the book yourself. It's not like those business books that have a single thesis, backed by 100 examples to support it, where the thesis itself can be written on the back of a stamp.
I can however try and describe to you what the book is about.
It's a book about how legacy software interventions are about the people as much as about the code and the machines, with advice for aligning incentives between stakeholders, developers and managers,
It's about prioritising competing goals under different sets of constraints, with useful advice for ensuring psychological safety in your team.
It's about measuring risk, and acting on the measurements.
It's about anthropology of software-using organisations, and about organisational design, and how those disciplines inform the job of recovering wayward software projects. It's not a book about computers, or about programming, or even about software management. It's about people in organisations doing all of the above.
It's about defining the right job to do lest you attempt to do the wrong job right.
It reads like an instant classic, like a "missing manual" for running software development operations in big organisations... but with advice that's also applicable at smaller scales.
I just finished reading it and I started on Chapter 1 again. It's that good.
I don't know if it is just me who finds such lists overwhelming. They bombard on you like hundreds of resources.
FOMO kicks in and I star them for false sense of effectiveness but hardly end up completing anything or even starting.
When I first started learning software I liked to 'collect' these kind of lists as educational busywork. Now that I've been learning software engineering for over 6 years I think they're super unhelpfully overwhelming like you say. You want _one_ short list that you actually use.
For me that is teachyourselfcs.com. It recommends only two books if you don't have "multiple years" to self-study part-time. They are: Computer Systems: A Programmer's Perspective and Designing Data-Intensive Applications. If you do have multiple years it recommends ~9 books. The OP list has almost 100 books just on software architecture.
It takes so long to read one good textbook that I'd bet 90% of software engineers haven't read more than three or four cover-to-cover. I was rare in my computing theory class for actually using the textbook and doing the exercises and I only got 2/3 through. Given my current progress rate through 'Computer Systems: A Programmer's Perspective' it will take me at least 150 hours to complete.
For me that is teachyourselfcs.com. It recommends only two books if you don't have "multiple years" to self-study part-time. They are: Computer Systems: A Programmer's Perspective and Designing Data-Intensive Applications. If you do have multiple years it recommends ~9 books. The OP list has almost 100 books just on software architecture.
It takes so long to read one good textbook that I'd bet 90% of software engineers haven't read more than three or four cover-to-cover. I was rare in my computing theory class for actually using the textbook and doing the exercises and I only got 2/3 through. Given my current progress rate through 'Computer Systems: A Programmer's Perspective' it will take me at least 150 hours to complete.
Thanks for this recommendation. I agree with you about quality over quantity. Working through a ~600-page (sometimes more) technical book is no easy task, and in fact can be pretty demotivating especially if you're learning on your own.
I feel like some people are compelled to gather these monster lists due to their hoarding inclinations---and it probably serves as "useful" procrastination as well. As I get older and curate my bookshelf further, I find myself either discarding a lot of overlapped material or skipping through the majority of the content. Otherwise there is no escape, as the SE field is so dynamic and complex, that the list of "required readings" trully is overwhelmingly large.
I feel like some people are compelled to gather these monster lists due to their hoarding inclinations---and it probably serves as "useful" procrastination as well. As I get older and curate my bookshelf further, I find myself either discarding a lot of overlapped material or skipping through the majority of the content. Otherwise there is no escape, as the SE field is so dynamic and complex, that the list of "required readings" trully is overwhelmingly large.
On the other hand it is different for collecting interesting and influential papers and essays. You read them in an afternoon and ponder over them for quite a while! Then you revisit them way, maybe years, later again.
But yes, you don‘t need more than one good introductory book on architecture, most of the books listed don’t have anything to do with architecture anyways, but rather software culture.
Maybe you don’t need to read one at all, but rather a paper from someone who analyzed or created a piece of software with interesting and useful architecture.
But yes, you don‘t need more than one good introductory book on architecture, most of the books listed don’t have anything to do with architecture anyways, but rather software culture.
Maybe you don’t need to read one at all, but rather a paper from someone who analyzed or created a piece of software with interesting and useful architecture.
One afternoon? Hm, it depends on the paper really and how close it is to your daily work.
2 pages in FoundationDB paper (https://www.foundationdb.org/files/fdb-paper.pdf) I knew I was looking at one month's reading material if I really was to grasp everything. It'd be much easier if I worked with DBs and Distributed daily but I don't.
But, yes, I see your point.
2 pages in FoundationDB paper (https://www.foundationdb.org/files/fdb-paper.pdf) I knew I was looking at one month's reading material if I really was to grasp everything. It'd be much easier if I worked with DBs and Distributed daily but I don't.
But, yes, I see your point.
Totally agree about papers and essays and revisiting them years later. I built a website based directly on that idea. https://whitelist.sh. It’s almost finished. Just need to reorder some items in the list.
That looks pretty cool! But I meant papers and essays from the likes of Edsger Dijsktra, Gerald Sussman, Alan Kay, Joe Armstrong, Daniel Ingalls, Peter Naur, Tony Hoare, Niklaus Wirth, Betrand Meyer, John McCarthy... and many, many others[0], including ones that are not necessarily as known but have discovered deep and useful insights into programming and computers.
Blog articles are really useful too, especially if they concentrate on say something more specifically practical that doesn't warrant the same polish and rigor of a paper or essay. Also something I noticed is that many, who will make more general assertions in these articles, are typically echoing something that has been written down by researchers quite a while ago, so why not go to the source?
[0] Apparently I can't stop writing down names because it feels like I'm leaving out too many...
Blog articles are really useful too, especially if they concentrate on say something more specifically practical that doesn't warrant the same polish and rigor of a paper or essay. Also something I noticed is that many, who will make more general assertions in these articles, are typically echoing something that has been written down by researchers quite a while ago, so why not go to the source?
[0] Apparently I can't stop writing down names because it feels like I'm leaving out too many...
> But I meant papers and essays from the likes of ...
Oh they're all in there! They're just put at the back end of the 4 years partly because the more advanced content goes towards the end and partly because I haven't distributed everything properly.
I've spent quite a few hours curating the ~800 items and have in that process learnt a few new names that you mentioned, such as Niklaus Wirth. From him, the list has "Good Ideas, Through The Looking Glass".
I don't recognize Daniel Ingalls and Peter Naur so I'll look into them and consider adding them to the list. Cheers :)
Edit: Oh, Peter Naur would be the Naur in Backus-Naur form. He'd be in there.
Oh they're all in there! They're just put at the back end of the 4 years partly because the more advanced content goes towards the end and partly because I haven't distributed everything properly.
I've spent quite a few hours curating the ~800 items and have in that process learnt a few new names that you mentioned, such as Niklaus Wirth. From him, the list has "Good Ideas, Through The Looking Glass".
I don't recognize Daniel Ingalls and Peter Naur so I'll look into them and consider adding them to the list. Cheers :)
Edit: Oh, Peter Naur would be the Naur in Backus-Naur form. He'd be in there.
It takes month to go through a technical book cover to cover, except if you have already learnd the content before then you can read it rather quickly like a novel. But if you know then content why read it.
Here are my four: Designing Data Intensive Applications, the Google SRE book, High Performance Browser Networking, and Effective Python.
https://notes.eatonphil.com/books-developers-should-read.htm...
https://notes.eatonphil.com/books-developers-should-read.htm...
I love Fluent Python, Luciano is a great professor and writer, also is a Brazilian (even more points for being a countryman)
It's fairly low effort curation based off public reviews of books. The problem with such things is that it's hard to gauge the quality of review or the subject matter expertise of the reviewer. Curation should ideally be performed by someone who is an expert in the field, has deep knowledge on the subjects and has actually consumed the content in order to make the judgement call on whether it passes the bar or not. Otherwise, it's nothing more than a listing of most popular books.
There ought to be a rule that any "curated" list of N books should also include N books not to read in the same category
An example of following a similar rule (briefly list other standard books and why the recommended books are preferred): https://www.lesswrong.com/posts/xg3hXCYQPJkwHyik2/the-best-t...
If you're looking for good/useful/worthwhile books to read, I would suggest considering UI/UX as well as technical writing topics - a couple personal recommendations:
* Don't Make Me Think! (UI/UX)
* Forms That Work (UI/UX)
* Letting Go of the Words (interface writing / UI/UX)
* Developing Quality Technical Information: A Handbook for Writers and Editors (technical writing)
* Don't Make Me Think! (UI/UX)
* Forms That Work (UI/UX)
* Letting Go of the Words (interface writing / UI/UX)
* Developing Quality Technical Information: A Handbook for Writers and Editors (technical writing)
For engineers who want to make less silly user interface mistakes, I second the recommendation for don't make me think. Since it was one of my first engineering books, the gang of four design patterns book will always be on my recommendations list.
I've found that the mindset taught by Don't make me think applies to other engineering practices as well - documenting, writing READMEs, and designing APIs.
I'm the owner of the repo. Thank you for posting this.
Many people here (and elsewhere) complain about the "curation" method I used, which is based on simple algorithmic rules instead of a subject matter expert curation. I totally understand their point. I admit that I misused the term "curated" here. I thought that algorithmic selection is a kind of curation.
When I made this, I didn't intend for a recommendation list. Instead, I intended for a comprehensive list excluding low-profile books. And there was a simple reason behind that: I don't know your experience level nor your preferences. You might prefer theoretical over practical books. Or prefer verbose over concise books. Or art-based over engineering-based books. Or and or and or. I will change "curated" to "comprehensive" in the repo description to reveal my purpose effectively and eliminate ambiguity.
You will end up with hundreds of almost unrated (zero raters) books without these seemingly simple algorithmic rules.
Don't be overwhelmed by the number of books on each subject. Practically speaking, you are supposed to read one or two books (maybe a little bit more for nerds?) on each subject that you are interested in. Deciding what to read is your business. Alternatively, you may go with the Goodreads community choice and start from the top of each list if you don't have the time to read reviews.
Many people here (and elsewhere) complain about the "curation" method I used, which is based on simple algorithmic rules instead of a subject matter expert curation. I totally understand their point. I admit that I misused the term "curated" here. I thought that algorithmic selection is a kind of curation.
When I made this, I didn't intend for a recommendation list. Instead, I intended for a comprehensive list excluding low-profile books. And there was a simple reason behind that: I don't know your experience level nor your preferences. You might prefer theoretical over practical books. Or prefer verbose over concise books. Or art-based over engineering-based books. Or and or and or. I will change "curated" to "comprehensive" in the repo description to reveal my purpose effectively and eliminate ambiguity.
You will end up with hundreds of almost unrated (zero raters) books without these seemingly simple algorithmic rules.
Don't be overwhelmed by the number of books on each subject. Practically speaking, you are supposed to read one or two books (maybe a little bit more for nerds?) on each subject that you are interested in. Deciding what to read is your business. Alternatively, you may go with the Goodreads community choice and start from the top of each list if you don't have the time to read reviews.
It really frustrates me that systems like Amazon and Goodreads (even before the Amazon acquisition) or Grubhub or Doordash don't allow you to order by number of reviewers.
I almost never care if something is 4/5 if only <10 people reviewed it unless the thing is very niche. Especially when trying to discover within a genre or keyword I'd like to see the books people read most. That's basically impossible to fine without hand-curated Best Of lists.
I'm prompted to say this by the fact that this curated list _does_ show the number of raters. So nice work.
I almost never care if something is 4/5 if only <10 people reviewed it unless the thing is very niche. Especially when trying to discover within a genre or keyword I'd like to see the books people read most. That's basically impossible to fine without hand-curated Best Of lists.
I'm prompted to say this by the fact that this curated list _does_ show the number of raters. So nice work.
I noticed this as well. Newegg is the only place I know of that lets you order by number of reviews.
This is just a long list of books on the topics, in what way has it been curated? Curation would be recommending two or three books on each topic which are excellent and outstanding in conveying the topic they cover.
Telling someone to read 20 books is hardly useful. Nobody is going to actually do that.
Long overwhelming lists of books considered harmful.
Telling someone to read 20 books is hardly useful. Nobody is going to actually do that.
Long overwhelming lists of books considered harmful.
Just read:
- Clean Architecture - Design Patterns: Elements of Reusable Object-Oriented Software - Domain-Driven Design: Tackling Complexity in the Heart of Software - Clean Agile
and forget the rest. Life is short and those books are more than enough.
- Clean Architecture - Design Patterns: Elements of Reusable Object-Oriented Software - Domain-Driven Design: Tackling Complexity in the Heart of Software - Clean Agile
and forget the rest. Life is short and those books are more than enough.
Designing Data-Intensive Applications has taught me more than 90% of what I know about scalability. I can't recommend that book enough.
I recently skimmed through it, for maybe 30 minutes, but it reads like an introductory text. Maybe useful if you've never heard the terms "replication" and "sharding" before, but not all that useful if you actually have to build a scalable architecture and you don't want to shoot yourself in the foot by designing something that's either too complex or that's going to fall over the moment traffic doubles.
I read through it and really enjoyed the way it was both a tour of the landscape, but also went into real distinctive attributes of why the 10 different X (message formats, pubsub architectures, etc) exist and what each one gains and loses by the choices it made.
For a more prestigious review:
“This book is awesome. It bridges the huge gap between distributed systems theory and practical engineering. I wish it had existed a decade ago, so I could have read it then and saved myself all the mistakes along the way.”
For a more prestigious review:
“This book is awesome. It bridges the huge gap between distributed systems theory and practical engineering. I wish it had existed a decade ago, so I could have read it then and saved myself all the mistakes along the way.”
— Jay Kreps, Creator of Apache Kafka and CEO of ConfluentHonest question - can a list really be curated if it’s basically just algorithmically generated?
What kind of curation is this?
Did you just literally search for books on software architecture on the internet . I can guarantee that the OP didn't even read 50%.
Did you just literally search for books on software architecture on the internet . I can guarantee that the OP didn't even read 50%.
I recommend reading the "Inclusion criteria" section of TFA.
This sentence wasn't clear:
> I thoroughly reviewed all books [tagged with software-architecture] on Goodreads and picked the best objectively
I thought that reviewing a book meant that you read it, but no? Is this a review of reviews?
> I thoroughly reviewed all books [tagged with software-architecture] on Goodreads and picked the best objectively
I thought that reviewing a book meant that you read it, but no? Is this a review of reviews?
This "curated" list has hundreds of volumes. I wonder what an uncurated list would look like.
In practice, the typical software developer is not terribly well-read. The number of (non-mandatory) volumes most devs read (not just use as bookshelf decoration) is probably in the lower single digits. If you read one software engineering book a year, you are probably in the top 5%.
In practice, the typical software developer is not terribly well-read. The number of (non-mandatory) volumes most devs read (not just use as bookshelf decoration) is probably in the lower single digits. If you read one software engineering book a year, you are probably in the top 5%.
Hey! My book’s on that list. (The Art of Agile Development.) The second edition is coming out later this year and I’ve been putting it up on my website as part of the open review: https://www.jamesshore.com/v2/books/aoad2
I loved the first edition! What's new in the second edition?
Thanks! And a lot. It’s basically a complete rewrite. Same practical “how to” focus, but with the benefit of 14 more years’ experience. A lot of material on organizational change, a new chapter on DevOps, material on remote teams, 12 new practices, including one on Incident Analysis I’m particularly proud of.
Sound great. Looking forward to getting one!
There are lots of great suggestions here in this repo however playing the Devil's advocate here, I feel that's really low effort one list (sorry for being this harsh).
Maybe we can create a repository where people's vote and comment why they recommend a book. Does GitHub have a way to vote stuff?!
What you people think about it?!
Maybe we can create a repository where people's vote and comment why they recommend a book. Does GitHub have a way to vote stuff?!
What you people think about it?!
Please add:
* Structure and Interpretation of Computer Programs (SICP)
* Structure and Interpretation of Computer Programs (SICP)
PS. The MIT Press based book by Harold Abelson and Gerald Jay Sussman with Julie Sussman, foreword by Alan J. Perlis is CC-BY-SA-4.0 and available in 2nd edition as PDF here:
https://web.mit.edu/alexmv/6.037/sicp.pdf
https://web.mit.edu/alexmv/6.037/sicp.pdf
That seems off topic. SICP is about understanding language, not architecture. That would be like saying you need to understand how SED and AWK would be implemented is Lisp before you try to write a script to use them together to parse a document.
SICP is to a large extent also about the interplay of language choices and architectural choices.
Although an interesting book, does it really fit into one of the categories?
Goes to show how poorly constructed this list is with this one missing.
If you add SICP, you probably can't omit Concepts, Techniques, and Models of Computer Programming either.
If you're going to add Concepts, Techniques, and Models of Computer Programming, you should add TAOCP as well.
Not quite sure how TAOCP relates to either of the former two. Those two books contain descriptions of architectural patterns, especially ones that are language-based.
IMHO auch software architecture books are great, but nowadays most software is embedded in a larger system, be it an appliance or an enterprise. And thus it is hard to meaningfully talk about software architecture without the containing system architecture. Therefore: System Architecture: Strategy and Product Development for Complex Systems by Crawley
This list isn’t curated in the usual sense of the word. The inclusion criteria explain.
I’m left wondering about the Venn diagram of self-selected GoodReads reviewers and current pragmatic software engineering practitioners with a systems architect mindset.
I’m left wondering about the Venn diagram of self-selected GoodReads reviewers and current pragmatic software engineering practitioners with a systems architect mindset.
I felt like a kid in a candy store, even if only briefly. While not a comprehensive list, it is a good start.
These are shitty books written by people that write and support bloated enterprise software.
Start with SICP.
Start with SICP.
what I miss in this list is the bibliographical information
Cover thumbnails would make this so much better ...
Goodreads can do it.
that is exactly what i want
The chapters are short and stand independently. In general the technical writing is pretty good, a skill that I am not surprised to find in project leaders.
It is free to read online: http://aosabook.org/en/index.html