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

61–70 of 303 posts

Re: Software Architecture Guide

#61

Post by EdwardDiego »

chrisseaton wrote: post #8
blub wrote: post #7

Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutiniz…

For some of these speakers, I’ve literally never seen any evidence that they’ve written a single line of code. Why should we listen to Fowler? What large successful projects has he created using his ideas are there that I can look at? Where’s the data behind his slides? It’s all just talk talk talk. I’d listen to someone like Chris Lattner talk about how to design and write software because I can see whatever approac…

https://github.com/unclebob might be a good place for you to start. Fitnesse is probably the biggest one on there.

You can't really hold the fact that most of his working life has been for closed source orgs against him.

Re: Software Architecture Guide

#62

Post by mrkeen »

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…

Would you expect your writing to be received any differently?

Re: Software Architecture Guide

#63

Post by tootie »

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…

As far as I understand Fowler's posts, it's mostly about distilling best practice and ways of thinking. I haven't seen anything advocating anything more complicated than what you're describing. I've seen a lot of enterprises that don't do any of this. Ball of Mud is still pretty prevalent.

Re: Software Architecture Guide

#64

Post by tootie »

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've worked in both a big IT orgs and consulting and the Ivory Tower Architecture people are 10X more prevalent in IT orgs. They're the ones who establish architecture review boards and request extensive documentation and rounds of approval before allowing a project to proceed. On the consulting side, we typically define an approach which might as simple as saying "We're going to write microservices, mostly in Python and our main data store will be Redis until we pick something better" and then start iterating.

Re: Software Architecture Guide

#65

Post by mrkeen »

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

Re: Software Architecture Guide

#66

Post by Ozzie_osman »

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 literature, and I would be worse off if it all had to be evidence-based.

If you think you can write better based on your experience, please go for it. I'd love to have more literature to read, analyze, and learn from. If you can't (pressed for time, etc), and only have time to post in HN comment threads, then at least discuss concretely which parts you disagree with so we can learn from that too (I'm serious, not being facetious). If you can't even do THAT, then sorry, all your valuable experience is way less useful than someone like Martin Fowler, because I'm not learning anything from you.

Having a good understanding of how to architect code is hard. Being able to write about that in a way that's useful for others is even harder, and is a skill of its own.

So personally, I thank Martin & Co for all their writing.

Re: Software Architecture Guide

#67

Post by Chris_Newton »

blub wrote: post #7

Whenever I see yet another article by Martin Fowler, Kent Beck, Robert Martin & co I ask myself - where is the evidence for what they are preaching? What are the graphs based on? What is the evidence behind the proposed rules? These authors are clearly accomplished blog and book writers, but anyone whose software-related accomplishments are not open source or at least well known should have their statements scrutiniz…

There’s nothing wrong with just suggesting reasonable ideas that might be useful. If everything needs to have a solid evidence base or rigorous supporting arguments before we talk about it, it becomes too easy to shut discussion down prematurely without ever discovering whether an idea does have value for someone, particularly in an industry like ours where much of what we do is hard to measure objectively.

It’s helpful to be clear about whether an idea being presented is just someone’s personal thoughts or anecdotal experience or whether it does have a stronger foundation. If something is presented as a firm recommendation of good practice then it’s fair to expect the latter. But it’s also dangerous if we reflexively disregard any idea that doesn’t already have robust evidence behind it.

Re: Software Architecture Guide

#68

Post by streetcat1 »

geofft wrote: post #54
streetcat1 wrote: post #49

Earlier quoted context omitted.

First, I must say that the inventors of UML saw it as the last layer. The grand vision was a complete code generation from UML diagrams. And this was the overall grand vision that drove OO in general. I think that this is was happening now with the "low code" startups. The whole idea is to separate the global decisions (which are hard to change) - e.g. architecture, what classes, what each class do, from the local on…

Again, I am not asking how to use UML, or why the inventors of UML designed it in a certain way, or why it sounds like it could be a good idea, or whether there are other systems like UML that are good ideas (I can just use those systems directly then!). I am asking what evidence there is that UML helps me deliver better products more efficiently. Are there successful software projects that do this complete code gene…

So you would not find any. You would need to judge those tools based on your specific use cases.

Even if you find such and such project did X and got Y, the sample size is too small.

The issue with software is that each project is different, and hence we cannot generalise from any given project.

Re: Software Architecture Guide

#69

Post by [deleted] »

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…

[deleted]

Re: Software Architecture Guide

#70

Post by karmakaze »

Let's talk about any good parts.

The architecture of systems varies enough that there isn't a good concrete definition. An aspect that's important for one system isn't for another so it's hard to say which aspects are part of an architecture. Unless you're always architecting the same types of systems, this will carry some weight.

The other idea that architecture is present but not visible is a great one. It's the important bits that are underlying or overarching or otherwise permeates the system without necessarily being separately visible. I've had so many difficult chats talking past one another about different levels of concern. When one side only sees what's named or in the diffs, it's hard to convey why something else is more important when there's a lack of 'shared understanding'.

I did have this experience when I was making a relay service which handled a headless browser and audio streams. Each of these ended up using a state machine so I separated the state machine mechanics and implemented each using it. The result ended up having many state machine visible parts than the interesting (for the use-case) non-state-machine parts. I undid all that and made each back to primarily do its job as a state-machine but it was far less visible. This isn't the best of examples but it's one where I learned that sometimes you want things to be less invisible even when it's important.

Post reply on HN