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

171–180 of 303 posts

Re: Software Architecture Guide

#171

Post by jammygit »

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…

I find Fowler writes/speaks more clearly about topics than anybody else. A few of these topics like refactoring or RESTful design have been very helpful for me.

Re: Software Architecture Guide

#172

Post by geekone »

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.

Looks like it is criticism of America's "at-will" labor laws to me too.

Re: Software Architecture Guide

#173

Post by netsensei »

ori_b wrote: post #164
netsensei wrote: post #116

Earlier quoted context omitted.

Ah yes, that would be Karl Popper's concept of Falsifiability of a hypothesis. https://en.m.wikipedia.org/wiki/Falsifiability That's what we are debating here: is this claim that use of UML is always markedly better when modelling any problem domain is true as observed through a sufficient number of data points? I'm poking holes in that hypothesis because there's always n + 1 conceivable use case where the opposite i…

> I'm poking holes in that hypothesis because there's always n + 1 conceivable use case where the opposite is true. And it's conceivable that the sun will not rise tomorrow, or that the law of gravity will pass an inflection point and reverse itself. Also based on "set theory and computational algebra", and the impossibly of testing each possibly. What's your plan for tomorrow, and does it depend on gravity?

I'll take logical fallacies and rethorical devices for 200, Alex.

Re: Software Architecture Guide

#174

Post by crimsonalucard »

sooheon wrote: post #120
crimsonalucard wrote: post #85

Earlier quoted context omitted.

I agree with you. There's another angle to look at it though other then "evidence based" or scientific. In the field of engineering a large portion of it has to do testing to verify systems that are unpredictable or not modelled by theory. For example: building a plane involves testing it a wind tunnel. The thing with computer systems is that computers are deterministic math machines. You don't need to test a compute…

> He treats this stuff like it's 100% art Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's. Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".

>Is this true? I'm just picturing in my mind juxtaposing Fowler's writings and I dunno, an art critic's.

He does. The language is different. He uses technical buzz words from the tech industry rather then the jargon from the art industry.

A paper with science will have data and statistics. A paper with logic will have formal descriptions, axioms and theorems. Martin Fowlers papers contain little of any of these things.

>Category theory is cool and important, but to insinuate that all design problems can be "derived" by it sounds like a mathematician declaring that the work of all civil engineers as just "applied math".

I never said that all solutions can be derived from category theory, I meant that the current state of category theory hints at a possibility that this could be possible in the future.

Civil engineers do a lot of similar things to what a proper Software architect should do. They use science, theory and art to materialize their ideas. I'm saying category theory COULD be pointing at way of making that "art" section smaller or eliminating it all together. Though total elimination is IMO unlikely I think making it much smaller is very viable. This process is even more amenable to computing systems as the solution space is much smaller. For computing systems, I think it's more reasonable to say that it may be possible in the future for "art" to be completely eliminated from this field, still unlikely imo, but definitely more likely then other types of engineering.

Re: Software Architecture Guide

#175

Post by temac »

snorkasaurus wrote: post #159
proc0 wrote: post #156

Earlier quoted context omitted.

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

Highly depends of your region. In France being an "engineer" means having an official Engineering Degree, or simply occupying an engineering position (the degree is not strictly necessary, you can have another one or even none at all).

The common ground of engineers throughout the world is more simply that they practice engineering... (and yes, this has a meaning -- managing requirements and developing in accordance to business values and economics comes to mind -- and yes, this can be applied to SE, and this is even quite "simple" to apply, at least this is not more difficult than for any other field)

I don't really see why some people pretend all the time that SE is different or young and it is not proper engineering. I never read a convincing argument about why it should be so. Of course they are differences but they also are differences between other fields.

Re: Software Architecture Guide

#176

Post by jammygit »

wincent wrote: post #121
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

> While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

>These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

Interesting!

Re: Software Architecture Guide

#177

Post by goostavos »

mobjack wrote: post #81
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…

Software development is as much of an art as a science. Personally I've seen people double down on bad design decisions early in a project that becomes major pain to deal with later on. It is easy to see that if they spent a little extra time on quality in the beginning it would pay off in a few weeks or even sooner. I also see others spend too much time trying to be perfect in the beginning and nothing ever gets del…

>need to use judgement

I'd put this as the only real Golden Rule of software development. There is so much blind cargo culting around best practices / code / architecture in our industry that, with some engineers, human judgement seems to have been replaced with someone else's paint-by-numbers rules. Sometimes, man, it just makes sense to take a step back, look at what you're actually building, and ask what makes sense _for this case_. Sometimes the stupid thing is the best option. Sometimes it's not. Judgement should trump all else.

Re: Software Architecture Guide

#178

Post by temac »

Ozzie_osman wrote: post #133
streetcat1 wrote: post #104

Earlier quoted context omitted.

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, th…

Your layering does not really have practical consequences that would matter to exclude a field for engineering. Plus you are focusing on the technologies, and while this is important this is really not what distinguish an engineer from a non-engineer technician (even an extremely skilled technician), and that part have way more things in common regardless of the field.

Re: Software Architecture Guide

#179

Post by blub »

Barrin92 wrote: post #170
blub wrote: post #158

Earlier quoted context omitted.

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" ho…

>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 Software development, as often as comparisons are made to engineering or science is neither. It's a…

Software development does have a certain Darwinian character - whatever survives and thrives can't be wrong.

Embracing this seems misguided, because as software becomes more complex, it's no longer enough to have software blacksmiths banging away with their software hammers and unit testing the end result into a releasable shape.

Teams working on high-availability, high-reliability software know this and take a rigorous approach. Too many take the BDD approach (blog-driven development) and when the thing inevitably falls apart, the customers pick up the broken pieces.

Re: Software Architecture Guide

#180

Post by camgunz »

stephen wrote: post #145
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…

Fancy new names is basically the antithesis of Fowler's approach (it's driving shared language/canonical definitions). And personally in the mid-2000s I found Fowler's material to, contrary to your assertions/experience, actually be a source of simplicity (by at least explaining pros/cons/alternatives in a comprehensive/vendor/platform agnostic manner) vs the other "just run this huge EJB server, np!" approaches ther…

I have what I feel like are cultural disagreements with Fowler (e.g. "Enterprise Architecture" is oxymoronic to me) so adjust for my bias accordingly. But perhaps his most famous book is "Refactoring", where he gives (fancy, new) names to things he found in the wild. It's basically what he does and arguably his most influential contribution to the industry.
Post reply on HN