5 ms·

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 alway

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, security, comms and exception management. You deploy these things on desktops, phones, and devices. Other parts of the things live on servers or on clusters, mabe. Call these places (hardware) tiers. There. Architecture done. From micro services to huge banking monoliths. Start there. Everything else is the usual let's think about what we're doing before we do it. But I guess keeping it simple and dealing with exceptions as they arise isn't as glamorous as using fancy new names, working for a hipster consultancy or generally saying X or Y is teh new futures. If you harbour doubt great, questions are good. I suggest obtaining a copy of Wicked Problems, Rightous Solutions (ISBN-10: 013590126X). It will show you that we had EXACTLY the same problems of today, back in 1990. We just call them new things.

scarface74 7y ago
I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.
- deleted 7y ago
  [deleted]
tootie 7y ago
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.
wpietri 7y ago
You say this with a lot of bile, but I'm not sure where your opinions actually differ from Fowler's. He says right in the second paragraph that he's suspicious of the term "architecture" because it "often suggests a separation from programming and an unhealthy dose of pomposity." I think keeping it simple and dealing with exceptions is great. And so does Fowler, I'm sure. But I've been doing that a long time and I've learned some lessons about what "simple" means, and how some ways of dealing with exceptions work well in certain circumstances, while others can seem appealing but end up being a mess. Like you, I think high-church, prescriptive software is mainly a giant waste, a way for fast talkers to get big paychecks while performing oh-so-smartness. But that doesn't mean over decades of coding we can't learn anything about they ways we build systems.
jsdalton 7y ago
Is that 99% of software all the same? Like, have you really not observed huge differences in the readability of the code you encountered? Have you not found that sometimes it is painful (or close to impossible) to extend or build more features on top of a particular system, while other times it is quite straightforward, even a joy? If your answer to these questions is yes, to what do you attribute the difference? How would you counsel a young software engineer or team? How can we write better, more maintainable software that still allows us to deliver features quickly?
stephen 7y ago
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).
- camgunz 7y ago
  I have what I feel like are cultural disagreements with Fowler (e.g. "Enterprise Architecture" is oxymoronic to me) so adjust for my bias accordingly. But perhaps his most famous book is "Refactoring", where he gives (fancy, new) names to things he found in the wild. It's basically what he does and arguably his most influential contribution to the industry.
lemmsjid 7y ago
Having similarly done software in that time period, your reductionist argument flies in the face of my own experience, where there are actually tons of nuance within what you are correctly identifying as typical macro patterns. When I look at Fowler's repository of EA patterns (https://martinfowler.com/eaaCatalog/ https://martinfowler.com/eaaCatalog/), I see a ton of time tested patterns that are, to this day, used in a tremendous amount of software. They are so prevalent that they are typically abstracted into frameworks or libraries that are then used by people building line of business applications. Something I have always appreciated about Fowler has been his workman-like, semi-anthropological approach to documenting these patterns. He does not claim ownership to them, but instead discovers and names them out of working software. He does have a playful opinionated-ness to his writing, but that is really only to spice things up, as far as I've seen (in other words, he has been quite willing to modify his own positions over time). Perhaps to your point, I have seen people read these books and suddenly wish to apply all the patterns at all the times to all the software, resulting in an ill conceived amount of complexity. That, to me, is why a healthy software development team needs senior developers who have been around the block on this sort of thing. And why the agism in the industry is so poisonous and counterproductive. A healthy team needs healthy defenses against the forces of over complexity (and, equally, over simplicity), and because of the tremendous amount of abstraction in software engineering, experience, erudition and mentorship can bring that to a team.

scarface74 7y ago

I learned a lot from Domain Driven Design and some from Design Patterns by the GOF.

deleted 7y ago
[deleted]

tootie 7y ago

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.

wpietri 7y ago

You say this with a lot of bile, but I'm not sure where your opinions actually differ from Fowler's. He says right in the second paragraph that he's suspicious of the term "architecture" because it "often suggests a separation from programming and an unhealthy dose of pomposity." I think keeping it simple and dealing with exceptions is great. And so does Fowler, I'm sure. But I've been doing that a long time and I've learned some lessons about what "simple" means, and how some ways of dealing with exceptions work well in certain circumstances, while others can seem appealing but end up being a mess. Like you, I think high-church, prescriptive software is mainly a giant waste, a way for fast talkers to get big paychecks while performing oh-so-smartness. But that doesn't mean over decades of coding we can't learn anything about they ways we build systems.

jsdalton 7y ago

Is that 99% of software all the same? Like, have you really not observed huge differences in the readability of the code you encountered? Have you not found that sometimes it is painful (or close to impossible) to extend or build more features on top of a particular system, while other times it is quite straightforward, even a joy? If your answer to these questions is yes, to what do you attribute the difference? How would you counsel a young software engineer or team? How can we write better, more maintainable software that still allows us to deliver features quickly?

stephen 7y ago

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).

camgunz 7y ago
I have what I feel like are cultural disagreements with Fowler (e.g. "Enterprise Architecture" is oxymoronic to me) so adjust for my bias accordingly. But perhaps his most famous book is "Refactoring", where he gives (fancy, new) names to things he found in the wild. It's basically what he does and arguably his most influential contribution to the industry.

lemmsjid 7y ago

Having similarly done software in that time period, your reductionist argument flies in the face of my own experience, where there are actually tons of nuance within what you are correctly identifying as typical macro patterns. When I look at Fowler's repository of EA patterns (https://martinfowler.com/eaaCatalog/ https://martinfowler.com/eaaCatalog/), I see a ton of time tested patterns that are, to this day, used in a tremendous amount of software. They are so prevalent that they are typically abstracted into frameworks or libraries that are then used by people building line of business applications. Something I have always appreciated about Fowler has been his workman-like, semi-anthropological approach to documenting these patterns. He does not claim ownership to them, but instead discovers and names them out of working software. He does have a playful opinionated-ness to his writing, but that is really only to spice things up, as far as I've seen (in other words, he has been quite willing to modify his own positions over time). Perhaps to your point, I have seen people read these books and suddenly wish to apply all the patterns at all the times to all the software, resulting in an ill conceived amount of complexity. That, to me, is why a healthy software development team needs senior developers who have been around the block on this sort of thing. And why the agism in the industry is so poisonous and counterproductive. A healthy team needs healthy defenses against the forces of over complexity (and, equally, over simplicity), and because of the tremendous amount of abstraction in software engineering, experience, erudition and mentorship can bring that to a team.