> 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.

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.

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.)

That might very well be true, but to a manager having a handover means the problem of loss of institutional knowledge is solved, and any subsequent problem due to lack of context or loss of institutional knowledge is avoidable and caused by poor handovers.

"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.

I had to take a sudden leave the week before, and my coworkers, and boss cared at a personal level. And while most of my tasks were taken care of by them some weren't, and I had to rush Monday morning when I got back.

This talk is not about personal feelings, even though it could include "do a memorial for the lost person", but it's about all the needed work that must go on on any scenario.

You should understand that people should keep going on their lifes once you are not there, and that is good. If they think kindly of you after your passing depends on your relationship during life, not on any company preparation scenario.

Life and death metaphors are my right to enjoy and share irreverently as the mortal being I am.

Take it like this to understand that mine was aimed to be constructive criticism:

Stop reminding the people who work at your stupid company, doing all your stupid scrum bs ceremonies that if they died and left the wife and children behind, you would be really worried about Tom needing two days to fix a bug in the iOS watch application, whereas it would take you only two hours. Again, you are free to do whatever you want, but if you keep reminding me that none of this bs what I'm doing here really matters to me, don't be surprised that I quit as soon as possible.

I did have a previous workplace, though, where they couldn't stop yapping about the bus factor and I disliked that phrase because it kept reminding me that one day I die and am wasting one more hour of my living days in a pointless retrospective that will have no positive effect on anything.

So? The company isn't going to let all their employees starve to death out of compassion for the one that did die.

They know you don't give a fuck about what happens after you're dead, but they're still alive, and they have to keep things running so that they can continue eating.

Telling people that you don't care what effect your death has on them is a pretty good way to indicate how selfish you are.

It may not be selfish to feel an emotion giving you a background hint about reality. There are hungry children in the world, Im not selfish just because I dont want to eat fermented soybeans.

And before you ask, yes I enjoy being overly graphic like this on the pseudonumoyous internet to exaggerate my points but I wouldn't do this irl. That is hypocritical of me.

from a more practical perspective: No, because you're replacing a well-understood metaphor with something that is unknown, juvenile and stupid, removing the value we get from shared language constructs.

But i could imagine someone who states that it's his "right" to be as irreverent as he likes to whomever he wants to is not open to the concept of other people's perspective.

And just to be clear, I wasn't saying that you should use my example instead. :D

And of course it's a strawman exaggerated version of the common "hit by a bus" idiom.

Story from this week:

Manager at large-ish IT support company, visibly distraught, tells their manager that one of her direct reports got cancer.

Response: "Oh, and I thought something bad happened, like the direct report quit."

You are reading a lot out of words read on an internet screen. This manager may very well be toxic, they may also just not be able to express emotion in the same way and very well went above and beyond putting everything in place for said employee to receive all the medical support they need, mental and physical.

We don't know and for all we know OP is in a bad space and completely misread the situation.

This whole comment is devil's advocate, you can make the same argument for the exact opposite and of course your personal experience matters but leave the airing of dirty laundry out of public forums and if I do the same I encourage anyone to call me out on it.

While it might be uncomfortable to be reminded of, it is in most cases true.

The company isn’t your family or your friends, and most managers adhere to the doctrine that the single important responsibility of the company is to create value for the stock holders.

That will exactly be the key worry of the management.

We've had team members lost like that - and that was the worry.

They'll still feel sorry, say their condolensces, and might even go to the funeral, but in the end, the work continues - almost immediately.

An alternative interpretation is "we have to keep doing x and y to earn our living, and it's doubly difficult because not only did you know how to do them but we're all having difficulty coping with your passing".

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

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?

And both were back to work in about a week.

I need a different standard example disaster.

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

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.

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

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.

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.

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.

It's not true, there are architectures that are a waste of time today, and a waste of time in 5 years, too.

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".

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.

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

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

[3] JESA section 1.5, 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."

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

Generally, clever architecture at the right stages can beat clever code and leave flexibility to pivot.

"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

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...

>> 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.

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.

