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

121–130 of 303 posts

Re: Software Architecture Guide

#121

Post by wincent »

gregdoesit wrote: post #14

I have been building large scale/distributed systems myself and reviewing designs of systems like these being built around me, for years now. I have never come across any of the type of ivory tower architecture that this post and other sofware architects write about. We're talking about real-world systems that are high-load and somewhat novel, with battle-scarred engineers building them. I find it ironic that that ma…

"I'm at the point where I'm serioulsly debating writing something more substantial on how actual software design works"

It's probably already been written; see the "Big Ball of Mud": http://www.laputan.org/mud/mud.html

Re: Software Architecture Guide

#122

Post by CraigJPerry »

noobiemcfoob wrote: post #112
CraigJPerry wrote: post #86

Earlier quoted context omitted.

> I think your criticism of 'at-will' employment There was no criticism of at-will employment in the parent post. That's a hair trigger you've got yourself there fella.

> In my country, which (thankfully) lacks America's "at-will" employment contract I'm sorry, is that not obviously criticism? My parser must be busted again.

No, it's not. Which is why I made my post.

Re: Software Architecture Guide

#123

Post by criddell »

2_listerine_pls wrote: post #103
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?)…

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.

That depends on what jurisdiction you are in. The title of engineer is protected in lots of places and the description of software engineer is very specific and effectively regulated. That is, a software engineer is licensed.

Re: Software Architecture Guide

#124

Post by dingoegret »

geofft wrote: post #20
streetcat1 wrote: post #18

Earlier quoted context omitted.

So first, you should read their books for concrete code. Martin books, for example "refactoring" or "Enterprise architecture" actually have good code examples. The same apply for kent beck early work on smalltalk (you can look at Junit) or his early work on the HotDraw editor (which was the source of many of the pattern in the Design Pattern book). Kent was one of the first adopter of smalltalk at the early 80 is tec…

The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of thing…

I feel like this enthrallment to studies is unhealthy and unproductive for discussion. Studies is not a synonym for truth. I could explain the limitations of studies and the historical errors they have contributed to, but I think that would be patronizing as most people on HN have discussed this ad nauseam.

Also I think summoning evidence without specifying the details of the evidence you're seeking is extremely unhelpful. It just shuts down progress in a discussion. Some actions require hard evidence because the price of error is too great, but this isn't a court room and we are just floating ideas about a craft that is hard to quantitate. I understand your attitude. A lot has been written about software practices and rarely if ever is any of it backed up with data points.

Re: Software Architecture Guide

#125

Post by mjburgess »

mrkeen wrote: post #65

Martin Fowler: "Architecture is hard to define, but I'll try. Good architecture allows the system to evolve. Bad architecture attracts cruft and makes change hard." HN: "Fuck this ivory tower bullshit! Where's the evidence?!?!"

My objection is the "ivory-tower bullshit" is wrong.

He goes to pains to fail to define architecture and rejects a reasonable definition for a confused genetic fallacy about social construction.

"Architecture" isn't understanding. Understanding is of Architecture. If architecture were merely "the common understanding of what's important" there could be no disagreement or understanding of the software. Disagreement would be hopelessly social: you could never say "this is too complex", but only, "your understanding is wrong".

> "My view is that applications are a social construction"

Deeply confuses many issues. Applications are made by people, as are tables, but neither are "social constructs" -- which mean they are irreducibly subjective group phenomenon.

Software runs on machines. The running machine isn't a subjective group phenomenon. "1 + 2" is code, mathematics isn't a "social construct".

"Architecture" refers to the structural elements of a domain (ie., how the domain objects are related to each other, and how these relations are related to each other, etc.).

It is a relative term, but not a subjective one. eg., The "architecture" of a animal is how its parts fit together. The "architecture" of a leg is its pieces fit together. And so on.

Re: Software Architecture Guide

#126

Post by MiyamotoAkira »

neya wrote: post #95

People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DD…

2015: https://www.martinfowler.com/bliki/MonolithFirst.html

Re: Software Architecture Guide

#127

Post by dwaltrip »

crimsonalucard wrote: post #107
notus wrote: post #41

Earlier quoted context omitted.

SICP isn't going to teach you excellent architecture for large systems, it's going to teach you excellent architecture for small programs.

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 designs would start performing poorly at scales that are still relevant to human concerns

This shouldn't be surprising. Most things (nearly everything?) that we care about are not scale invariant.

Re: Software Architecture Guide

#128

Post by sooheon »

neya wrote: post #95

People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DD…

What I find interesting about this anecdote is that if you give DDD proponents the benefit of charitable interpretation, they may genuinely have had your exact same journey in reverse.

Maybe there is an inversion of the duckling imprinting phenomenon in software, where everyone hates the first terrible architecture they write, and when they finally get it right through lessons learned, preach that as The Way.

Re: Software Architecture Guide

#129

Post by [deleted] »

MiyamotoAkira wrote: post #126
neya wrote: post #95

People have asked for evidence on this thread, so let me share my experience. A couple of years ago, I was developing an E-Commerce platformm internally for my company. I follow Martin Fowlers' articles on using DDD (Domain Driven Design) and Microservices to architect applications. What should have been a month long project took us 8 months! I'm not including the time I took to read about, understand and practice DD…

2015: https://www.martinfowler.com/bliki/MonolithFirst.html

[deleted]

Re: Software Architecture Guide

#130

Post by reallydude »

bradleyjg wrote: post #109
Scarbutt wrote: post #79

Earlier quoted context omitted.

There is a small gap in this reasoning: that something is written down and sounds like a good idea doesn't make it a good idea. That's his point, doesn't matter if is a good or bad idea, but that someone took the time to sit down to think through, write and publish some ideas that will give developers a new perspective on how to do things that they would never thought about, whether those ideas are good/bad, apply or…

Suppose we weren't software engineers, but instead bridge engineers or physicians. Would you then accept "someone took the time to sit down to think through, write and publish some ideas" that we could either take or leave depending on how persuasive a writer the author happens to be? I think it is entirely reasonable to ask "what reason to we have to think this is good advice"?

Perception, Comprehension, Analysis, Publication repeat.

Somewhere in there, it's doesn't matter if it's "advice" or whatever you want to call it, as long as it's shareable elucidation you can apply your own reasoning...but if you don't bother to follow the pattern, it doesn't matter what you think. Asking someone else to have done these steps for you, is a proxy for a lack of interest, imo. Everyone wants to be lazily told things they either already know or can agree with easily, but being critical in a constructive way is work.

Post reply on HN