7 ms·

Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many p

by s1k3s 5y ago

Probably not necessarily on topic - but I really want to say that this guy has been the #1 source of pain in my developer career so far. There've been so many projects where I had to implement some solution some way because the "architect" said "that's how Fowler recommends it, so that's how we're doing it", even if the solution was so bad that everyone saw it coming back to bite us from miles away. I read his books and found nothing impressive. To me the guy is just a glorified salesman who I'd hire to sell BS to my agency's clients.

tommica 5y ago
Well, he is not your source of pain, it's your superiors that made the decisions - he did not tell them to do it
ncann 5y ago
I echo this sentiment. For some reason his writing is very popular among so-called "software architect", which is especially painful if they are in a position of power in the organization and start forcing it down everyone's throat.
conradfr 5y ago
Yes, I must say, him and Eric Evans. It's not their fault, but still ;) I remember it well, starting 2016 suddenly everyone wants to do DDD, CQRS etc. Let's shoehorn new paradigms in our framework of choice. Boilerplate, lots of boilerplate...
The_Colonel 5y ago
You suffer from bad architects. If there wasn't Fowler, they would just misinterpret somebody else. > that's how Fowler recommends it, so that's how we're doing it Fowler would be the first to point out that there are no hard & fast rules / recommendations and each case should be evaluated individually since there's just too many variables.
thrower123 5y ago
Everybody reads Fowler and does horrible things thereafter for a while. Hopefully, you come out of that phase and learn what is worth bothering with and what is not, without too many years and without too many scars and too many failed projects. Some never do though... The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.
- andrekandre 5y ago
  > The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period. does this come from the architectural patterns themselves, or from applying them everywhere (including where they dont fit)? or maybe something else? (i have my own experiences, but im really keen to hear from others)
- chousuke 5y ago
  I think the best use in studying patterns and approaches is thinking about where they are applicable and where they aren't and reflecting that on what you've done. You can't really use architectural patterns as shortcuts before you've accumulated enough experience to internalise their requirements and caveats, but just knowing about them gives your brain more to work with when you design systems, allowing you to think more broadly.