1) Not all qualities are requirements. Requirements tend to be pass/fail, either you meet them or you don't. Latency is a quality and typically lower is better, not pass/fail (though sometimes it is).

2) "Nonfunctional" in other contexts means broken. If you saw a machine with a sign on it saying "nonfunctional" what would you conclude?

At one point I tried to find the origin of the term "quality attributes". It's way older than the software community. I found it being used in the 1960's by the US National Academy of Sciences. If anyone knows the origin I'm interested in learning more.

"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...

"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...

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…

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

And nobody ever will, because in 10 years, coding AIs will not look like they do now. Right now they are just incapable of architecture, which your supposed optimal approach seems to be optimizing for, but I wouldn't care to guarantee that's the case in 10 years. If nothing else, there will certainly be other relevant changes. And you'll need experience to determine how best to use those, unless they just get so good they take care of that too.

But I find it intriguing. Do you mean architecting software to allow LLMs to be able to modify and extend it? Having more of the overall picture in one place (shallow monoliths) and lots of helper funtions and modules to keep code length down? Ie, optimising for the input and output context windows?

LLMs can unlock incredibly development velocity. For things like creating utility or helper functions and their unit tests at the same time, an engineer using a LLM will easily 10x an equally skilled engineer not using a LLM. The key is to architect your system so that as much of it as possible can be treated this way, while not making it indecipherable for humans.

This is a temporary constraint. Soon the maintenance programmers will use an AI to tell them what the code says.

The AI might not reliably be able to do that unless it is in the same "family" of AIs that wrote the code. In other words, analogous to the situation today where choice of programming language has strategic consequences, choice of AI "family" with which to start a project will tend to have strategic consequences.

It's more of a generic system with attention on performance of specific application rather than a system designed to cater to current LLMs.

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".

It does make the last step ("have a piece of software that's fit-for-purpose") a bit harder; but that's a price you should be willing to pay for velocity.

Maybe this time it’s different, maybe it’s not. Time will tell.

I’ve been writing code professionally for a decade. I’ve led the development of production-grade systems. I understand architecture. I’m no idiot. I use Copilot. It’s regularly helpful. and saves time. Do you have a counter-argument that doesn’t involve some sort of thinly veiled “but you’re an idiot and I’m just a better developer than you”?

I don’t by any means think that a current generation LLM can do everything that a software developer can. Far from it. But that’s not what we are talking about.

It's not that I don't believe your experience specifically. I don't believe either side in this case knows the real industry-wide average improvement until someone really measures it.

What I do know though, is that ChatGPT can finish a leetcode problem before I've even fully parsed the question.

There are definitely ratholes to get stuck and lose time in when trying to get the LLM to give the right answer, but LLM-unassisted programming has the same problem. When using an LLM to help, there's a bunch of different contexts I don't have to load in because the LLM is handling it giving me more head space to think about the bigger problems at hand.

No matter what a study says, as soon as it comes out, it's going to get picked apart because people aren't going to believe the results, no matter what the results say.

This shit's not properly measurable like in a hard science so you're going to have to settle for subjective opinions. If you want to make it a competition, how would you rank John Carmack, Linus Torvalds, Grace Hopper, and Fabrice Bellard? How do you even try and make that comparison? How do you measure and compare something you don't have a ruler for?

This is an interesting case for two reasons. One is that leetcode is for distilled elementary problems known in CS - given all CS papers or even blogs at disposal, you should be able to solve them all by pattern matching the solution. Real work is anything but that - the elementary problems have solutions in libraries, but everything in between is complicated and messy and requires handling the unexpected/underdefined cases. The second reason is that leetcode problems are fully specified in a concise description with an example and no outside parameters. Just spending the time to define your problem to that level for the LLM is likely getting you more than halfway to the solution. And that kind of detailed spec really takes time to create.

You have to watch out for that, that's an AI evaluation trap. Leetcode problems are in the training set.

I'm reminded of people excitedly discussing how GPT-2 "solved" the 10 pounds of feathers versus 10 pounds of lead problem... of course, it did, that's literally in the training set. GPT-2 could be easily fooled by changing any aspect of the problem to something it did not expect. Later ones less so though last I tried a few months ago while they got it right more often then wrong they could still be pretty easily tripped up.

