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

Software Architecture Guide

martinfowler.com

Post reply on HN
Print view View original

151–160 of 303 posts

Re: Software Architecture Guide

#151

Post by lemmsjid »

Spearchucker wrote: post #11

Oh man. Another diatribe from Martin Fowler™. Takes me back to the 90's when I was in awe of teh architectures and architects, understanding of which was always just beyond my grasp. 99% of software I've encountered has some kind of interface, a domain it operates in, and data it operates on. Call these three things layers. It also has some cross-cutting things that are universally available in the software - broadly…

Having similarly done software in that time period, your reductionist argument flies in the face of my own experience, where there are actually tons of nuance within what you are correctly identifying as typical macro patterns. When I look at Fowler's repository of EA patterns (https://martinfowler.com/eaaCatalog/), I see a ton of time tested patterns that are, to this day, used in a tremendous amount of software. They are so prevalent that they are typically abstracted into frameworks or libraries that are then used by people building line of business applications.

Something I have always appreciated about Fowler has been his workman-like, semi-anthropological approach to documenting these patterns. He does not claim ownership to them, but instead discovers and names them out of working software. He does have a playful opinionated-ness to his writing, but that is really only to spice things up, as far as I've seen (in other words, he has been quite willing to modify his own positions over time).

Perhaps to your point, I have seen people read these books and suddenly wish to apply all the patterns at all the times to all the software, resulting in an ill conceived amount of complexity. That, to me, is why a healthy software development team needs senior developers who have been around the block on this sort of thing. And why the agism in the industry is so poisonous and counterproductive. A healthy team needs healthy defenses against the forces of over complexity (and, equally, over simplicity), and because of the tremendous amount of abstraction in software engineering, experience, erudition and mentorship can bring that to a team.

Re: Software Architecture Guide

#152

Post by vikingcaffiene »

wpietri wrote: post #142
vikingcaffiene wrote: post #71

I gotta say I am surprised and a little disheartened by all the negativity around this post and Fowler in general. Fowler's writing has been a huge inspiration to me in my career. I'm about to gift a copy of his book "Refactoring" to one of the junior engineers I work with for instance. I think the idea of an architecture as a social construct is very fitting. Software is hard when multiple people are working on it w…

Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If I hadn't been exposed to their ideas, I surely would have left software by now. Over and over, my experience was building something that slowly got less tractable over time, where eventually we'd just want to do a big rewrite. It sucked! I had tried the big-desig…

Thanks for taking the time to write this. I really hope that the latest generation of developers don’t see all the negative HN hive mind comments and discount writings like this.

Re: Software Architecture Guide

#153

Post by eitland »

hyperpallium wrote: post #91
Ozzie_osman wrote: post #66

Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this…

