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

131–140 of 303 posts

Re: Software Architecture Guide

#131

Post by extra_rice »

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 parts of the system, which could mean multiple redeployments of many different services. Also implies more complex integration (even e2e) testing.

Re: Software Architecture Guide

#132

Post by hyperpallium »

streetcat1 wrote: post #104
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?)…

Software engineering is engineering in the same sense the mechanical engineering is engineering. The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something . In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for exampl…

That is a valid argument if your concept of a mechanical engineer includes anyone who designs a machine; for example improvising levers, pulleys, gears to achieve some end.

I guess it is all "engineering" in a casual, tinkering sense. But a professional engineer, with a Mech Eng degree who uses mathematical models of stress and strain etc, who did lots of tinkering as a kid, might not agree.

Re: Software Architecture Guide

#133

Post by Ozzie_osman »

streetcat1 wrote: post #104
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?)…

Software engineering is engineering in the same sense the mechanical engineering is engineering. The only difference is that with software your materials are descriptions. I.e. you describe something, give to the computer and the computer turn itself into this something . In the end, there is a physical entity in the world (the hardware), which turned itself into a unique machine based on your description (for exampl…

I disagree. Engineering disciplines vary in how far removed they are from the underlying physics and how malleable they are. Building a bridge (or civil engineering) is very connected to the underlying physics. A set of equations give you the answers. It's also not malleable. You design it once, then build it, putting in some margins of safety to account for any variances in underlying material or potential usage, then it's pretty much not malleable.

Mechanical engineering is a little more removed. You have moving parts, interconnected pieces, wear and tear, etc. Now you have to lean heavily on preventative maintenance, ability to replace worn parts, etc.

Hardware is more removed. Software is even more removed. The laws of physics are there, but there are so many man-made layers of abstractions on top of it that "good architecture" is a lot less like what you'd expect in a typical engineering discipline.

Not saying any is easier than the other, just that they are very different disciplines.

Re: Software Architecture Guide

#134

Post by AnimalMuppet »

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…

I seem to recall something like the "rule of 10" - for every factor of 10 in scale, a new set of problems dominates. And, from experience, there's some truth to it.

Re: Software Architecture Guide

#135

Post by Ozzie_osman »

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.

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.

Re: Software Architecture Guide

#136

Post by dredmorbius »

Kortaggio wrote: post #82

The author's statement that "My view is that applications are a social construction" I think hints at a deeper truth, that while _code_ is run by machines, managing a _codebase_ is more like raising a plant in a garden and not like changing the oil in a machine. Reminds me of "A Codebase is An Organism"[1]. [1] https://meltingasphalt.com/a-codebase-is-an-organism/

See also: Conway's Law.

http://melconway.com/Home/Conways_Law.html

Re: Software Architecture Guide

#137

Post by atoav »

vikingcaffiene wrote: post #110
sidlls wrote: post #89

Earlier quoted context omitted.

Is this because what they've written truly works or is it because they've simply managed the same thing as the loudest engineer in the office, at larger scale?

Well HN knows a thing or two about the latter ;) It’s because I write better software in a team setting when I apply the techniques and philosophies of Fowler & Co. The biggest complexity in software is people. Coordinating them, navigating egos, and leveraging their experience levels. It’s a hard problem and the place where I see the most consistent system problems. IMO Fowler is just providing accessible common sen…

Interestingly enough this social factor is also the hardest to deal with in other scenarios (expeditions, film crews, multi-party-projects, ...)

Re: Software Architecture Guide

#138

Post by wpietri »

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…

You say this with a lot of bile, but I'm not sure where your opinions actually differ from Fowler's. He says right in the second paragraph that he's suspicious of the term "architecture" because it "often suggests a separation from programming and an unhealthy dose of pomposity."

I think keeping it simple and dealing with exceptions is great. And so does Fowler, I'm sure. But I've been doing that a long time and I've learned some lessons about what "simple" means, and how some ways of dealing with exceptions work well in certain circumstances, while others can seem appealing but end up being a mess.

Like you, I think high-church, prescriptive software is mainly a giant waste, a way for fast talkers to get big paychecks while performing oh-so-smartness. But that doesn't mean over decades of coding we can't learn anything about they ways we build systems.

Re: Software Architecture Guide

#139

Post by noobiemcfoob »

CraigJPerry wrote: post #122
noobiemcfoob wrote: post #112

Earlier quoted context omitted.

> 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.

Ah, noted. Thanks for the education.

Re: Software Architecture Guide

#140

Post by jsdalton »

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…

Is that 99% of software all the same? Like, have you really not observed huge differences in the readability of the code you encountered? Have you not found that sometimes it is painful (or close to impossible) to extend or build more features on top of a particular system, while other times it is quite straightforward, even a joy?

If your answer to these questions is yes, to what do you attribute the difference? How would you counsel a young software engineer or team? How can we write better, more maintainable software that still allows us to deliver features quickly?

Post reply on HN