Requiring that the counter-argument reaches a higher bar than both your and the original argument is...definitely a look!

Linus Torvalds is a strong advocate. He even wrote a blockchain-based source code management system, which he dubbed “the information manager from hell”[0], spending over three months on it (six months, by his own account) before handing it over to others to maintain.

People complain that this “information manager” system is hard to understand, but it's actively used (alongside email) for coordinating the Linux kernel project. Some say it's crucial to Linux's continued success, or even that it's more important than Linux.

[0]: see commit e83c5163316f89bfbde7d9ab23ca2e25604af290

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...

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.

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.

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.

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?

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)

I read the article about quality attributes you linked. Interestingly it mixes attributes that are measurable, like performance and availability, but also ones that are very hard to measure like extensibility and adaptability.

The latter group of attributes are often not measured at all in my experience. I don’t even know of a way that lets me quantify those in a sound, practical way.

The opinions on how to optimize for these attributes are conflicting and full of contradictions. Nobody seems to have a clear model.

What is your take on this?

Same applies to much of software.

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.

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.

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” :)

---

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.

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?

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-...

That said, ideas like ubiquitous language and bounded contexts are extraordinarily powerful, and definitely sharpened my own observations, so despite the filler, all in all I'd say it's one of the keystone books on software design and definitely worth reading.

Another thing that DDD talks about, and is relevant to this, is that design and implementation are two sides of the same coin. In "Just Enough", Fairbanks says, "Every architect I have met wishes that all developers understood architecture". Well, I am not kidding when I say that I wish every architect I've ever met understood software. A lack of understanding of the technical constraints of computing is just as likely to lead to failure as misunderstanding the business constraints. They are both critical to success, and these people should be working and learning from each other, rather than operating in a hierarchy.

To that point, one of the most influential things I've ever read was Code as Design: https://www.developerdotstar.com/mag/articles/reeves_design_...

Since it's a series of essays, it has all the detail and none of the filler.

Domain Driven Design has a lot of good ideas, but then I consistently see them misrepresented by others who seem to half-understand it?

Probably the clearest example is the idea of a “bounded context.” You will find microservice folks for example who say you should decompose such that each microservice is one bounded context and vice versa, but then when they actually decompose a system there's like one microservice per entity kind (in SQL, this is a relation or table, so in a microservice pet-adoption app there would be a cat service, a dog service, a shelter service, an approval service, a user service...).

The thing is, Eric Evans is pretty clear about what he means by bounded context, and in my words it is taking Tim Peters’s dictum “Namespaces are one honking great idea—let’s do more of those!” and applying it to business vocabulary. So the idea is that Assembly Designer Jerry on the 3rd floor means X when he says “a project,” but our pipefitter Alice on the shop floor means something different when she says “a project,” and whenever she hears Jerry talking about a project she is mentally translating that to the word “contract” which has an analogous meaning in her vocabulary. And DDD is saying we should carefully create a namespace boundary so that we can talk about “pipefitting projects” and “pipefitting contracts” and “assembly-design projects” and then have maybe a one-to-one relationship between pipefitting contracts and assembly-design projects. Eric Evans wants this so that when a pipefitter comes to us and tells us that there's a problem with “the project,” we immediately look at the pipefitter project and not the assembly-design project. He really hates that wasted effort that comes from the program not being implemented in vocabulary that closely matches the language of the business.

So if the microservices folks actually had internalized Eric's point, then they would carve their microservices not around kinds of entities, but rather archetypes of users. So for the pet adoption center you would actually start with a shelter admin service and a prospective adopter service and a background checker service, assuming those are the three categories of people who need to interact with the pet adoption process. Or like for a college bursar's office you would decompose into a teacher service, student service, admin service, accountant service, financial aid worker service, person who reminds you that you haven't paid your bills yet service.

So I thought it was a really good read, that's actually a really interesting perspective, right? But I don't think the ideas inside are communicated with enough clarity that I can bond with others who have read this book. It is kind of strange in that regard.

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.

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.

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.