[HN Gopher] How Much Architecture Is "Enough?"
___________________________________________________________________
How Much Architecture Is "Enough?"
Author : alexzeitler
Score : 36 points
Date : 2024-01-29 11:55 UTC (3 days ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| brodouevencode wrote:
| I've found that using techniques like C4 address this issue
| chrisweekly wrote:
| hmm, not sure I understand how a particular approach to
| diagramming architecture even relates to things like
| determining the value of an MVP.
|
| I found the linked article insightful, and the focus on making
| the MVA an explicit and crucial peer of a given MVP is, for me,
| a helpful framing of concerns that too often remain indistinct.
| brodouevencode wrote:
| C4 pushes a broad view on the state of is and will be, with
| successive "zooming in" at different layers. The act of such
| allows you to figure out what's necessary and what's not,
| while also pushing the builders into thinking in terms of
| reusability/overlap/components/interfaces. Personal
| experience has proved that I wind up architecting for _less_
| using this approach.
| Veuxdo wrote:
| C4 is about diagramming software systems, and primarily
| existing ones at that. Not sure what this has to do with
| creating MVAs.
| Am4TIfIsER0ppos wrote:
| I think that is a joke about bombs.
| ActionHank wrote:
| I find that asking do I really need this right now? Is
| generally good enough. Diagrams just help to see the lay of the
| land.
| bbor wrote:
| I really liked this article. Very concise, clear, and I like the
| systematic thinking of "what are we really DOING here?". If the
| author(s) read this: make sure to define your acronyms in the
| TLDR up top, since it pops up first. Tiny thing but might help
| engagement rates - I almost clicked away thinking MVA was some
| business school concept, not knowing this was part of a series.
|
| I've been reading a lot of Kant recently and he has two ideas I
| think could be helpful to modern software engineering:
|
| 1. Using the word "architectonics" to describe the science of
| structures. Now it's only used for the brain (Cytoarchitectonics)
| and some other small academic fields, sadly. I think that would
| be an awesome evolution for the slowly-outmoded agile coaches of
| the industry: "Architectonic consultants" or "architectonics".
|
| 2. He thinks an important principle of Architectonics is not to
| just collect a bunch of components until you have a system that
| works, but rather to start with the top level, deduce the
| divisions within the structure that are necessary, and only then
| start filling in the details. In the practical world of
| engineering this isn't always necessary, but I've found it really
| helpful, for the exact reasons discussed in this post (scoping,
| not getting ahead of yourself, allowing for growth without doing
| unnecessarily early work, etc)
| asolove wrote:
| Folks who enjoy this should consider reading Christopher
| Alexander's "The Nature of Order", which has some philosophy
| and metaphysics, but also a lot of analysis of concrete
| examples, of how complex structures come to be. It also
| attempts to analyze the process-oriented reasons behind
| guidelines like this.
| CyberDildonics wrote:
| That's called architecture. We don't need new terms to convince
| people they are doing something new so they feel better about
| reinventing the wheel and never making it round.
| wmil wrote:
| You'll know your architecture is complex enough when diagrams of
| it land you a big raise at a new company.
|
| Until then you need more services.
___________________________________________________________________
(page generated 2024-02-01 23:01 UTC)