Yes. And Computer Science is not a science, and Software Engineering is not an engineering. Guides to it are more like guides to writing. Strunk and White , where is your empirical data? What's your control? Where are your PDE's? Some also have aspects of business productivity books, with well-known common-sense ideas, like In Search of Excellence (which made up case studies, and a co-author said what's the problem?)…

> Even Fred Brooks' Mythical Man-Month - informed by his leadership of the massive bet-the-company "360" project at IBM - lacks data. It's still great though (in, uh... my subjective opinion, I guess).

I have just read that book.

It is the computer book with most tables pr page of any I have seen.

How you come to this conclusion is beyond me.

Re: Software Architecture Guide

#154

Post by jbmsf »

extra_rice wrote: post #131
jeswin wrote: post #98

I looked at this thread a while back and closed the window, hoping that those early comments don't influence the younger practitioners who are on HN. As someone nearing 40 (mainly doing consulting work around boring business apps for a long time), my view is that Martin Folwer's biggest contribution is indeed the documentation, and defining the vocabulary to enable discussion around frequently encountered (but perhap…

I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple…

I'm definitely guilty of using and promoting anemic models. I find that teams have a hard time deciding whether logic is service or domain or whatever and gravitate towards putting everything in one place if domain objects are allowed to be at all smart. On the other hand, people do well with the rule that logic belongs in procedural layers with clear names and some sort of maximum size/complexity.

I also find that these discussions matter less in microservices because the size of each service is so small that you usually don't need more than two layers: one for business logic and one for persistence.

I very much agree that microservices create their own challenges at service interfaces, but since these boundaries are usually expressed as http operations instead of object oriented function calls, I look for different solutions, especially various forms of system-wide introspection and testing.

Re: Software Architecture Guide

#155

Post by eitland »

Ozzie_osman wrote: post #135
2_listerine_pls wrote: post #103

Earlier quoted context omitted.

Engineering is the application of science. A civil engineer uses laws regarding compression, stress, etc... to build its buildings. If you apply scientifically derived principles when building software then You are a software engineer.

I'd love to see what those scientifically derived principles are. If I'm building a bridge, there are equations based on physics I can use. Like I mentioned in a separate thread, software is far more removed from those physics.

While not exact physics we have plenty of real world constraints that we skillfully (or not) work our way around or use for our advantage, here are two :

- Amdalhls law

- Moores law

Re: Software Architecture Guide

#156

Post by proc0 »

hyperpallium wrote: post #91
Ozzie_osman wrote: post #66

Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this…

Yes. And Computer Science is not a science, and Software Engineering is not an engineering. Guides to it are more like guides to writing. Strunk and White , where is your empirical data? What's your control? Where are your PDE's? Some also have aspects of business productivity books, with well-known common-sense ideas, like In Search of Excellence (which made up case studies, and a co-author said what's the problem?)…

"Engineer" Origin: Middle English (denoting a designer and constructor of fortifications and weapons; formerly also as ingineer ): in early use from Old French engigneor.

Also shares same root as Engine I assume. Engineers are experts in system building or some kind, the earliest being weapons, then transportation, etc.

Software Engineer is 100% an engineering role IF you are making what could be called a kind of engine. Prime example is working on a game engine's source code, and design (i.e. Unreal, Unity...), or working on a custom operating system. I've seen many people try to downplay how much software has these "engine-like" properties, where you have to pay attention at the "moving parts" (runtime), and those people simply don't see the invisible machine that's doing the work.

Re: Software Architecture Guide

#157

Post by proc0 »

EdwardDiego wrote: post #59

> All I see is yet another reasonably sounding yet unsupported piece of folklore. Another artefact of the fact that software developers are still craftspeople - as in "someone skilled at making things by hand". Software development output is something that no-one has yet successfully quantified. There's no easy metric to assess a non-productive software developer from a productive one. We can all tell the difference,…

Of course it can be quantified otherwise hiring based on skill level for a software role would be impossible. You can look a examples of code and know someone's level and then deduce their performance based on output and quality of code. The problem is NON-technical people are the ones who want to quantify your performance! Which has been my problem for years in the software industry. If you haven't written code in years, you will be lost as to whether I'm writing good software or not, yet these are the people who rise to the top to manage the technical people and then do a horrible job because they have no idea what to optimize for.

Re: Software Architecture Guide

#158

Post by blub »

Ozzie_osman wrote: post #66

Lots of hate in this thread.. People asking for proof: what sort of evidence would convince you? I take these blog posts, apply it to my experience, and take what I think makes sense. Sometimes, an idea will solve an obvious pain I've had. Sometimes, an idea will show me a pain I didn't know I have. Sometimes I disagree with the idea because it won't work for me. That's fine. I'm still much better off thanks to this…

If you want to see how a properly referenced text looks like, pick any of the following:

* Code Complete - McConnell

* The Economics of Software Quality - Capers Jones

* Facts and Fallacies of Software Engineering - Robert Glass

* Making Software - Oram & Wilson

... and there are many others. Not all references have survived the test of time, L. Bossavit describes in his book " Leprechauns of Software Engineering" how several software development "facts" are in fact myths.

The approach you suggest suffers from a chicken & egg problem because you first have to be experienced enough to be able to evaluate such reference-free content, as the blog written by Martin Fowler. It's precisely the inexperienced that are likely to internalize such advice and perpetuate personality cults.

Your objections are invalid; one does not need to be better at a task than an individual in order to criticize them. Asking for references and proof is perfectly legitimate, at least if we want to approach our discipline more as engineering and less as "Strunk & White" as someone comically suggested in another comment.,

Re: Software Architecture Guide

#159

Post by snorkasaurus »

proc0 wrote: post #156
hyperpallium wrote: post #91

Earlier quoted context omitted.

Yes. And Computer Science is not a science, and Software Engineering is not an engineering. Guides to it are more like guides to writing. Strunk and White , where is your empirical data? What's your control? Where are your PDE's? Some also have aspects of business productivity books, with well-known common-sense ideas, like In Search of Excellence (which made up case studies, and a co-author said what's the problem?)…

"Engineer" Origin: Middle English (denoting a designer and constructor of fortifications and weapons; formerly also as ingineer ): in early use from Old French engigneor. Also shares same root as Engine I assume. Engineers are experts in system building or some kind, the earliest being weapons, then transportation, etc. Software Engineer is 100% an engineering role IF you are making what could be called a kind of eng…

Or in a non-medieval context, an engineer is member of a professional association of engineers whose rights and responsibilities are legislated. And imo, anyone who calls themselves an engineer but isn't a member of a professional association of engineers is misrepresenting themselves.

Re: Software Architecture Guide

#160

Post by crimsonalucard »

dwaltrip wrote: post #127
crimsonalucard wrote: post #107

Earlier quoted context omitted.

The design of small programs is isomorphic to the design of large programs at all levels. You're just referring to real world caveats and details, but the overall concepts taught in SICP apply to all layers of programming from assembly to the architectural level. Small programs: Q = A -> B W = B -> C R = C -> D T = D -> E Large Programs L = W . Q K = T . R Architecture M = L . K The above description works at every l…

> The design of small programs is isomorphic to the design of large programs at all levels Good software design is not scale invariant. Significant scale deltas change things in fundamental ways. Designs that work and are maintainable, from a human perspective, at one scale often will fail at a larger scale. Some designs scale better than others, this is true. But no design scales infinitely, and the vast majority of…

The concept of abstraction and process IS scale invariant.

What is not scale invariant is the real world details like I mentioned above.

1. What assembly language instructions a language compiles to

2. Network latency / topology / etc..

Scheme or other programming languages hides real world detail #1 so we don't have to deal with it (as much).

While there is a lot of work done for #2. we currently do not have as good abstractions for #2. as we do for #1. Therefore usually a programmer must exit the abstraction and deal with the real world issues. Hence the confusion. You usually don't have to deal with assembly language or even know about it because a good abstraction exists but you do have to deal with "network architecture" and know about it because no good abstraction exists (yet). This is what is actually going on. You are dealing with real world details because those details change. But the concepts of abstraction that SICP talks about remain invariant.

That being said my statement about SICP is correct. My diagram that illustrates abstraction and design from a high level point of view the way SICP does is correct. Even with real world details in mind there is nothing about my diagram that is incorrect. The diagram I drew IS scale invariant. SICP teaches such concepts and is thus in itself a good book that is also "scale invariant."

If you feel there is something about that diagram that is incorrect please point it out. If you can find a flaw without going into lower level details like network topology or assembly language then you can prove my statement definitely incorrect. But as such my statement is correct and the diagram is still correct.

The ideal is to come up with a language that can compile down into both applications and a network of computers with minimal leakage. The concept of abstraction that SICP introduces remains applicable to all layers even if we currently lack the technology to stay within the abstraction.

I think what's going on is you're just mistaken. You think that abstraction is not scale invariant simply because of the way we deal small programs and large programs is different. Actually it's the same, we just don't currently have the tech to hide the details for large architectures like we do for small architectures... work is being done on this front though... Terraform, docker, cloud computing all these things move it in the right direction but we don't yet have an abstraction over this area like we do for single applications.

This does not mean it's impossible. Who's to say I can't write an entire web app in one language and it compiles down to server app, networked physical servers, cache and database automatically? This is a very viable architecture. Why not let a compiler tune network topology like it tunes assembly instructions? Of course, it's not viable yet, but definitely in the realm of future possibility.

Post reply on HN