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 , 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  ("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.
* "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"
This is in stark contrast with Uncle Bob who implies you're not a professional if you don't write "clean code".
Martin Fowler is dangerous in this regard, there isn't a bandwagon he doesn't jump on making it sound like it is the new normal, and, although, as you say, he does mention counterindications, his presentations are still very unbalanced, hyping what is still inmature and extremelly risky. He is an excellent popularizer, I actually enjoy listening to him, but too many buy it uncritically.
I meantioned CQRS, the wider context is microservices. Thank you for presenting so much evidence, you are right, but the thing is, the wider context where it was said, all the hype, is still missing.
Here is one example from a few years ago in youtube , at the height of the NoSQL craze this time. He proudly mentioned how his mates at The Guardian adopted it, because "a news article is a natural aggregate", or something like that.
He does indeed add later, in passing, that "some NoSQL databases are immature , we don't have the tools, the experience, the knowledge to work with them well; we've got decades of experience with sql databases".
It turned out that they were burnt at The Guardian, and wrote about their painful migration to a RDBMS and to safety .
Now, one can argue, rightly, that this is just anecdotal evidence against NoSQL. The problem is that he used it as evidence for NoSQL. Anecdotal too. The difference is that the former evidence benefits from hindsight, whereas the latter was premature, a space he regularly finds himself in.
It's not really fair to judge technical decisions retroactively.
PostgreSQL in 2012 wasn't the same as in 2018. PostgreSQL was uncommon back then, there was a limited talent pool, it was painful to operate/failover/scale/shard, and it wasn't yet available on RDS. JSONB support only arrived to Postgres in Dec/2014.
The alternatives (e.g. MySQL) were also problematic, e.g. locking tables every time a new column was added was likely a deal-breaker.
They only migrated to PostgreSQL because they didn't want the pain and downtime of self-hosting MongoDB, but there didn't seem to be any major architectural issues. In this case it seemed like specific issues with MongoDB in production rather than NoSQL in general.
He briefly touches on the downsides during the talk, but the purpose of a talk is to excite and pique somebody's interest.
In the book he uses more nuanced language and warns that it's not something to be used on every occasion.
* "It’s essential to test your expectations about programmer productivity and/or performance before committing to using a NoSQL technology."
* "Most applications, particularly nonstrategic ones, should stick with relational technology—at
least until the NoSQL ecosystem becomes more mature."
* "But we also realize that there are many cases, indeed the
majority of cases, where you’re better off sticking with the default option of a relational database."
* "There’s no shame in doing the assessments for
programmability and performance, finding no clear advantage, and staying with the relational option."
> I meantioned CQRS, the wider context is microservices.
Regarding microservices, he states that you shouldn't start with complex distributed architecture even if you're confident you'll need it in the future.
> Martin Fowler is dangerous in this regard, there isn't a bandwagon he doesn't jump on making it sound like it is the new normal
While he talked about hyped technologies, I don't think you can blame him for bad decisions other people have made after watching his talks.
> My main point was that we should focus first on learning and applying well ageless fundamentals and mature solutions, rather than on shoehorning the latest fad. Only in extreme cases should that new idea from a FAANG be adopted.
Indeed, nowadays I usually choose boring technology instead of the latest fads
My intention wasn't really to bash on Martin Fowler, the problem is much wider than that, and he is certainly not the worst example, just happens to be the OP's subject.
Let me end by quoting MIT software engineering professor Daniel Jackson, I think that he pinpoints the essence of the problem beautifully (in his book "Design by concept", where, BTW, he credits Martin Fowler's book "Analysis Patterns" influence):
In my work as a consultant, I've been involved in discussions about future products and strategic directions, usually under the rubric of "digital transformation". Companies may be keenly aware of what they're trying to achieve (better customer experience, increased customer engagement, differentiation from competitors, etc), but much less certain of how to do it, and especially how to explore new posibilities and get results and feedback quickly. Too often, the options are cast in terms of technology adoption (selecting from the latest shiny new things, whether mobile, cloud, blockchain, machine learning, Internet of Things, etc). These technologies may have great potential, but they are only platforms, and choosing one with the hope that it will transform your business is no more plausible than expecting such an impact from the adoption of a new programming language or web application framework. A better approach is to focus on functionality, which is the source of real value.
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".
I wouldn't be surprised if the mere existence of a software architect title incentivizes overly complicated architectures
There's not a single piece of hard data in that article, not even how many of his colleagues are making the specific recommendation.
It's an article about his experience as a technical expert brought in to consult on many projects.
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.
But let imagine through some miracle he did have data that conclusively proved 75% of the time it was better to build a monolith. This might suggest you should more seriously consider building a monolith first, but still this doesn't make the decision for your project. You have to decide based on your project, teams, goals, and budget if a microservice is right for you.
I think you're 100% right that it's the reception. Our industry is filled with people who take the practice of software as a matter of dogma. But we do that with everything, we'll turn any technique into a cult TDD, microservices, unit testing, immutability, functional programming, BDD, etc..
I would need the above to make my mind precisely because I can't find any indication that Fowler is a technical expert. The fact that they're a SW book author that I can't attribute any well-known software to is a big red flag for me. Likewise that they've been working as a consultant for a very long time.
> 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.
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.
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
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...
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.
It's telling that one Wikipedia’s citations describes their customer burning out due to the evangelized methodology:
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
Did you mean his writing here (2005): https://martinfowler.com/articles/newMethodology.html#ration... ?
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.
> 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.
or maybe something else?
(i have my own experiences, but im really keen to hear from others)
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.
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!
There is nothing off the shelf with the level of sophistication you see in those systems.