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

161–170 of 303 posts

Re: Software Architecture Guide

#161

Post by blub »

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…

You're completely off-topic. Nobody's mentioning CQRS or anemic models.

This is an article about architecture with zero references to other authors, studies or proof of any kind. It presents several graphs without any supporting evidence.

=> it's absolutely normal to request evidence for those claims. This is software engineering, not software literature, where we try to guess what the author meant and marvel in awe.

It's exactly the younger practitioners on HN which should ignore such articles and demand properly supported texts.

Re: Software Architecture Guide

#162

Post by jonbronson »

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…

Thank you for writing this. As an engineer reading these style of articles, I've witnessed two common reactions: Either the content resonates, and our eyes widen at the site of a simplified and intuitive explanation for phenomenon that we've somehow already observed, or... it doesn't. And maybe that's the source of much of the negativity we're seeing. These engineers haven't worked in domains, projects, or organizations where they could encounter how these lessons play out, and so they're dubious about the whole thing. One reaction to being in that position is to downplay the author and complain about lack of 'evidence'. The other, is to put down our egos, and consider that maybe we're just not there yet to appreciate what the author is trying to tell us.

Re: Software Architecture Guide

#163

Post by blub »

cliffcrosland wrote: post #143

Reading an enumeration of architecture options can be helpful, but I've probably found more value in works like Ousterhout's "A Philosophy of Software Design" that cover fundamental design principles. Such principles seem to be applicable no matter the project. I appreciate that Ousterhout tries to support these principles with some data from his own experience (building Tcl, RamCloud where Raft consensus was discove…

Yes, "A Philosophy of Software Design" is brilliant, precisely because the author supports their statements through the many experiments they performed with students and

The fact that they're the author of a well-known piece of software helps, although we should not use this as the main criteria to evaluate a text.

Offering at least evidence based on experimentation is essential if we want to move past personality cults and having entire teams work based on what someone wrote on a blog somewhere.

Re: Software Architecture Guide

#164

Post by ori_b »

netsensei wrote: post #116
ori_b wrote: post #96

Earlier quoted context omitted.

> I think the answer to your question would be Yes, that's the problem. The pixels spent here are based on hypothesis, not experiments. You think one thing, I think something else, and not a joule of effort is spent measuring.

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?

Re: Software Architecture Guide

#165

Post by temac »

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?)…

> Software Engineering is not an engineering

For those who refuse to practice engineering, casting that self-fulfilling prophecy over and over instead, yes, what they call "Software Engineering" is not engineering.

They are tons of people who practice Software Engineering as proper engineering for decades, as most people (everybody?) should do.

At least take an other word if you want to designate your practice related to software development that is not engineering, and define it in detail.

Re: Software Architecture Guide

#166

Post by jammygit »

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 at tech companies

If you need a little push to do so... I dare you

Re: Software Architecture Guide

#167

Post by jammygit »

proc0 wrote: post #157
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 y…

The standard practice is to quiz based on algorithms and data structures. How is that quantifying anybody’s performance? I knew a smart young algorithms guy once who could solve anything, but he still liked storing all his data in the global scope until he was told to stop it.

Re: Software Architecture Guide

#168

Post by proc0 »

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.

That's like saying no one can be an artist because they're not a member of the official artist club. I'm sure the term engineer outdates any professional association.

Re: Software Architecture Guide

#169

Post by snorkasaurus »

proc0 wrote: post #168
snorkasaurus wrote: post #159

Earlier quoted context omitted.

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.

That's like saying no one can be an artist because they're not a member of the official artist club. I'm sure the term engineer outdates any professional association.

Actually it's just being respectful. I'm not an engineer, but I work with a lot of engineers who actually have the qualifications to call themselves engineers, so if I call myself one, I'm essentially lying.

Re: Software Architecture Guide

#170

Post by Barrin92 »

blub wrote: post #158
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" 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 craft. The tools differ from person to person, each piece of software is different, a lot of practises are learned and tacit and transmitted from one pracitioner to the next.

Writing code is more like being a blacksmith than being a scientist, as much as people yearn for formalistic answers and peer reviewed studies so that they can have the appearance of objectivity, a lot of software development is fundamentally subjective.

Post reply on HN