Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Architecture Guide (2019)

martinfowler.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Software Architecture Guide (2019)

#21

Post by cadamsdotcom »

The most powerful thing you can do in 2026: lint your architecture in a pre-commit check.

Agents & humans can’t commit, or stop work, unless they’ve passed all lint checks. Passing the linter requires complying with the architecture. Now architecture violations can’t creep in and entrench themselves - they have to be fixed upfront. Code review is free from worries about architecture too.

Start by having your agent install some import-linter rules. When you hit its limits, have your agent write a custom AST-based checker (a short python script will do) that can look for imports that violate your rules. Resist its attempts to add a `# noqa: imports` escape hatch, because future agents will gleefully abuse that and you’ll be back to human in the loop (ask me how I know!)

Re: Software Architecture Guide (2019)

#22

Post by jeffreygoesto »

YZF wrote: post #10
cjfd wrote: post #6

Earlier quoted context omitted.

So what would be a good architecture? How would I recognize it if I stumbled against it? My own inclinations here are that it would be good to have as few different technologies as possible. To run things on as few different machines as possible and to have automated tests for everything. The thing is that as soon as there are multiple technologies you get to have different people specializing in them and it is alway…

In an existing system some combination of these attributes: - High quality (e.g. low number of issues hit by customers, resilient to failures, efficient, secure etc.) - Easy to maintain (well organized, broken down in a sensible way into components or layers) - Easy to extend/adapt to future requirements (i.e. the designer was able to anticipate the likely direction of the system and account for that in the design) A…

We sometimes point to ISO25010 [0] if management or not so experienced devs are asking. It contains a good deal of the relevant "qualities" you keep an eye on for quality.

[0] https://iso25000.com/index.php/en/iso-25000-standards/iso-25...

Re: Software Architecture Guide (2019)

#23

Post by cadamsdotcom »

> This is what happens with poor internal quality. Progress is rapid initially, but as time goes on it gets harder to add new features. Even small changes require programmers to understand large areas of code, code that's difficult to understand. When they make changes, unexpected breakages occur, leading to long test times and defects that need to be fixed.

Seems familiar!

> Concentrating on high internal quality... is a rarer case, as it requires a skilled and disciplined team to make it happen. But we do occasionally see it.

Vibecoding vs. agentic coding. Same tools used different ways. Very different outcomes.

Re: Software Architecture Guide (2019)

#24

Post by sunrunner »

jeffreygoesto wrote: post #22
YZF wrote: post #10

Earlier quoted context omitted.

In an existing system some combination of these attributes: - High quality (e.g. low number of issues hit by customers, resilient to failures, efficient, secure etc.) - Easy to maintain (well organized, broken down in a sensible way into components or layers) - Easy to extend/adapt to future requirements (i.e. the designer was able to anticipate the likely direction of the system and account for that in the design) A…

We sometimes point to ISO25010 [0] if management or not so experienced devs are asking. It contains a good deal of the relevant "qualities" you keep an eye on for quality. [0] https://iso25000.com/index.php/en/iso-25000-standards/iso-25...

That looks like a whole lot of dimensions to measure without providing any clear way of actually doing so. Which I guess is the point? But what do management or less experienced devs actually do with the information in the standard after they’ve read it?

Re: Software Architecture Guide (2019)

#25

Post by kxc42 »

cadamsdotcom wrote: post #21

The most powerful thing you can do in 2026: lint your architecture in a pre-commit check. Agents & humans can’t commit, or stop work, unless they’ve passed all lint checks. Passing the linter requires complying with the architecture. Now architecture violations can’t creep in and entrench themselves - they have to be fixed upfront. Code review is free from worries about architecture too. Start by having your agent in…

For python projects I created pytest-archon[1], initially for humans, but now I'm using it for agents, too.

[1]: https://github.com/jwbargsten/pytest-archon

Re: Software Architecture Guide (2019)

#26

Post by cadamsdotcom »

kxc42 wrote: post #25
cadamsdotcom wrote: post #21

