16 ms·

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 someon

by jeswin 7y ago

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 perhaps mundane) problems in Enterprise Application development. He isn't trying to break new ground, but I'm glad his writings exist. To pick a very random example, here's CQRS defined in an approachable manner[1]. It's a great link to send to a team of 50, out of which quite a few will be fresh out of college. And I am pretty sure Martin Folwer has seen plenty of real world code while he was working at Thoughtworks. The ideas in his writings aren't conceived in some vaccuum. Some of his early writing isn't perhaps as relevant today. For instance, he talks about the flaws of Anemic Domain Model here [2]. Back in the day, many of us tried to enrich the domain model with particular emphasis on reusability. But those things are less relevant in today's heterogeous environments where logic lives across in multiple services (many outside your team's control). So just reading through his site will surface a lot of outdated ideas; but that's helped a lot of companies along the way when we didn't have to aim for web-scale tps. Actually, it might still work for 99% of apps even today. HN tilts towards the experiences of Startups and young founders, but one good lesson to learn early is that we should be more open minded. 1: https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html 2: https://martinfowler.com/bliki/AnemicDomainModel.html https://martinfowler.com/bliki/AnemicDomainModel.html

Ozzie_osman 7y ago
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.
- camgunz 7y ago
  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 https://youtu.be/lKXe3HUG2l4
  - charlieflowers 7y ago
    > Agree, but people tend to stop at Fowler and live it as gospel. I know people do that, and it sucks. But I never got that from Fowler himself. There are other authors (not naming names) who are pretty dogmatic often. But Fowler seems to genuinely try to capture patterns and techniques in an open-minded way. It's the abuse of his material that is the problem.
    - camgunz 7y ago
      Yeah he's no Zed Shaw. But actually I think Fowler is... well he skips a lot of steps and makes a lot of assertions. Here's an excerpt from the intro to Refactoring: > The performance of software usually depends on just a few parts of the code, and changes anywhere else don't make an appreciable difference. > But "mostly" isn't "alwaysly." Sometimes a refactoring will have a significant performance implication. Even then, I usually go ahead and do it, because it's much easier to tune the performance of well-factored code. If I introduce a significant performance issue during refactoring, I spend time on performance tuning afterwards. It may be that this leads to reversing some of the refactoring I did earlier--but most of the time, due to the refactoring, I can apply a more effective performance-tuning enhancement instead. I end up with code that's both clearer and faster. > So my overall advice on performance with refactoring is: Most of the time you should ignore it. If your refactoring introduces performance slow-downs, finish refactoring first and do performance tuning afterwards. One way to read this is basically what he writes: clear code is more important than efficient code, and clear code can help you make code more efficient if that's important. Another way--indeed the way I read it--is "performance isn't the most important thing, and at least some of the time following my advice, performance will suffer, even if you undo a lot of the work I'm recommending you do." And I can respect that, but what he writes tries to have it both ways. At least when DHH makes this argument, he basically just says "yeah, buy more machines, they're cheap, engineers aren't." This "incidental" absence of drawbacks is just one of the things that makes all of Fowler's writing feel like marketing. Another is all the hand waving assertions. There's a lot of it even in those three short paragraphs: - How did he measure "much easier to tune the performance of well-factored code"? Honestly how would you even measure that? - How did he measure "more effective performance-tuning enhancement", and also what does "effective" mean? - What does "well-factored" mean? - What does "clearer" mean when he says "I end up with code that's both clearer and faster" Further, he reinvents and renames things. His (short) article about "Application Boundary" [1] is actually Conway's Law [2], which was nearly 40 years old at writing. And OK, no one knows everything. But that piece is written very prescriptively; here's an excerpt: > We can draw application boundaries in hundred arbitrarily different ways. But it's our nature to group things together and organize groups of people around these groups. There's little science in how this works, and in many ways these boundaries are drawn primarily by human inter-relationships and politics rather than technical and functional considerations. To think about this more clearly I think we have to recognize this uncomfortable fact. How can you say "there's little science in how this works" immediately after "it's in our nature to..."? And for what it's worth, there's plenty of work around this; look at any discussion of permission/capability systems, consensus systems, sandboxes, etc. There is literally science about it. I have no doubt that Fowler is earnest and well-meaning, I appreciate his contributions to (what I reluctantly accept is) my field, and I'm happy that he's frequently many people's gateway to thinking more critically about software. But he's far from the final word on it, and too often he writes like he is. And, at the risk of making an over-long post even longer, there are two problems with that. I've already been explicit about the first: people take it as gospel and don't look further. That's not great for our field. But even worse, it ends up changing our culture from one of wonder, exploration, and experimentation to one of prescription and certitude. I have no idea what the best way to factor a program is; it's very hard for me (or anyone) to say why one expression of information or a computation is "better" than another, and that is an endless source of delight for me. God help me the day I figure it all out. [1]: https://martinfowler.com/bliki/ApplicationBoundary.html https://martinfowler.com/bliki/ApplicationBoundary.html [2]: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
