Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.
The kicker about software architecture is that it gives bad advice about writing software. Now, it's true, the individual bits of advice are all over the map. They don't all agree. But the premise was to prevent bad code from getting written by syntax changes and style conventions, hopefully stopping bad practices in their tracks and encouraging good practices in their place. I think the premise failed -- bad code hasn't stopped -- but the experiment continues, and the net sum of all the advice and conventions has been to encourage more complexity and more code, while simplicity is what yields good software.
This is hugely misguided. Architecture comes before implementation, not after. A tool that encourages a view of the structure of the implemenatation to be mistaken for architecture is a tool for failure.
Whatever next?? Make your code edits on source accurately generated from the binary?? :)
It is the sole source I've ever encountered that had anything useful, actionable, insightful, informative, rigorous, etc.
Alas, I've never been able to synthesis Design Rules' methodology into any of my efforts.
Because what I do is software craftsmanship. I've designed some awesome stuff (and a lot of crap). But nothing rigorous, repeatable, explainable.
For a few years, I bought every software design book I could find. Some of them actually good. But the ones claiming to be about "software architecture" are really describing software craftsmanship. Describe as in descriptive, vs prescriptive.
From memory, Design Rules states that architecture is the set of visible design choices in a product. The entire thesis of the book, backed by oodles of case studies and data, is that deciding where the lines between subsystems, the interfaces, and the allowable parameters for those interfaces, is architecture.
PS- Just read the OP. Nothing actionable. Move along.
The title of the post, and consequently the HN submission, should say "Software Architecture". If you omit it, most people would think you're talking about bricks and buildings.
Every "architectural decision" I've ever seen has been wrong. It's always resulted in a worse product than simply writing the code and allowing the architecture to happen.
(This doesn't mean writing code with no layering, just deferring those decisions to the point where you actually have the code that makes use of them)
I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation. That's what (in my experience) most software architects do; lay down guidance and structure for the software engineers.
> The C4 model was created as a way to help software development teams describe and communicate software architecture, both during up-front design sessions and when retrospectively documenting an existing codebase.
> It's a way to create maps of your code, at various levels of detail, in the same way you would use something like Google Maps to zoom in and out of an area you are interested in.
This seems different.
I have no idea why you would refer to the a code diagram as your software architecture. That's literally the code level. How is that architectural?
It's like saying the circuit diagram in the plug should go on the house blueprint. "You should use automated tools for this" ... so, it's for documenting existing code bases at the per-function level?
How is that useful for architecting / designing / planning software?
That sounds like software structure to me, not software architecture.
Sure, a map of existing software that explains how it's structured sounds cool... but I dunno. Like, if you're talking about design patterns, you're not gonna give someone a function-by-function map of how to implement a singleton. They're not stupid. You'd tell them you think it should have a singleton (or repository, or whatever).
Software design is totally a thing, and this seems entirely reasonable for designing software.
...but software design and implementation and software architecture are not the same thing and they're not done by the same people, in my experience.
This feels more like... systems design, which a software architect would contribute advice to in the way that the systems were designed so they aligned with good software architecture principals.
That's like calling a bike shed "civil engineering". I don't know what point you're making with the term "software architecture" other than trying to make it sound burdensome.
> Engineers make dozens of architectural decisions every day.
> Two really key fundamental knowledge areas if you're goal is to build actually reliable and relatively efficient software.
I would challenge you on this, and suspect that you're looking at a relatively thin slice of developers: can you clarify why you believe this to be the case. As a counter-example, a lot of modern web development is building frontends (mobile or JS), where good code organization matters, but systems architecture doesn't matter so much.
Way off the mark. "Software architecture" is about how you make the disparate parts of a software system work together towards a common goal. Most of these parts aren't code: hardware, programmers, tech support, HR, licensing and legal, etc.
reply