9 ms·
Just Enough Software Architecture (2010)
- Sakos 2y agoSo is this a good book? Are there any other software architecture books that are recommended reading?
- hemantv 2y agoGame Programming Patterns was one which had a big impact on me. Other was Effective Engineer
- vendiddy 2y agoIs Game Programming Patterns relevant to those who are not building games?
- mon_ 2y agoRelevant excerpt from the Introduction chapter: --- Conversely, I think this book is applicable to non-game software too. I could just as well have called this book More Design Patterns, but I think games make for more engaging examples. Do you really want to read yet another book about employee records and bank accounts? That being said, while the patterns introduced here are useful in other software, I think they’re particularly well-suited to engineering challenges commonly encountered in games: - Time and sequencing are often a core part of a game’s architecture. Things must happen in the right order and at the right time. - Development cycles are highly compressed, and a number of programmers need to be able to rapidly build and iterate on a rich set of different behavior without stepping on each other’s toes or leaving footprints all over the codebase. - After all of this behavior is defined, it starts interacting. Monsters bite the hero, potions are mixed together, and bombs blast enemies and friends alike. Those interactions must happen without the codebase turning into an intertwined hairball. - And, finally, performance is critical in games. Game developers are in a constant race to see who can squeeze the most out of their platform. Tricks for shaving off cycles can mean the difference between an A-rated game and millions of sales or dropped frames and angry reviewers.
- richrichie 2y agoPerformance part alone is worth reading about game development for non game developers. Retail off the shelf machines these days are so powerful that it encourages sloppy design and development.
- water-your-self 2y agoPerformance is very much still relevant in the modern day, even given the area under the curve of moores law
- zamalek 2y agoGames are just normal software dev dialed up to ten, though there are many problems that game developers enjoy not having to care about (and visa-versa). Attempting to make a basic 3D engine is probably a good exercise for all developers - even if it goes uncompleted.
- smnplk 2y agoIs GPP relevant if you don't want to do OOP ?
- yashap 2y agoHaven’t read this one, but have read a few - “Domain Driven Design” (by Eric Evans) was the most influential for me.
- jojohohanon 2y agoI 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?
- sbayeta 2y ago(Not gp) I read this book more than a decade ago, when I was very inexperienced. The thing I remember the most, and I think the most valuable to me, is the idea of defining a shared domain language with the business domain experts, with a clearly defined meaning for each concept identified. For instance, what a "frozen" account exactly means, what's the difference with a "blocked" account. These are arbitrary, but must be shared among all the participants. This enables very precise and clear communication.
- darkerside 2y agoI think that's the core idea. The layer on top the idea that that domain language should be expressed in an isolated core layer of your code. Here lies all your business logic. On top of that, you build application layers to adapt it as necessary to interact with the outside world, through things like web pages, emails, etc. as well as infrastructure layers to talk to your database, etc.
- zeroCalories 2y agoAt my job we have a shared glossary and data model that we use with business people, but do you really need a whole book on that?
- jameshart 2y agoDDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them. No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems. This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/ch04.html https://www.oreilly.com/library/view/learning-domain-driven-...
- mbb70 2y agoDesigning Data-Intensive Applications by Martin Kleppmann. It's my "this is the book I wish I read when I started programming"
- adamors 2y agoWhen you started? I mean it’s a good book but it would be wasted on beginners.
- mbb70 2y agoMaybe not when I started, but after years of hard lessons working with HDFS, Cassandra and Spark (not to mention S3, Dynamo and SQS) seeing all those hard lessons pinned down like butterflies in a display case made me jealous of anyone who found this book early
- pragmatic 2y agoWe’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.
- JackMorgan 2y agoAn absolutely excellent book! I learned so much going through it slowly with a reading group I started at my job.
- notduncansmith 2y agoI 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 2y agoClean Architecture and Fundamentals of Software Architecture: An Engineering Approach.
- GiorgioG 2y agoUgh enough with clean architecture. So much boilerplate. Uncle Bob please retire.
- srid 2y agoJuval'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&seqNum=2 https://www.informit.com/articles/article.aspx?p=2995357&seq... (Note the electricity analogy)
- ChrisMarshallNY 2y agoWriting 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 2y agoAOSA, https://aosabook.org/en/index.html https://aosabook.org/en/index.html is good. Also, study the code of lots of different systems.
- JackMorgan 2y agoI 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/ 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 2y agoGreat book. I think it’s more ideal for folks who solution design day-to-day. Better when you have experiences to relate back with.
- gfairbanks 2y 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.
- pbnjay 2y agoPublished 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…
- zeroCalories 2y agoProcess 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 2y agoI can't think of many things that have changed in architecture since 2010. I'm not talking about fads but about actual principles.
- CuriouslyC 2y agoThings 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.
- wizzwizz4 2y ago> I'm not talking about fads but about actual principles. Most problems are not well-addressed by shallow monoliths made of glue code. It's irrelevant what "AI wants", just as it's irrelevant what blockchain "wants".
- CuriouslyC 2y agoIf you think development velocity doesn't matter, you should talk to the people who employ you.
- hvv8008 2y ago[flagged]
- rowls66 2y agoI 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 2y agoGreat book, I've learnt a lot from it
- evmar 2y agoI 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-2020-testing-numbs-us-to-our-loss-of-intellectual-control https://www.georgefairbanks.com/ieee-software-v37-n3-may-202...
- chanux 2y agoGood read. Thanks for sharing. I feel that this article goes really well with it. https://johnwhiles.com/posts/programming-as-theory https://johnwhiles.com/posts/programming-as-theory
- gfairbanks 2y agoSome 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-1985-section https://gwern.net/doc/philosophy/epistemology/index#naur-198... [2] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC36BJve1vgPBi https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC... [3] Continuous Design, https://www.georgefairbanks.com/ieee-continuous-design/ https://www.georgefairbanks.com/ieee-continuous-design/
- chanux 2y agoValidation of highest order! Thank you for the reply. I finally read the full original text of Programming as Theory Building. Thanks for your writing as well. As the OP said, the Intellectual Control essay is extremely insightful.
- ysofunny 2y agosoftware 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_k 2y agoWhile 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.
- JackMorgan 2y agoNo 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.
- viraptor 2y agoAlso: 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 2y agoGreat analogy with the bike and car. I will use that in the future
- dgb23 2y ago
- xhevahir 2y ago"Risk-dependent" would be a much better name for this methodology. (Why are programmers so fond of this "[X]-driven" phrase?)
- canadaduane 2y agoPersonally, 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 2y agoArchitecture 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 agoSome 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 agoOver engineering is the result when you focus too much on “future” needs.
- sverhagen 2y agoAnd 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 agoWhile 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.
- bjt 2y agoWe did a book club on this at work a few years back. I found it extremely repetitive.
- refibrillator 2y 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 2y agoI've heard that positive spin responded to with "this company is my biggest investment, I'm not going anywhere" :)
- ajanuary 2y 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 2y agoDepends 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.
- serial_dev 2y agoI dislike the "hit by the bus" not because it hypothetically kills a team mate, but because it implies that if one of us dies, the key worry of the management is who left who knows how to deploy the foo-banana service. This phrase is a reminder that nobody would care if you died apart from the fact that only you know how to do x and y. "Abducted by an alien" is so absurd, it takes away all that and replaces it with something potentially fun and an experience of a lifetime. I also very much prefer the lottery example, and the fact that someone on HN would still do a handover doesn't change that fact.
- __rito__ 2y agoIs 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?
- deleted 2y ago[deleted]
- revskill 2y agoI'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 2y agoWithin my prior company they circulated this "Software Architecture for Developers" book by Simon Brown: https://leanpub.com/b/software-architecture 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?
- gfairbanks 2y agoSimon 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+architecture https://www.youtube.com/results?search_query=simon+brown+arc... [2] https://c4model.com/ https://c4model.com/ [3] https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC36BJve1vgPBi https://www.youtube.com/playlist?list=PLRqKmfi2Jh3uoMnZdaWmC...
- RcouF1uZ4gsC 2y 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.