extra_rice 7y ago
I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple parts of the system, which could mean multiple redeployments of many different services. Also implies more complex integration (even e2e) testing.
- jbmsf 7y ago
  I'm definitely guilty of using and promoting anemic models. I find that teams have a hard time deciding whether logic is service or domain or whatever and gravitate towards putting everything in one place if domain objects are allowed to be at all smart. On the other hand, people do well with the rule that logic belongs in procedural layers with clear names and some sort of maximum size/complexity. I also find that these discussions matter less in microservices because the size of each service is so small that you usually don't need more than two layers: one for business logic and one for persistence. I very much agree that microservices create their own challenges at service interfaces, but since these boundaries are usually expressed as http operations instead of object oriented function calls, I look for different solutions, especially various forms of system-wide introspection and testing.
  - Spearchucker 7y ago
    First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world. Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data. So guilt because anemic strikes me as... odd. Modern connected apps aren't written as single-tier Smalltalk apps.
    - lonelappde 7y ago
blub 7y ago
You're completely off-topic. Nobody's mentioning CQRS or anemic models. This is an article about architecture with zero references to other authors, studies or proof of any kind. It presents several graphs without any supporting evidence. => it's absolutely normal to request evidence for those claims. This is software engineering, not software literature, where we try to guess what the author meant and marvel in awe. It's exactly the younger practitioners on HN which should ignore such articles and demand properly supported texts.
- sidlls 7y ago
  Too much of this industry is driven by fads and personalities. You're exactly correct, of course, but I don't think your point will be well received.
vbezhenar 7y ago
I know one guy who thinks that Fowler is wrong in very large number of points. He works as an architect in big company now (FAANG) and he did some great projects before, so I certainly trust him. For example he thinks that anemic model is the right way to do and putting methods into data objects is wrong. Unfortunately he does not want to write a book yet, so I can't reveal anything, but I just want to underline that a good engineer should not blindly trust anything, even if it seems to be written by a well received author. I, myself, read his Refactoring book and it was great. Unfortunately I'm not qualified enough to judge those things myself, I just learned that I must doubt about anything, even if it seems to come from big names.
- extra_rice 7y ago
  > I just want to underline that a good engineer should not blindly trust anything, even if it seems to be written by a well received author. Doesn't this also apply to the opinions of your friend who works at a FAANG? How do you judge between theirs and Fowler's view points?

by jeswin 7y ago

Ozzie_osman 7y ago

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.

camgunz 7y ago
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 https://youtu.be/lKXe3HUG2l4
- charlieflowers 7y ago
  > Agree, but people tend to stop at Fowler and live it as gospel. I know people do that, and it sucks. But I never got that from Fowler himself. There are other authors (not naming names) who are pretty dogmatic often. But Fowler seems to genuinely try to capture patterns and techniques in an open-minded way. It's the abuse of his material that is the problem.
  - camgunz 7y ago
    Yeah he's no Zed Shaw. But actually I think Fowler is... well he skips a lot of steps and makes a lot of assertions. Here's an excerpt from the intro to Refactoring: > The performance of software usually depends on just a few parts of the code, and changes anywhere else don't make an appreciable difference. > But "mostly" isn't "alwaysly." Sometimes a refactoring will have a significant performance implication. Even then, I usually go ahead and do it, because it's much easier to tune the performance of well-factored code. If I introduce a significant performance issue during refactoring, I spend time on performance tuning afterwards. It may be that this leads to reversing some of the refactoring I did earlier--but most of the time, due to the refactoring, I can apply a more effective performance-tuning enhancement instead. I end up with code that's both clearer and faster. > So my overall advice on performance with refactoring is: Most of the time you should ignore it. If your refactoring introduces performance slow-downs, finish refactoring first and do performance tuning afterwards. One way to read this is basically what he writes: clear code is more important than efficient code, and clear code can help you make code more efficient if that's important. Another way--indeed the way I read it--is "performance isn't the most important thing, and at least some of the time following my advice, performance will suffer, even if you undo a lot of the work I'm recommending you do." And I can respect that, but what he writes tries to have it both ways. At least when DHH makes this argument, he basically just says "yeah, buy more machines, they're cheap, engineers aren't." This "incidental" absence of drawbacks is just one of the things that makes all of Fowler's writing feel like marketing. Another is all the hand waving assertions. There's a lot of it even in those three short paragraphs: - How did he measure "much easier to tune the performance of well-factored code"? Honestly how would you even measure that? - How did he measure "more effective performance-tuning enhancement", and also what does "effective" mean? - What does "well-factored" mean? - What does "clearer" mean when he says "I end up with code that's both clearer and faster" Further, he reinvents and renames things. His (short) article about "Application Boundary" [1] is actually Conway's Law [2], which was nearly 40 years old at writing. And OK, no one knows everything. But that piece is written very prescriptively; here's an excerpt: > We can draw application boundaries in hundred arbitrarily different ways. But it's our nature to group things together and organize groups of people around these groups. There's little science in how this works, and in many ways these boundaries are drawn primarily by human inter-relationships and politics rather than technical and functional considerations. To think about this more clearly I think we have to recognize this uncomfortable fact. How can you say "there's little science in how this works" immediately after "it's in our nature to..."? And for what it's worth, there's plenty of work around this; look at any discussion of permission/capability systems, consensus systems, sandboxes, etc. There is literally science about it. I have no doubt that Fowler is earnest and well-meaning, I appreciate his contributions to (what I reluctantly accept is) my field, and I'm happy that he's frequently many people's gateway to thinking more critically about software. But he's far from the final word on it, and too often he writes like he is. And, at the risk of making an over-long post even longer, there are two problems with that. I've already been explicit about the first: people take it as gospel and don't look further. That's not great for our field. But even worse, it ends up changing our culture from one of wonder, exploration, and experimentation to one of prescription and certitude. I have no idea what the best way to factor a program is; it's very hard for me (or anyone) to say why one expression of information or a computation is "better" than another, and that is an endless source of delight for me. God help me the day I figure it all out. [1]: https://martinfowler.com/bliki/ApplicationBoundary.html https://martinfowler.com/bliki/ApplicationBoundary.html [2]: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