The most powerful thing you can do in 2026: lint your architecture in a pre-commit check. Agents & humans can’t commit, or stop work, unless they’ve passed all lint checks. Passing the linter requires complying with the architecture. Now architecture violations can’t creep in and entrench themselves - they have to be fixed upfront. Code review is free from worries about architecture too. Start by having your agent in…

For python projects I created pytest-archon[1], initially for humans, but now I'm using it for agents, too. [1]: https://github.com/jwbargsten/pytest-archon

Thanks, lots to love in here! You’re clearly a convert :)

The goal is codification.

Writing down knowledge as verifiable invariants. The more that is codified, the less context you need. And that means you can be fearless.

Re: Software Architecture Guide (2019)

#27

Post by crewindream »

cjfd wrote: post #6
YZF wrote: post #2

The problem is that bad architecture can be carried forward for a very long time at increasing cost. The ability to differentiate good and bad architectures seems to be a lost art because to build this ability you need to have enough experience (e.g. the discussion in "The Mythical Man-Month"). Most software developers today have had no experience designing even a single system and many systems are often a random ass…

So what would be a good architecture? How would I recognize it if I stumbled against it? My own inclinations here are that it would be good to have as few different technologies as possible. To run things on as few different machines as possible and to have automated tests for everything. The thing is that as soon as there are multiple technologies you get to have different people specializing in them and it is alway…

Good architecture reduces cost, while still achieving business goals.

(E.g. If you have problems hiring for a weird stack, it increases hiring cost; you have problems with dependency zoo maintenance it increases costs; if it took a year to build a framework that could've been a bash script, it increased the cost)

Every other architecture “metric” should be useful/convenient proxy towards reducing overall cost.

Re: Software Architecture Guide (2019)

#28

Post by speedbird »

amosjyng wrote: post #17
csbartus wrote: post #11

Earlier quoted context omitted.

Exactly! What I use is a main workflow document where I embed at every step pointers to architecture and templates. My prompt is ... "We are implementing the X feature. We are at step 6. Plan first" Then the agent spits out identical plans then identical code for every feature.

I am so curious as to how you make this happen. 1. How do you organize your architecture files so that agents know where to find and update architectural info? E.g. everything in one big file, or sharded per module/subsystem with an AGENTS.md for discoverability, or something else? 2. What gets templated? What do your template files contain or look like? 3. How do you get the LLMs to actually slot something into the…

You can use a well known template like ARC42 and insist on the maintenance of suitable indexes for agent access and review for coherence on a regular basis.

Ultimately any useful documentation needs active curation.

Getting devs to do this well is hard. Agents can be driven to do a fair job through suitable prompt frameworks and repetition eg as PR reviewers.

I’ve had reasonable success with a combination of space dimensions structured requirements and component based indexes and time dimensions of decision records and commits.

Also a strong design model to give common structure - hex arch with ports and adapters and pure business logic.

YMMV

Re: Software Architecture Guide (2019)

#29

Post by bluefirebrand »

sunrunner wrote: post #24
jeffreygoesto wrote: post #22

Earlier quoted context omitted.

We sometimes point to ISO25010 [0] if management or not so experienced devs are asking. It contains a good deal of the relevant "qualities" you keep an eye on for quality. [0] https://iso25000.com/index.php/en/iso-25000-standards/iso-25...

That looks like a whole lot of dimensions to measure without providing any clear way of actually doing so. Which I guess is the point? But what do management or less experienced devs actually do with the information in the standard after they’ve read it?

Hopefully, they ask more experienced devs "what do we do to accomplish this" and hopefully the devs on their team actually are experienced enough to have good answers

Re: Software Architecture Guide (2019)

#30

Post by userbinator »

Take his advice with a grain... or perhaps a quarry's worth of salt. This guy has written plenty of books and articles about the "agile" dogma, but most crucially, nothing about any of the software that he wrote. These days, it's even more obvious as the contents of this page feel like something an LLM could've generated.

If you want a "software architecture guide", you'd be better off examining software written by the likes of Linus Torvalds, Richard Stallman, Brian Kernighan, Dennis Ritchie, etc.

Post reply on HN