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

181–190 of 303 posts

Re: Software Architecture Guide

#181

Post by WalterBright »

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…

Much programming is more art or craft than engineering.

For example, what separates a mechanic from an engineer? They are often working on the same project, and appear to be doing the same thing. In my view, a mechanic follows rules of thumb, eyeballs a design, etc. An engineer applies math and derives design, or checks the design using math. A mechanic will say "this beam looks thick enough to hold the load", and engineer can do a calculation to select the correct thickness for the load.

For software, a programmer can tell you that quicksort is faster. An engineer can tell you why it is faster, and be able to calculate how much faster it is.

Re: Software Architecture Guide

#182

Post by crimsonalucard »

streetcat1 wrote: post #99
crimsonalucard wrote: post #93

Earlier quoted context omitted.

Software development doesn't need to be an art and it doesn't need to be a science either. By science I mean using data and statistical evidence to drive development, by Art I mean using your gut and your intuition to drive development. A computer is a deterministic system. It is 100% predictable and follows an exact set of rules. Software development is amenable to proof, logic and theory. You don't need to make dec…

> The thing with Object Orientation is that it has no basis in theory or science and is almost 100% art. Absolutely incorrect. The data part of OO is based on set theory as formalised in the database design research and type systems. The dynamic part of OO is based on finite state machines. The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - h…

>Absolutely incorrect.

I said OO didn't have basis in theory or science. By basis I mean it wasn't derived from theory. Rather it was created as more of an "artistic" endeavor and later it was fit into a framework of an existing theory. You should know almost ANY system can be broken down to fit into an existing theory from a projectile object, to a flying plane, to the weather, to an object oriented programming language. Thus following that line of thought ANYTHING can be a part of a theory but I use the term "basis" to emphasize that something can be derived out of theory.

>The data part of OO is based on set theory as formalised in the database design research and type systems.

I highly disagree. Type systems are not exclusive to OO, additionally the OO type system allows for mutation which is basically not at all part of set theory at all. Also type systems and database systems didn't formalize set theory. Set theory comes from mathematics.

>The dynamic part of OO is based on finite state machines.

This I can agree. A state machine modifies a change of state which is closer to the definition of an object in OOP.

>The data abstraction and information hiding part is based on the work of barbara liskov (for which she won the Turing award) - https://en.wikipedia.org/wiki/Barbara_Liskov

This has more to do with the type system then it does with OOP. Also note if you read the paper. Her paper has no data, statistics, formal theory, rigor, theorems, proofs or axioms. So although she won the turing award, although this is a research paper... it is largely "artistic" in the sense I defined it. See the paper here:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136...

Note that her paper is important, I am not discounting it. But it is largely more in the realm of design then it is in the realm of theory and science.

Re: Software Architecture Guide

#183

Post by mlthoughts2018 »

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…

The rampant semantic games about art vs science vs engineering vs craft littering this thread are nauseating. It’s all of those things in different contexts and situations, and regardless, seeking evidence backed advice is the right thing to do no matter what context you’re in.

My electrician father doesn’t base his craft on thought leading blogs. He has actual textbooks on electrical equipment, and guides with examples on using tools and solving certain common problems, full of reference material to other books.

I happen to think software is something like 70% craft, 25% science and 5% art, and to me this suggests not putting much stock in armchair blog opinions (and yes that includes Fowler’s) and instead seek scientific or data-backed analyses, even for craftsmanship such as any of the references in the comment above yours.

Re: Software Architecture Guide

#184

Post by camgunz »

Ozzie_osman wrote: post #117
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…

Your point on vocab is so spot on. Simply identifying something as a pattern and naming it is tremendously valuable. Doing it in a way that's packageable and shareable with others is not easy at all.

Agree, but people tend to stop at Fowler and live it as gospel. There is a profound richness in the different ways to think and talk about computers, engineering, and information science, far more wonderous than any one person can catalog. Read SICP, Knuth, Code Complete, Codd. Hell, just YouTube around. If your vocabulary is prescribed by literally one guy in a fedora, you gotta get out there. Might I suggest Joe Armstrong [1] :)

[1] https://youtu.be/lKXe3HUG2l4

Re: Software Architecture Guide

#185

Post by hutzlibu »

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"

He did not say that. He said, that he wants concrete criticism, what ideas are wrong and if possible, why ...

Re: Software Architecture Guide

#186

Post by Rainymood »

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?!?!"

Drew Houston: "Hey guys I made this thing called Dropbox"

HN: "But we have rsync?!?!"

Re: Software Architecture Guide

#187

Post by atoav »

blub wrote: post #179
Barrin92 wrote: post #170

Earlier quoted context omitted.

>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 rigor…

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

I am not sure of that. A lot of what we see today is just adding an abstraction on top of other abstractions. People use five frameworks for a static webpage that could have been easily made in half a day using editor, css and html without ever writing a single line of javascript.

In a evolutionary sense it works for them, but the reason isn't that html and css wouldn't also work, the reason is that they believe they have to use it.

So I'd be careful with the darwinian comparison here, this is more a mimetic or meme-like evolution of ideas and once the layer below is abstracted away it is quite easy to just forget about it alltogether.

Re: Software Architecture Guide

#188

Post by meowface »

sooheon wrote: post #128
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.

Exactly. That's what this breaks down to a lot of the time. A huge portion of software design, and discussion of it, is a lot more psychological and a lot less empirical or objective than it may appear. That's why you still see people at each other's throats pretty much every day on reddit and HN over pretty much every software design debate ever. (And software usage debates are even worse.) Their method is optimal and their opponent's is terribly overengineered or underengineered.

People like to cling to their preferences, and prefer what they've moved away from when they were less experienced and skilled, or what people they respect use, or what happened to catch their fancy or fascination years ago, or just what makes them subjectively feel good. You see the exact same kind of thing in other disciplines, including artistic fields, and the exact same kind of discussion board vitriol and cargo culting.

The nice thing is you at least get exposed to a lot of perspectives. If someone were to read only 1/4 of the posts in this thread, they may be convinced to take some kind of hardline position and find themselves down a narrow path. But if they read every post, they can take it all in and understand how much vehement disagreement and fuzziness there is, and be more skeptical and critical about the right or wrong way to do things.

Re: Software Architecture Guide

#189

Post by neya »

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

I remember this article very well. When it was published, it was too late as we were already following his articles on DDD before that. This is what I meant when I said the authors said we were doing it wrong. This was published after realizing a lot of people who took these authors' advice and went down the DDD path weren't happy and shot themselves in the foot.

Re: Software Architecture Guide

#190

Post by meowface »

billfruit wrote: post #29
jmartinpetersen wrote: post #24

Earlier quoted context omitted.

Robert Martin seems to cherry pick stats and trends and whatever that fits his world view. In Clean Architecture he cites a study with N=1 as proof TDD works. I have no hope for him.

I generally dislike building arguments on top of statistics, rather than on theory which to my eye almost always looks more convincing. With statistics it is as if the burden is passed on to the reader to check the veracity and validity of the said numbers, where as if it is an argument constructed out of theory, the whole of it is present there for the reader to judge intrinsically on its own merits.

Ideally you'd have some of both.
Post reply on HN