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

141–150 of 303 posts

Re: Software Architecture Guide

#141

Post by hyperpallium »

Ozzie_osman wrote: post #135
2_listerine_pls wrote: post #103

Earlier quoted context omitted.

Engineering is the application of science. A civil engineer uses laws regarding compression, stress, etc... to build its buildings. If you apply scientifically derived principles when building software then You are a software engineer.

I'd love to see what those scientifically derived principles are. If I'm building a bridge, there are equations based on physics I can use. Like I mentioned in a separate thread, software is far more removed from those physics.

GP may be implying from the conditional that there aren't any software engineers.

Re: Software Architecture Guide

#142

Post by wpietri »

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…

Totally. In a side room at Java One in 1999 or 2000 I saw Fowler talking about Refactoring, and he happened to bring Kent Beck up on stage to talk a bit. If I hadn't been exposed to their ideas, I surely would have left software by now.

Over and over, my experience was building something that slowly got less tractable over time, where eventually we'd just want to do a big rewrite. It sucked! I had tried the big-design-up-front approach, where I thought real hard for a long time before building. That might push out the rewrite date some, but definitely not forever. It was dispiriting, a slow, sticky death. That combined with crunches and burnout was slowly making me hate something I had loved doing.

But their main point was that code bases didn't have to end in an entropic snarl. That with decent tests and a little elbow grease, code could get better organized every time we touched it. That instead of death by papercut, we could make things a little better every day. Better for the users, better for the business, better for the developers. They weren't promoting silver architecture bullets. They were saying that we should trust and empower teams to figure it out. That if we gave them room and tools to figure it out, everybody would end up happier.

It made a huge difference in my life, so it's weird to see people here aggressively putting words in Fowler's mouth, words that seem entirely at odds with my experience of him and his work.

Re: Software Architecture Guide

#143

Post by cliffcrosland »

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 discovered, etc) and from code reviews of student projects in his design course, but he admits that there is a lack of data about things like design.

Sample principles from Ousterhout:

* When developing an interface, favor exposing a small number of functions each with deep functionality over exposing a large number of functions each with shallow functionality. For example, favor Unix file I/O interface (open, close, read, write, unlink) over Java file I/O interface (File, FileReader, BufferedReader, FileWriter, BufferedWriter, FileNotFoundException, ... etc.)

* When choosing between keeping your code specific and keeping your code general, favor "somewhat" general. For example, instead of exposing "deleteNextCharacter(text, pos), deleteNextWord(text, pos), deleteNextSentence(text, pos)", just expose "delete(text, pos, length)" and let the caller use it how they will.

Re: Software Architecture Guide

#144

Post by wolco »

noobiemcfoob wrote: post #80
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,…

> it does mean that it's quite hard to fire an underperforming dev, because how the hell do you prove they're underperforming? What metric do you use? I think your criticism of 'at-will' employment is unfounded in this scenario. Having lower guardrails on employment means it's not as pressing to figure out performance metrics. If the company narrative is that an employee is helpful to the mission, then there isn't mu…

At will doesn't mean you can test out more employees. It means you don't have to pay anyone any pay when you let them go.

It has side-effects. A worker will bolt at the first better opportunity or when your company looks like they are in trouble because they have to. It also raises wages as people changes jobs more often.

Re: Software Architecture Guide

#145

Post by stephen »

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 there were mainstream at the time (and personally who I think would be a better target of your ire than Fowler and ThoughtWorks).

Re: Software Architecture Guide

#146

Post by wolco »

tootie wrote: post #64
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…

When consulting I love those guys. So many billable hours and project delays with pay.

Re: Software Architecture Guide

#147

Post by goatinaboat »

The key to understanding Fowler and similar, and Thoughtworks, that the methodology is their product. They sell consulting and training and seminars and conferences and books.

If any useful, working software is produced that is at best by sheer coincidence and more likely despite their involvement.

Re: Software Architecture Guide

#149

Post by dvlsg »

His biggest contribution may be the documentation and defining the vocabulary, but when he defines a pattern with a word that has an obvious negative connotation ("anemic"), it feels manipulative.

A while ago I was told by members of a separate team that I was writing the core of my javascript application incorrectly. I was following "functional core, imperative shell"[1] and intentionally separating my data from my functions[2]. Specifically, the code was considered to be wrong because it was "anemic", and I was sent a link straight to that 16 year old page about anemic domain models[3]. The suggestion to fix was to add a bunch of mutable state.

Don't get me wrong - I still almost always appreciate Martin Fowler's writing, as it's often quite good, including the original post. But I also understand some of the skepticism here.

---

1: https://www.destroyallsoftware.com/screencasts/catalog/funct...

2: https://softwareengineering.stackexchange.com/q/203077

3: https://martinfowler.com/bliki/AnemicDomainModel.html

Re: Software Architecture Guide

#150

Post by geofft »

jhayward wrote: post #111
geofft wrote: post #20

Earlier quoted context omitted.

The question was about "research" in the meaning of quantitative scientific evidence that these proposed techniques make software delivery better in real-world conditions, not "research" in the sense of new ideas from academics. As a professional, I don't want UML because I've seen no evidence it actually helps. Show me relevant studies that it does and I will absolutely change my mind. (And there are plenty of thing…

I would be interested in a list of the tools you use daily and your list of research publications that prove that those specific tools improve productivity, reliability, or whatever metric you have named in selecting them.

That's a fair question, and it is absolutely fair and correct for you to imply that I don't have any.

However, the comment above (which was not me) said "studies cited, case studies presented or concrete examples," not just studies. I was taking objection to the claim that merely coming out of academia counts as a "study" in this sense. I don't need an experimental study (though I would love to have one), a body of anecdotes of successful uses of a tool is sufficient.

I can name countless case studies, concrete examples, and anecdotes of people using the programming languages and software environments I use successfully. There is a large body of evidence that, say, Linux works fine, whether or not a paper says as much. (And, in particular, there is a sizable body of anecdotal evidence that OpenStack does not work fine, and I've been pushing my team to find a migration strategy out of OpenStack for this exact reason.)

Also, I think the burden of proof is on someone advocating for change. When I am delivering software successfully, and someone else comes in and says "You need to be taking this approach," I think it's fair for me to say "Why?", and that that's very different from staring blankly at bash and saying "Why?" and refusing to type anything.

And finally I would actually be delighted to have real metrics for my tools. I do want to know if, say, enforcing style checks via pre-commit hooks makes development velocity faster and avoids annoying developers! It certainly seems like it would but it sounds like an easy enough thing to test, and I wish we as an industry (and more specifically people in either academia or industry who see their work as advocating for better software development practices, not developing software) would spend the time to test it.

Post reply on HN