Live data from Hacker News

Software Architecture Guide

martinfowler.com

281–290 of 303 posts

Re: Software Architecture Guide

#281
post #251

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…

I think there is some tribalism at play. Fowler and friends are writing about enterprise architecture. HN is probably more oriented towards startups which haven't yet reached that kind of challenges and constraints (and in most cases never will), and who feel superior to the dinosaurs. And then there is is the "computer scientists" who think software development should be based on proofs rather than experience and re…

The word enterprise is not included in the article, which makes it a generic article about architecture.

Experience and results are better then nothing. Where are the author's results?

Based on which project experience was the article authored? Without knowing such things, we can't distinguish what kind of outcome will the proposed ideas result in. After all, good results can be good on many dimensions.

Re: Software Architecture Guide

#282
post #279

Earlier quoted context omitted.

> Are you applying the principle of charity...? Well, when I read that passage, I tried to figure out what he might mean. And mostly I distilled it down to what I wrote: "clarity is more important than performance, and will usually lead to better performance". So even though he's lacking a lot of specifics, sure I think I get his meaning. > "That's basically exactly what Knuth said" No Knuth said "ignore small ineffi…

> clarity is more important than performance, But he does not say that! You are deliberately misrepresenting the meaning of the quote. He says he focus on clarity first and only optimize for performance if absolutely necessary. You can disagree with that, but it is a totally different thing. If you have legitimate disagreements which his viewpoints you should be able to state your argument without needing to misrepre…

I mean I quoted the entire 3 paragraphs up there, so of course I'm paraphrasing.

Fowler advocates strongly for OOP. Presumably he'd find an OO entity system clearer (if you're gonna quibble with this, imagine how much more productive this conversation would be if we had an understanding of what "clearer" meant, then recoil in horror as you realize thousands of developers are having this exact same unproductive discussion, all because one guy said he had the answers but didn't really give specifics, like Fermat's final theorem but for devs), but the fact remains that if you built a modern entity system this way you'd have to rewrite it to get even average performance out of it. No amount of refactoring will fix the base design.

So I feel like I have disagreed directly with his point, and I'm happy to discuss further. I do, weirdly, feel a little like you're not applying the principle of charity to me though. So let's both endeavor to be a little more understanding.

Re: Software Architecture Guide

#283
post #87

Earlier quoted context omitted.

Exactly. In fact, this thread looks like people cargo-culting what it means to be evidence-based (hint: life and work will always contain some reasoning and craft).

At this point it seems that there's more comments that start by saying "OMG HN is so negative about Fowler" than there are comments actually doing this. I have this working hypothesis that HN is a nexus where multiple alternative realities intersect, which is why I sometimes find threads with 5 comments complaining about HN negativity to one or zero comments that are actually negative...

Well, the cavalry comes in and soon outweighs the misguided negativity...at least in this thread. The negative comments were definitely outstanding.

Re: Software Architecture Guide

#284

Earlier quoted context omitted.

The "data" in this context is empirical data in support of the hypothesis that the man-month is mythical (aka adding people to a late project makes it later). You also need a control. Similar for other hypotheses, such as a "programming product" and "programming systems" take three times longer than a "program" (written by e.g. a garage duo). BTW Your "beyond me" was unnecessary. https://news.ycombinator.com/newsguid…

Thought I'd better check this. I went through the book's eponymous chapter 2 The Mythical Man-Month (p.14, 1975 ed), and it has not a single table; not a single datum. It has many graphs, without data points, and the text and their smoothness indicate they are graphs of functions, not data. I have a disturbing feeling that the downvoters in this thread simply don't know what it means to validate a mathematical model…

A philosophical book of essays about software from 1975 is not relevant for a set of recommendations on architecture 44 years later.

You are correct that chapter two lacks supporting evidence. And that's a problem for the book, it doesn't mean it's ok to omit data everywhere now.

Re: Software Architecture Guide

#285
post #233

Earlier quoted context omitted.

That's not at all the source of my negativity. Instead, I am confronted in my work with developers of different experience levels which justify their design and coding decisions based on what e.g. Robert Martin or Martin Fowler wrote in a book or blog. Some of these ideas, like "code should read like prose" or the obsession with unit testing are causing problems, such as making the code harder to follow or neglecting…

> unit testing [...] or neglecting other kinds of testing that are more effective Could you elaborate? (happens I come from a background where there is no kind of systematic testing, which is a bit of a downer) And 'PoC' = proof of concept? > which justify their design and coding decisions based on what wrote in a book or blog. Happened to me. We had an SQL-based product that ran like a dog. Much faster by the time I…