benhoyt 5y ago
I sympathize (I like saying I don't do BDD, Buzzword-Driven Development), but I'm not terribly up on Fowler's work -- can you provide some concrete examples of things he recommends that were over-engineered or just plain bad for your use cases?
- abraxas 5y ago
  Rational Unified Process. Let's start right here.
  - solarengineer 5y ago
    (Disclosure: I'm at Thoughtworks, but my opinions are my own. In fact, we're so broadly dispersed across the world that we can't claim to represent a "Thoughtworks" opinion). Did you mean his writing here (2005): https://martinfowler.com/articles/newMethodology.html#rationalUnifiedProcess https://martinfowler.com/articles/newMethodology.html#ration... ?
    - abraxas 5y ago
      he peddles whatever is the fad du jour. Back in 2001/2003 when the RUP was at its peak cycle Fowler made a number of posts and talks praising its virtues.
amw-zero 5y ago
As is always the case, I feel the exact opposite. The #1 source of pain in my career is people not understanding that certain concepts / principles are really the key to surviving in a complex system. But, we probably don't build the same kinds of software. Shooting him down because he isn't talking about the kind of software you build is pretty ignorant.
- moonchrome 5y ago
  I think the problem is people who aren't building these kinds of systems learn these "best practices" without the context and then you get frustration like OP, and you can often blame the people selling these approaches (I mean understandably they want to promote their work, no doubt it works in their scenario) But I've seen this in every direction possible at this point : - people talking about horizontal and vertical scaling, citing Google and Facebook research - on an unreleased MVP with 0 users - people using the quick and dirty approach with stuff like RoR and then 5 years down the line getting stuck in an mess that's hard to reuse and hard to refactor and being unable to react to quick market changes fast enough - people implementing a distributed lock system to synchronise some state - meanwhile the entire system is built on top of one DB instance and if the DB is down the system is down - so use the DB locking .... so many "best practices" or "good approaches" without context
  - amw-zero 5y ago
    I totally agree with that. Everything is contextual.
shaicoleman 5y ago
Fowler's article that made the most impact on me is the one about Monolith First, and how you shouldn't start with a complex distributed architecture, even if you're confident you'll need it in the future. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html Fowler shares ideas of architecture, but in a nuanced way, and clearly states when it might be appropriate, and what are the costs and complexities involved. The problem in your case seems to be more of "Architecture Astronauts". https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... I wouldn't be surprised if the mere existence of a software architect title incentivizes overly complicated architectures
- blub 5y ago
  What's remarkable to me is that Fowler is telling an interesting story about a technical decision, includes an entertaining diagram, but in the end doesn't provide any proof either way. There's not a single piece of hard data in that article, not even how many of his colleagues are making the specific recommendation.
  - JamesBarney 5y ago
    What proof would you expect him to bring? It's an article about his experience as a technical expert brought in to consult on many projects.
    - routerl 5y ago
      > What proof would you expect him to bring? Data. Data about software projects. What bugs me most about Fowler is his reception, not his writing. If we take his writing in the spirit you've outlined (an experienced developer sharing his anecdotes), there's no problem. But that just isn't how he's seen in the industry. There is a whole class of developers who take his writings as gospel, without the critical sense to wonder whether Fowler's experience/insight actually matches the project at hand.
hvmonk 5y ago
100% agree. The fact he still exists is surprising. I have never came across a single article from this guy which is useful... even so, when he belabors on an existing tech, I have always found articles from other bloggers which are way more precise and to-the-point. He is just a salesman under a tech garb.
alecco 5y ago
One of the largest financials institutions in the world based some of their main trading systems in Event Sourcing with serialized object storage. It's a massive pain. But the dogma/mantra and sunk cost fallacy pull make any attempt at moving away from it being outright mocked. Want to see the current state of a trade? Open and deserialize 50 objects and then manually make these classes pick the merging of all those fields. Not like there are multiple database products out there with temporal support. Let's reinvent the wheel, baby!
- revel 5y ago
  Literally every major bank follows this model and has done for at least a decade There is nothing off the shelf with the level of sophistication you see in those systems.
bsder 5y ago
Everybody forgets that the Chrysler Comprehensive Compensation System project that spawned most of these guys was a massive disaster: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... But, then, this just proves the business aphorism that, for your career, it is better to be part of a gigantic disaster than a modest success.
- hitekker 5y ago
  I definitely didn't know about this. It's a shame you're the only one to remember. Thanks for sharing. It's telling that one Wikipedia’s citations describes their customer burning out due to the evangelized methodology: http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html http://www.coldewey.com/publikationen/conferences/oopsla2001... And then Martin handwaves the project's failure away, claiming he wasn't that involved, and that his methodology is blameless: https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html
charlysl 5y ago
Just like Uncle Bob. I am dismayed by the fame of these two. If you want to actually learn what they call "clean coding" (aka proper design, these guys are great at creating buzzwords, and great public speakers), the way to go is "Systematic Program Design" (in youtube [1], same material as edx's How To Code), which is based on the Htdp book ("how to design programs"), followed by MIT's OCW 6.005 [2] ("Software Construction"). Both are free. But who knows this? There is no one to hype them, no "movement" behind what are tried and trusted techniques, no flashy CQRS SOLID acronyms. These two courses, instead, teach you timeless concepts and techniques that will survive all fads. [1] https://youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w https://youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w [2] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-software-construction-spring-2016/ https://ocw.mit.edu/courses/electrical-engineering-and-compu...
- Kinrany 5y ago
  Thanks for the links! Wikipedia suggests the book intends to improve on SICP and is used at many universities other than MIT.
- shaicoleman 5y ago
  You can't blame Fowler because your software architect decided to implement CQRS, here's some of the warnings in the article he wrote about CQRS: * "CQRS is useful in some places, but not in others" * "Beware that for most systems CQRS adds risky complexity" * "CQRS is a significant mental leap for all concerned, so shouldn't be tackled unless the benefit is worth the jump." * "So far the majority of cases I've run into have not been so good, with CQRS seen as a significant force for getting a software system into serious difficulties." * "CQRS should only be used on specific portions of a system and not the system as a whole" * "Suitability for CQRS is very much the minority case" * "Using CQRS on a domain that doesn't match it will add complexity, thus reducing productivity and increasing risk." * "You should be very cautious about using CQRS" * "Adding CQRS to such a system can add significant complexity" * "I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team" * "Beware that it is difficult to use well" https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html This is in stark contrast with Uncle Bob who implies you're not a professional if you don't write "clean code".
abraxas 5y ago
Yes, I once said at work that "the sad testament to the sorry state of our industry is that Fowler can still make good money rather than be chased with pitchforks". It did not go over well with the rest of the architects. I still stand by that.

by s1k3s 5y ago

tommica 5y ago

Well, he is not your source of pain, it's your superiors that made the decisions - he did not tell them to do it

ncann 5y ago

I echo this sentiment. For some reason his writing is very popular among so-called "software architect", which is especially painful if they are in a position of power in the organization and start forcing it down everyone's throat.

conradfr 5y ago

Yes, I must say, him and Eric Evans. It's not their fault, but still ;) I remember it well, starting 2016 suddenly everyone wants to do DDD, CQRS etc. Let's shoehorn new paradigms in our framework of choice. Boilerplate, lots of boilerplate...

The_Colonel 5y ago

You suffer from bad architects. If there wasn't Fowler, they would just misinterpret somebody else. > that's how Fowler recommends it, so that's how we're doing it Fowler would be the first to point out that there are no hard & fast rules / recommendations and each case should be evaluated individually since there's just too many variables.

thrower123 5y ago

Everybody reads Fowler and does horrible things thereafter for a while. Hopefully, you come out of that phase and learn what is worth bothering with and what is not, without too many years and without too many scars and too many failed projects. Some never do though... The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period.

andrekandre 5y ago
> The phase of my career where I drank the SOLID kool-aid and studied and tried to apply the hip architectural patterns is one of the darkest and most regrettable. I'm still dealing with bad decisions made in code bases from that period. does this come from the architectural patterns themselves, or from applying them everywhere (including where they dont fit)? or maybe something else? (i have my own experiences, but im really keen to hear from others)
chousuke 5y ago
I think the best use in studying patterns and approaches is thinking about where they are applicable and where they aren't and reflecting that on what you've done. You can't really use architectural patterns as shortcuts before you've accumulated enough experience to internalise their requirements and caveats, but just knowing about them gives your brain more to work with when you design systems, allowing you to think more broadly.

benhoyt 5y ago

I sympathize (I like saying I don't do BDD, Buzzword-Driven Development), but I'm not terribly up on Fowler's work -- can you provide some concrete examples of things he recommends that were over-engineered or just plain bad for your use cases?

abraxas 5y ago
Rational Unified Process. Let's start right here.
- solarengineer 5y ago
  (Disclosure: I'm at Thoughtworks, but my opinions are my own. In fact, we're so broadly dispersed across the world that we can't claim to represent a "Thoughtworks" opinion). Did you mean his writing here (2005): https://martinfowler.com/articles/newMethodology.html#rationalUnifiedProcess https://martinfowler.com/articles/newMethodology.html#ration... ?
  - abraxas 5y ago
    he peddles whatever is the fad du jour. Back in 2001/2003 when the RUP was at its peak cycle Fowler made a number of posts and talks praising its virtues.

amw-zero 5y ago

As is always the case, I feel the exact opposite. The #1 source of pain in my career is people not understanding that certain concepts / principles are really the key to surviving in a complex system. But, we probably don't build the same kinds of software. Shooting him down because he isn't talking about the kind of software you build is pretty ignorant.

moonchrome 5y ago
I think the problem is people who aren't building these kinds of systems learn these "best practices" without the context and then you get frustration like OP, and you can often blame the people selling these approaches (I mean understandably they want to promote their work, no doubt it works in their scenario) But I've seen this in every direction possible at this point : - people talking about horizontal and vertical scaling, citing Google and Facebook research - on an unreleased MVP with 0 users - people using the quick and dirty approach with stuff like RoR and then 5 years down the line getting stuck in an mess that's hard to reuse and hard to refactor and being unable to react to quick market changes fast enough - people implementing a distributed lock system to synchronise some state - meanwhile the entire system is built on top of one DB instance and if the DB is down the system is down - so use the DB locking .... so many "best practices" or "good approaches" without context
- amw-zero 5y ago
  I totally agree with that. Everything is contextual.

shaicoleman 5y ago

Fowler's article that made the most impact on me is the one about Monolith First, and how you shouldn't start with a complex distributed architecture, even if you're confident you'll need it in the future. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html Fowler shares ideas of architecture, but in a nuanced way, and clearly states when it might be appropriate, and what are the costs and complexities involved. The problem in your case seems to be more of "Architecture Astronauts". https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ https://www.joelonsoftware.com/2001/04/21/dont-let-architect... I wouldn't be surprised if the mere existence of a software architect title incentivizes overly complicated architectures

blub 5y ago
What's remarkable to me is that Fowler is telling an interesting story about a technical decision, includes an entertaining diagram, but in the end doesn't provide any proof either way. There's not a single piece of hard data in that article, not even how many of his colleagues are making the specific recommendation.
- JamesBarney 5y ago
  What proof would you expect him to bring? It's an article about his experience as a technical expert brought in to consult on many projects.
  - routerl 5y ago
    > What proof would you expect him to bring? Data. Data about software projects. What bugs me most about Fowler is his reception, not his writing. If we take his writing in the spirit you've outlined (an experienced developer sharing his anecdotes), there's no problem. But that just isn't how he's seen in the industry. There is a whole class of developers who take his writings as gospel, without the critical sense to wonder whether Fowler's experience/insight actually matches the project at hand.

hvmonk 5y ago

100% agree. The fact he still exists is surprising. I have never came across a single article from this guy which is useful... even so, when he belabors on an existing tech, I have always found articles from other bloggers which are way more precise and to-the-point. He is just a salesman under a tech garb.

alecco 5y ago

One of the largest financials institutions in the world based some of their main trading systems in Event Sourcing with serialized object storage. It's a massive pain. But the dogma/mantra and sunk cost fallacy pull make any attempt at moving away from it being outright mocked. Want to see the current state of a trade? Open and deserialize 50 objects and then manually make these classes pick the merging of all those fields. Not like there are multiple database products out there with temporal support. Let's reinvent the wheel, baby!

revel 5y ago
Literally every major bank follows this model and has done for at least a decade There is nothing off the shelf with the level of sophistication you see in those systems.

bsder 5y ago

Everybody forgets that the Chrysler Comprehensive Compensation System project that spawned most of these guys was a massive disaster: https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens... But, then, this just proves the business aphorism that, for your career, it is better to be part of a gigantic disaster than a modest success.

hitekker 5y ago
I definitely didn't know about this. It's a shame you're the only one to remember. Thanks for sharing. It's telling that one Wikipedia’s citations describes their customer burning out due to the evangelized methodology: http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html http://www.coldewey.com/publikationen/conferences/oopsla2001... And then Martin handwaves the project's failure away, claiming he wasn't that involved, and that his methodology is blameless: https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html

charlysl 5y ago

Just like Uncle Bob. I am dismayed by the fame of these two. If you want to actually learn what they call "clean coding" (aka proper design, these guys are great at creating buzzwords, and great public speakers), the way to go is "Systematic Program Design" (in youtube [1], same material as edx's How To Code), which is based on the Htdp book ("how to design programs"), followed by MIT's OCW 6.005 [2] ("Software Construction"). Both are free. But who knows this? There is no one to hype them, no "movement" behind what are tried and trusted techniques, no flashy CQRS SOLID acronyms. These two courses, instead, teach you timeless concepts and techniques that will survive all fads. [1] https://youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w https://youtube.com/channel/UC7dEjIUwSxSNcW4PqNRQW8w [2] https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-005-software-construction-spring-2016/ https://ocw.mit.edu/courses/electrical-engineering-and-compu...

Kinrany 5y ago
Thanks for the links! Wikipedia suggests the book intends to improve on SICP and is used at many universities other than MIT.
shaicoleman 5y ago
You can't blame Fowler because your software architect decided to implement CQRS, here's some of the warnings in the article he wrote about CQRS: * "CQRS is useful in some places, but not in others" * "Beware that for most systems CQRS adds risky complexity" * "CQRS is a significant mental leap for all concerned, so shouldn't be tackled unless the benefit is worth the jump." * "So far the majority of cases I've run into have not been so good, with CQRS seen as a significant force for getting a software system into serious difficulties." * "CQRS should only be used on specific portions of a system and not the system as a whole" * "Suitability for CQRS is very much the minority case" * "Using CQRS on a domain that doesn't match it will add complexity, thus reducing productivity and increasing risk." * "You should be very cautious about using CQRS" * "Adding CQRS to such a system can add significant complexity" * "I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team" * "Beware that it is difficult to use well" https://martinfowler.com/bliki/CQRS.html https://martinfowler.com/bliki/CQRS.html This is in stark contrast with Uncle Bob who implies you're not a professional if you don't write "clean code".

abraxas 5y ago

Yes, I once said at work that "the sad testament to the sorry state of our industry is that Fowler can still make good money rather than be chased with pitchforks". It did not go over well with the rest of the architects. I still stand by that.