121–130 of 133 posts
Software design/architecture is a strange beast. It feels that if you want to learn it, you should spend time in legacy systems and large codebases of rewrite a project 3 times to explore counterfactuals. A lot of books on the subjects are abstract and give such simple examples, they are useless.
Earlier quoted context omitted.
Ah, the infamous "I believe I'm building a video game, but in reality I'm building a video game engine and I don't realize it yet" every game developer goes through at least once, god speed to you :)
Its been such a fun endeavor
Good reminder for the rest of us to enjoy the journey once in a while.
[flagged]
> Laozi gives the complementary warning: “In pursuing learning, every day something is added. In pursuing the Tao, every day something is dropped.” Mastery is not only accumulation. It is also subtraction: removing unnecessary abstraction, ceremony, cleverness, and control. Well, your (or your LLM's) interpretation is a bit less nuanced than the original. The verse from DDJ you mention is more about letting go and li…
I totally agree that programming needs enough complexity to handle the complexity of the world. However, elegant architecture should less accumulate unnecessary complexity or organizational burdens.
Sorry for the late reply since my account is fairly new and system do not allow me to reply too fast on yesterday.
Earlier quoted context omitted.
I think of it this way. Software architecture can not be taught. (This is not particularly uncommon, and so not a claim to being particularly special.) But you can sensitize people to the problems they will encounter and solutions they should consider. You can't "teach" someone into being a software architect of 10 "software architecture goodness units", but you can accelerate the rate at which they accumulate SAGUs…
It’s tangential to your point, which I agree with completely, but this is also exactly why I get so frustrated with the idea that higher education is about acquiring job skills. Ideally, regardless of major, a university teaches you how to think, critically and deeply, and how to learn. If you have those things, job skills are easy to pick up, but instead we treat college like an RPG skill tree, where you’ve got to p…
Two quotes I am keep revisit when I learn:
“To LEARN, and to PRACTICE what you learned at the RIGHT time, and from time to time, isn't that JOY indeed?” - Confucius
“Many have remarked the speed with which Muad'Dib learned the necessities of Arrakis. The Bene Gesserit, of course, know the basis of this speed. For the others, we can say that Muad'Dib learned rapidly because his first training was in how to learn. And the first lesson of all was the basic trust that he could learn. It is shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult. Muad'Dib knew that every experience carries its lesson.” ― Frank Herbert, Dune
Earlier quoted context omitted.
I don't agree with all of these, but I'll add a couple of my own: - The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible. Any bad design which is better on those goals than a good design is actually a good design. - Make your interfaces easy to use correctly and hard to misuse. Think of how people unf…
> The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible. Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have…
Solving the immediate problem should be the primary goal (otherwise you get overengineering), but the secondary goal is still important. It seems like that PM didn't consider the secondary goal at all, he achieved the primary one without considering anything else.
Incidentally, this is a pattern agents often fall into. They're great task finishers, not so great architecture designers.
Earlier quoted context omitted.
I think of it this way. Software architecture can not be taught. (This is not particularly uncommon, and so not a claim to being particularly special.) But you can sensitize people to the problems they will encounter and solutions they should consider. You can't "teach" someone into being a software architect of 10 "software architecture goodness units", but you can accelerate the rate at which they accumulate SAGUs…
It’s tangential to your point, which I agree with completely, but this is also exactly why I get so frustrated with the idea that higher education is about acquiring job skills. Ideally, regardless of major, a university teaches you how to think, critically and deeply, and how to learn. If you have those things, job skills are easy to pick up, but instead we treat college like an RPG skill tree, where you’ve got to p…
You'd have to have lived a pretty sheltered life to not have picked up those things long before reaching the typical age of attending university.
University's role is to give you a place to apply those qualities to subjects where you otherwise wouldn't have access to the necessary resources to fulfill your interest in the subject, like where you need equipment that costs many figures beyond what a personal budget could ever dream of.
Which is also where the job skill conflation comes from as those same resources are often used to fulfil job training, like where one needs to learn how a certain costly machine works before messing with the real thing in industry.
I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…
What exactly do you mean by “make state explicit”?
All software is actually a state machine and almost all complexity comes from unmanaged state transitions. Especially if you have errors, concurrency, async actions, and distributed systems.
The most important task any software architect has is defining how you know what is true about the system.
Consider a few examples:
await sendEmail(); await saveUser();
That's obvious right? Well what happens when saveUser fails and some retry sends a duplicate email?
---
If you're relying on a webhook to let system A know when system B has changed things, what happens when that failed and now the two systems are out of sync? This is why event-driven architectures often work well: they externalize state transitions.
---
A classic React problem, you define state like this:
``` const [loading, setLoading] = ... const [error, setError] = ... const [data, setData] = ... const [isRefreshing, setRefreshing] = ... ```
Now there's all sorts of invalid states you can be in. Like "loading true, data true, error true".
**
You should strongly prefer: state machines, lifecycle enums, event logs, immutable events, append-only histories, strict versioning, idempotency keys, and explicit workflow stages.
You should avoid like the plauge: hidden globals, timing assumptions, inferred behavior, synchronization, side effects, boolean explosion, mulitple sources of truth.
Event sourcing, CQRS, Redux, Kafka, workflow engines, finite state machines, transactional outboxes, CRDTs, database normalization they all do the same thing _control where the state lives_.
Earlier quoted context omitted.
> The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible. Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have…
So it seems that we agree? Solving the immediate problem should be the primary goal (otherwise you get overengineering), but the secondary goal is still important. It seems like that PM didn't consider the secondary goal at all, he achieved the primary one without considering anything else. Incidentally, this is a pattern agents often fall into. They're great task finishers, not so great architecture designers.
I'll give you the cheat sheet: - Good design is a single idea pervaded throughout. - More generally, your goal should be to minimize surprise. - If your system allows it, people will do it. - Everyone will not just. If your solution starts with "if everyone will just..." then you don't have a solution. - Isolate the parts of your system that transform data from the ones that use it. Data models outlive code. - Coupli…
Good architecture is not about the patterns you pick. It’s about having a team dev cohesively on any pattern(s) - programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated - if you # ignore anything, leave a comment explaining why - use bdd so your cases are human readable and must update with the code (unlike a stale comment) - follow the same pattern in all your services (I lo…
I wonder sometimes if the role of architect in a business might be about having a group/team wide senior person who
- Knows how to architect systems very well and can share that knowledge with the larger group and more junior devs - Is a kind of high level business analyst who can speak "business, stuff that makes money" and "dev, how it's done" to each of those groups effectively
Does Google/Atlassian miss out on things by not having system architects? ... Or can they achieve what's needed by having sensible team rules (so architecture gets followed) and relatively standard reusable architectures (so it's not too hard to adapt to a given business solution).
I'd be genuinely interested to know. My aspiration was to become an architect, but I now wonder if this is the right way to go.
Earlier quoted context omitted.
Good architecture is not about the patterns you pick. It’s about having a team dev cohesively on any pattern(s) - programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated - if you # ignore anything, leave a comment explaining why - use bdd so your cases are human readable and must update with the code (unlike a stale comment) - follow the same pattern in all your services (I lo…
Atlassian and Google require all of their dev hires to be "up to scratch" on architecture. They don't hire system architects at all, as far as I understand. I wonder sometimes if the role of architect in a business might be about having a group/team wide senior person who - Knows how to architect systems very well and can share that knowledge with the larger group and more junior devs - Is a kind of high level busine…