I was referring to system and integration tests. If a system has any kind of user interaction, user testing is essential.

Re: Software Architecture Guide

#286
post #262

Earlier quoted context omitted.

This is where I get confused. Are you criticizing a particular architecture, or architecture in general? Is it even possible to have a system without an architecture?

The Winchester Mystery House does exist in software somewhere.

Even the Winchester Mystery House has architecture. Pretty good architecture. It's still standing, in spite of earthquakes. She bought it in 1884.

Now it has some fairly odd "features" based on her very eccentric "requirements." Doors that open into walls. Stairs that "go nowhere." Very expensive windows that look out at brick walls.

But given her odd sense of "requirements," it's the house she wanted!

Re: Software Architecture Guide

#287
post #234

Earlier quoted context omitted.

Please detail your understanding of what philosophy is and how it resembles what such teams are doing. My gut feeling is that they're quite different, but I could be missing something...

I don’t reward sealioning.

All right, but if we take the standard definition of philosophy then your initial claim makes no sense.

The study of the fundamental nature of knowledge, reality and existence is unrelated to writing software.

Re: Software Architecture Guide

#288
post #284

Earlier quoted context omitted.

Thought I'd better check this. I went through the book's eponymous chapter 2 The Mythical Man-Month (p.14, 1975 ed), and it has not a single table; not a single datum. It has many graphs, without data points, and the text and their smoothness indicate they are graphs of functions, not data. I have a disturbing feeling that the downvoters in this thread simply don't know what it means to validate a mathematical model…

A philosophical book of essays about software from 1975 is not relevant for a set of recommendations on architecture 44 years later. You are correct that chapter two lacks supporting evidence. And that's a problem for the book, it doesn't mean it's ok to omit data everywhere now.

I seems to me that you and hyperpallium agree.

I still hold that

1.) That book is still one of the most relevant books I've seen lately (which might be scaring, I haven't made up my mind yet)

2.) While he might not have (or at least not include) data, he argues hos case well, and while I wouldn't bet money on experiments to follow his smooth curve I would be willing to bet (a small amount of) money that for non-trivial software his ideas would still result in better estimates than one that accepts "man-months" as a unit of progress.

And for those that haven't read the book yet it might be worth noting that while some people might find the book quotable more or less from cover to cover there is also a number of observations to be made that takes a full reading to realize. Here is one I'd like to point out:

Some quotes from the book might leave one thinking that he says programming cannot be scaled. I'd say the opposite is true, he just argues that it must be done in a thoughtful way instead of by mindlessly adding people to the project.

Re: Software Architecture Guide

#289
post #284

Earlier quoted context omitted.

Thought I'd better check this. I went through the book's eponymous chapter 2 The Mythical Man-Month (p.14, 1975 ed), and it has not a single table; not a single datum. It has many graphs, without data points, and the text and their smoothness indicate they are graphs of functions, not data. I have a disturbing feeling that the downvoters in this thread simply don't know what it means to validate a mathematical model…

A philosophical book of essays about software from 1975 is not relevant for a set of recommendations on architecture 44 years later. You are correct that chapter two lacks supporting evidence. And that's a problem for the book, it doesn't mean it's ok to omit data everywhere now.

I think it's quite clear from context that all graphs in Mythical Man Month are based on formulas and theory, not on double-blind experiments or empirical measurements.

Still, I often find it quite useful advice even for today's projects, where people commonly assume that they can put a late project back on track by adding people to it, and that by doubling the staff, the product will be produced twice as fast.

Re: Software Architecture Guide

#290
post #279

Earlier quoted context omitted.

> clarity is more important than performance, But he does not say that! You are deliberately misrepresenting the meaning of the quote. He says he focus on clarity first and only optimize for performance if absolutely necessary. You can disagree with that, but it is a totally different thing. If you have legitimate disagreements which his viewpoints you should be able to state your argument without needing to misrepre…

I mean I quoted the entire 3 paragraphs up there, so of course I'm paraphrasing. Fowler advocates strongly for OOP. Presumably he'd find an OO entity system clearer (if you're gonna quibble with this, imagine how much more productive this conversation would be if we had an understanding of what "clearer" meant, then recoil in horror as you realize thousands of developers are having this exact same unproductive discus…

> I do, weirdly, feel a little like you're not applying the principle of charity to me though.

Fair enough, we can all be guilty of that. What part of your argument have I misunderstood or misrepresented?

Post reply on HN