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

11–20 of 39 posts

Re: Software Architecture Guide (2019)

#11

Post by csbartus »

simonw wrote: post #9
csbartus wrote: post #7

In my 30+ years of SWE/SWA career this is the first time I can harvest the benefits of a well defined and exactly implemented architecture. Thanks to LLMs. Before LLMs even if the architecture principles were simple and clear, distilled into templates + codegens added for boilerplate / skeleton generation ... It was impossible to follow them on the long run. Devs tried their best, but on the long run everything erode…

Something I recently realized is that the fastest and easiest way to use coding agents is if you apply them to problems where there is just one, obvious solution. This absolutely relates to architecture. If your system is designed such that any given feature fits in an obvious place, using obvious patterns, with obvious ways to test it... 90% of the time a coding agent will be able to do exactly the right thing from…

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.

Re: Software Architecture Guide (2019)

#12

Post by aljgz »

"We create products and services that we are proud of"

This was one of the 3 core values in the best company I ever worked for. One I would never leave, if the region was not heading for a disaster.

Good architecture transcends the software: enables people to be their best, evolve the software to better match the reality of its reason for existence.

In an effective organization, people constantly exceed their own expectations. They debate alternatives, understanding the reality of momentum, but aiming for an infinitely long living product.

They identify the "main problem", find ways to best solve that.

A good architecture does not do much more than what's needed, but avoid unnecessary assumptions that would block future development.

It is vague, philosophical, pragmatic, challenging, rewarding.

Re: Software Architecture Guide (2019)

#13

Post by bluefirebrand »

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…

I've been doing this stuff for about 15 years now. Longer than many, not as long as some.

In my opinion, good architecture should be easy to extend, easy to scale (up and down), easy to reproduce. Microservice architectures are easy to scale, but usually hard to reproduce (any amount of config per service adds up a lot) and can be very hard to extend too (any changes to one service might ripple to many others, with knock-on effects)

One of my biggest red flags for a bad architecture is if you cannot easily create a (preferably localhost) development environment for it. I think this is where a lot of microservice based projects stumble. It leads to a lot of brittleness and a very siloed development team in my experience. Replacing what should be a library call or DB query with a network request to another service (which then has to query the DB for you) is a certain kind of lunacy.

Frameworks that are very opinionated are also very bad in my opinion. Depending how strict they are if you're doing anything even remotely unexpected you will butt up against the limitations of the framework often. That's annoying to me, I prefer to build my own stuff.

Re: Software Architecture Guide (2019)

#15

Post by Schiendelman »

aljgz wrote: post #12

"We create products and services that we are proud of" This was one of the 3 core values in the best company I ever worked for. One I would never leave, if the region was not heading for a disaster. Good architecture transcends the software: enables people to be their best, evolve the software to better match the reality of its reason for existence. In an effective organization, people constantly exceed their own exp…

What was the region?

Re: Software Architecture Guide (2019)

#16

Post by saratogacx »

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…

I like to ask this question: "Can I make this system do what I need it to do while being able to stay with the existing architecture or do I need to become a special case?"

There is a lot buried in this question but it can help sus out if the rules in place allow the challenges the system faces today or if it is antiquated in how it views the world it operates in. Good and bad can be related to time and context but like many things in software, it needs to be able to change and sometimes that change requires the willingness to start from scratch with new assumptions.

Attributes like mix of languages, system/task ownership, specialization are symptoms that an architecture may want to enable or discourage but are symptoms, not measures of quality. Automated testing and how much that influences your software design is more aligned with the culture of the organization and how it treats code than it is the arrangement of subsystems it is built on.

Re: Software Architecture Guide (2019)

#17

Post by amosjyng »

csbartus wrote: post #11
simonw wrote: post #9

Earlier quoted context omitted.

Something I recently realized is that the fastest and easiest way to use coding agents is if you apply them to problems where there is just one, obvious solution. This absolutely relates to architecture. If your system is designed such that any given feature fits in an obvious place, using obvious patterns, with obvious ways to test it... 90% of the time a coding agent will be able to do exactly the right thing from…

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 right place? E.g. a problem I repeatedly run into is the LLM weakening abstraction boundaries. I have to explicitly tell it things such as "No, this is obviously a UI-specific endpoint that belongs on the BFF rather than on the business logic focused backend API." Of course it gets better as I add more examples and rules each time I catch something dumb, but it sounds like you're avoiding this problem altogether with good architecture. How are you doing that?

4. It sounds like you have some sort of workflow that is standardized yet still generalizable enough to cover the generic case of new feature development on the system. How is that possible? What can you share about this flow?

Re: Software Architecture Guide (2019)

#18

Post by aljgz »

Schiendelman wrote: post #15
aljgz wrote: post #12

"We create products and services that we are proud of" This was one of the 3 core values in the best company I ever worked for. One I would never leave, if the region was not heading for a disaster. Good architecture transcends the software: enables people to be their best, evolve the software to better match the reality of its reason for existence. In an effective organization, people constantly exceed their own exp…

What was the region?

I'm Iranian

Re: Software Architecture Guide (2019)

#20

Post by mpweiher »

While these somewhat fuzzy definitions are hugely important (well, it says: "the important stuff, whatever that is", so by definition...), I have a hard time calling them "software architecture".

I'd like to suggest that at least some of the problems associated with the term, for example the pomposity, are rooted in the "separation from programming" that is not just a suggestion, but an unfortunate fact of architecture today.

And I would further suggest that we could improve the situation if we could actually express our architectures in our programs, in our programming languages. Then software architecture wouldn't just be "deeply intertwined with programming", as it must be, but actually be part of programming and part of the program.

And once the architecture becomes part of the program, it becomes part of our feedback loops. My experience is that feedback loops are a good antidote to pomposity and great for building/evolving systems.

To do that, though, we have to retreat from this idea that software architecture must be fuzzy, an idea that IMNSHO is just a cope for the current sad state of affairs. We have pretty good definitions of architecture (connectors and components, systems, architectural styles, etc.), let's start using them in earnest and in our programs.

Post reply on HN