extra_rice 7y ago

I don't understand how anemic domain models are irrelevant now especially in a time where a lot of software practitioners seem to observe domain driven design. In the age of microservices, it is very important to determine clear context boundaries. "Logic lives across multiple services" sounds more like a design smell to me. In this case, changing even very simple business requirements could mean changes in multiple parts of the system, which could mean multiple redeployments of many different services. Also implies more complex integration (even e2e) testing.

jbmsf 7y ago
I'm definitely guilty of using and promoting anemic models. I find that teams have a hard time deciding whether logic is service or domain or whatever and gravitate towards putting everything in one place if domain objects are allowed to be at all smart. On the other hand, people do well with the rule that logic belongs in procedural layers with clear names and some sort of maximum size/complexity. I also find that these discussions matter less in microservices because the size of each service is so small that you usually don't need more than two layers: one for business logic and one for persistence. I very much agree that microservices create their own challenges at service interfaces, but since these boundaries are usually expressed as http operations instead of object oriented function calls, I look for different solutions, especially various forms of system-wide introspection and testing.
- Spearchucker 7y ago
  First, anemic models work well in service contexts. You can't send a business rule from a web page to a web service as part of a data entity. And so such models have a valid place in the world. Micro services are still services. As such we always validate data crossing a trust boundary - whether monolith or micro service. The rules to do that validation cannot travel with the data. So guilt because anemic strikes me as... odd. Modern connected apps aren't written as single-tier Smalltalk apps.
  - lonelappde 7y ago

blub 7y ago

You're completely off-topic. Nobody's mentioning CQRS or anemic models. This is an article about architecture with zero references to other authors, studies or proof of any kind. It presents several graphs without any supporting evidence. => it's absolutely normal to request evidence for those claims. This is software engineering, not software literature, where we try to guess what the author meant and marvel in awe. It's exactly the younger practitioners on HN which should ignore such articles and demand properly supported texts.

sidlls 7y ago
Too much of this industry is driven by fads and personalities. You're exactly correct, of course, but I don't think your point will be well received.

vbezhenar 7y ago

I know one guy who thinks that Fowler is wrong in very large number of points. He works as an architect in big company now (FAANG) and he did some great projects before, so I certainly trust him. For example he thinks that anemic model is the right way to do and putting methods into data objects is wrong. Unfortunately he does not want to write a book yet, so I can't reveal anything, but I just want to underline that a good engineer should not blindly trust anything, even if it seems to be written by a well received author. I, myself, read his Refactoring book and it was great. Unfortunately I'm not qualified enough to judge those things myself, I just learned that I must doubt about anything, even if it seems to come from big names.

extra_rice 7y ago
> I just want to underline that a good engineer should not blindly trust anything, even if it seems to be written by a well received author. Doesn't this also apply to the opinions of your friend who works at a FAANG? How do you judge between theirs and Fowler's view points?