6 ms·

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 gre

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".
- charlysl 5y ago
  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. 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 [1], 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 [2]. 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. [1] https://youtu.be/qI_g07C_Q5I https://youtu.be/qI_g07C_Q5I [2] https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-h...
  - shaicoleman 5y ago
    > It turned out that they [The Guardian] were burnt, and wrote about their painful migration to a RDBMS and to safety 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. https://youtu.be/qI_g07C_Q5I?t=3120 https://youtu.be/qI_g07C_Q5I?t=3120 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. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html > 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 https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology

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

charlysl 5y ago
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. 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 [1], 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 [2]. 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. [1] https://youtu.be/qI_g07C_Q5I https://youtu.be/qI_g07C_Q5I [2] https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-h...
- shaicoleman 5y ago
  > It turned out that they [The Guardian] were burnt, and wrote about their painful migration to a RDBMS and to safety 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. https://youtu.be/qI_g07C_Q5I?t=3120 https://youtu.be/qI_g07C_Q5I?t=3120 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. https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html > 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 https://mcfunley.com/choose-boring-technology https://mcfunley.com/choose-boring-technology