Uncle Bob Martin

This is a great post on this topic: https://blog.cleancoder.com/uncle-bob/2014/02/23/OhForemanWhereArtThou… I'm not sure I'd agree with the full argument as such about commit rights (vs. e.g. pull request review), but it does illustrate parent's point

Uncle Bob in particular is a funny case. I feel like his books are largely credited as the being source those very particular OOP obsessions But he eventually turned to the dark side. He claims clojure, a functional lisp, is his absolute favorite language. He’s even got blog posts about it! Multiple! I stumbled on this while reading about clojure. I really like his blog! https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html

+1 … it has a great discussion of structural vs object-oriented vs functional, presenting the trade-offs, it describes different service and module decomposition patterns, with pros and cons for each, without prescribing one. Here is a blog post from Robert C. Martin about microservices and clean architecture: https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArch…

> I've seen 100% code coverage with tests for all the getters and setters. These tests were not only 100% useless, they actively hindered any changes to the system. It's a red flag to blame high coverage for fragile tests. Use narrow public component interfaces to reach code parts and you simultaneously gain robust tests which can be used during refactoring and you can be guided by coverage to generate test cases. Bob Martin has a great article: https://blog.cleancoder.com/uncle-bob/2017/10/03/TestContravariance.ht…

EDIT: Paste this hacky snippet into your browser's console to save all of the links into your clipboard: (() => { let result = [...document.querySelectorAll('td a')] .map((link) => link && !link.href.includes('ycombinator') && !link.href.includes('javascript:void') ? link.href : '' ) .filter(Boolean); result = [...new Set(result)]; result.sort(); copy(result.join('\n\n')); })(); Just to help, here's a compiled-list of all of the links shared here so…

Kent Beck said so many other great things.. he was really ahead of his time: http://blog.cleancoder.com/uncle-bob/2013/12/10/Thankyou-Kent.html Yes, Uncle Bob :)

Considering his strongest argument for Clojure seems to be "economy of expression" [1], I think it's time to stop following what he things. For someone that spent a lot of his career talking about rotting code, how to adapt to change, things like that; his only argument being "it's faster to write" feels really weak. [1]: https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html

For me Clean Code is not about slavishly adhering to the rules therein, but about guidelines to help make your code better if you follow them, in most circumstances. On his blog Bob Martin himself says about livable code vs pristinely clean code: "Does this rule apply to code? It absolutely does! When I write code I fight very hard to keep it clean. But there are also little places where I break the rules specifically because those breakages create affordances for transient issues." I've found the Clean Code guidelines very useful. Your team's mileage may very. As always: Use what works, toss the rest, give back where you can. For more about this see: * Bob Martin's blog post 'Too Clean' - https://blog.cleancoder.com/uncle-bob/2018/08/13/TooClean.html * Livable Code by Sarah Mei - https://www.youtube.com/watch?v=8_UoDmJi7U8

I never recommended Clean Code, but I've become a strong advocate against it on teams that I lead after reading opinions by Bob Martin such as this one: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html. That whole article reads as someone who is stuck in their old ways and inflexible, then given their large soapbox tries to justify their discomfort and frustration. I consider Swift, Kotlin (and Rust) to be one of the most important language evolutions that dramatically improved software quality on the projects I've worked on. I've seen so many real world counter-examples to arguments made in that article and his other blog posts that I'm puzzled why this guy has such a large and devoted following.

FWIW, one useful tidbit from Uncle Bob that I keep thinking about is how the number of working programmers has doubled every five years. http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html That insight helped me calm down quite a bit. Because noobs are being produced faster than best practices can percolate. Per Mark Twain's quip about lies racing half-way around the world before truth can get its pants on, every generation thinking they invented sex, and how people are generally emotionally attached to their first notions (no matter how wrong). (So if your introduction to computing is thru Python, PHP, JavaScript or whatever, it's super hard to see their flaws, or to appreciate what their precedents were trying to achieve.)

makes sense, thanks for the reply and clarification. although, how do you suggest to phrase it / to apply SRP in a language without interfaces e.g. Node.js? In my opinion it's more about coupling than interfaces. I feel I'm quite in line with the following by unclebob, let me know what you think, i'm open to learn more https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPr…

I'm fulltime Clojure since 2014, and I can't say enough how happy I am. I find a lot of joy, every day, in my work as working with a LISP really fits with how my brain think. The community is great and the language leaks through the people: you'll often find very pragmatic (even conservative) approaches. If you are looking for some more testimonials, look no further than Uncle Bob [0] and Gene Kim [1], but there's several more results online. Lately, I tried to "modernize" a little bit the Clojure course that I used, many years ago, to start, and you can find it at [2]: - [0]: https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html - [1]: https://itrevolution.com/love-letter-to-clojure-part-1/ - [2]: https://heliosmaster.github.io/academy/

Why isn't it discoverable? You know what type is returned by "To()" and if that has a BeCalled() method you can call it :) Now, the problem that requires an IDE, that many curse Scala for comes in when you have implicit things. So even if "To()" returns a WhateverTestDslElement that might not tell you anything because there might be a hundred implicit functions that convert WhateverTestDslElement to OtherFancyDslThingWithTheMethodYouAreLookingFor. Of course, at this point you are basically back to reading the documentation, which is kind of what C programming looks like. That said efficient and useful and really "domain specific" layers are great, and many systems would benefit from one. (Which is sort of what the whole clean code "entities" is about - https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-arch… )

This isn't about OOP vs. FP. This is about OOP vs. everything else. Rust, Go and javascript are three languages that are moving away from the OOP paradigm. None of those three languages are classified as functional. >Is there some resource you can point to that says in the past when faced with situation X developers tended to use pattern Y, these days that has been superseded with way of doing things Z? No. A general trend is an anecdotal observation. Still a quick google search yielded: https://blog.cleancoder.com/uncle-bob/images/fpvsoo.jpg Take a look at the following video: https://www.youtube.com/watch?v=QM1iUe6IofM While I don't agree with a lot of it, I think it sums up my opinion really clearly. It's not about DP's but because DP's focus around OOP and the video is a criticism of OOP therefore the arguments apply to DPs.

"A lot of the best programmers and the most productive programmers I know are writing everything in Clojure and swearing by it, and then just producing ridiculously sophisticated things in a very short time." - Adrian Cockcroft http://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html I want to learn some Clojure!

I'm curious, and I'm prefacing this up front because I'm not always good at writing what I say in a way that may not feel like I'm coming from a good place, so here goes: Whats your testing story? This to me seems like not writing good, solid, abstracted tests before doing proper implementations of your code. This could be solved with good interface design, and perhaps be faster. I apologize in advance if this sounds harsh. This sounds like the exact thing folks on my team were trying to do, and it was turning things very sub-optimal. (Disclaimer: I'm a bit of a TDD/BDD idealogue. Not as hardcore as Uncle Bob[0], certainly, but close enough. I think writing Interfaces before Tests is acceptable, I think that might be where things differ, i guess). [0]https://blog.cleancoder.com/

Yeah a lot of the 90s/early 2000s OOP stuff I learned in school seemed to always result in really tightly coupled systems and bespoke webs of tests and fixtures that strung along weird dependency chains in unwieldy spaghetti piles that did no good. Following TDD has helped me land at decoupled functional interfaces like the ones you've described, and it all scales and composes so nicely, yet stays very tractable. Robert Martin sketched 2 diagrams in [1] that elegantly illustrate these two different design patterns and how testable usually means composable and more tractable: [1] http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture…

I recommend to read Robert C. Martin's (Uncle Bob) view on that presented in "The Tragedy of Craftsmanship": https://blog.cleancoder.com/uncle-bob/2018/08/28/CraftsmanshipMovement…

That comparisong is not fair, but anyway, no need for new languages today, we should improve the existing ones. See UncleBob's opinion on these: http://blog.cleancoder.com/uncle-bob/2015/08/06/LetTheMagicDie.html C is just terrible, it has to be improved, but the "Git vs Mercurial" is not the same topic, because Mercurial is not THAT MUCH better to worth to replace it or make thing more complex.

>"Access to developers is a bigger constraint than access to capital" As software continues to eat the world, I am reminded of Uncle Bob's blog on a Hippocratic Oath for software developers and the gravity behind the consequences of what we produce. http://blog.cleancoder.com/uncle-bob/2015/11/27/OathDiscussion.html It's only a matter of time before the discussion changes from "Developer Coefficient" to much more dire tone. To quote Bob Martin, "With that great power ought to come great responsibility. And, indeed, society will hold us responsible when our actions result in disaster. And yet nothing binds us together as a profession. We share no ethics. We share no discipline. We share no standards. We are viewed, by our employers, as laborers. We are tools for others to command and use. We have no profession."

I see the framework cancer now conquering CSS world as it did with back-end and JS world. The question is do we really need these frameworks? I want to remind Robert Martin's advice about this issue; "Never buy magic! Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?" http://blog.cleancoder.com/uncle-bob/2015/08/06/LetTheMagicDie.html

After reading the post by Hillel Wayne I decided to read Uncle Bob's article that is mentioned in the post (http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotTheAnswer.htm… After reading both posts, and after reading most of the comments on this thread, I have to admit that my inclination is in favor of Uncle Bob. I agree with most of the points Uncle Bob made in his blog post. Tools are not the answer. TDD is not the answer. Agile is not the answer. More programming languages are not the answer. There is no silver bullet. For me the answer is to do the best I can, with the tools I have. Never stop learning, always strive to improve my skills. And yes, it takes discipline.

Youre not the only one: http://blog.cleancoder.com/uncle-bob/2016/07/27/TheChurn.html and the follow-up http://blog.cleancoder.com/uncle-bob/2016/09/01/TheLurn.html

I agree, this answer is pretty solid. I honestly think you could just start with #5. You can use the term "Technical Debt" when describing the debt that is created by not using unit tests. As in you are creating more work & cost down the road. Here is 1 of many good Uncle Bob articles on TDD - http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTDD.html This quote from the article is slightly off topic, but I think it is a great one you could tweak & use with Management: "Look. Suppose you ask me to write an app to control your grandmother's pacemaker. I agree, and a week later I hand you a thumb-drive and tell you to load it into her controller. Before you do you ask me: 'Did you test it?' And my response is: 'No, I chose a design that was hard to test.'"

Will you grant that sometimes, they aren't? It depends. Let's take a SaaS engineering department, for example. If your customer base is tripling year over year based in the need of the market, you can end up with feature requests that would take decades even with an engineering team ten times the size. Those are often from sales on the backs of failed deals because the product didn't yet meet the client need. If the goal is to keep the lights on and meet current customer need, you need a fraction of the total engineering team. However, we're on the message board of a venture capital site, so we can take an assumption of hypergrowth, as is the goal of a startup. So, then, I'd argue that in growth scenarios, these people are required. That doesn't mean that they are being used the most efficiently, of course. I think this would be a main point of our disagreement. That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? I agree. And some of that is the ZIRF culture as well. And I think we agree with the rest as well. However, I think I am sensing a separate point where I don't know if we agree or disagree. Our field has not created the tools to scale from 10 to 100 or 100 to 250 well. The best tools that have been created to date have taken microservices as part of the orthodoxy. I don't think this is the only way to do it - Robert Martin has a good article here from a decade ago:…

I can't speak to the "need balls" comment, however he has multiple posts where he discusses types: > You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python. https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html He has another that is a bit less assertive and more just "types aren't for me": https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html However I think it's worth pointing out, as a teacher, Uncle Bob seems to not have experience in many languages with high quality type systems and doesn't seem to understand types. He says "I prefer the flexibility of dynamic typing, and the ability to enforce types if, and when, I need such enforcement." As a Clojure person he's probably talking about what Clojure has which does not enforce types at all but really is just a runtime assert system. The following is vaguely in support of types but it's mostly incoherent. Where is "The Dark Path" he refers to? He seems to have a very narrow view of types, no concept of "correct by construction" with an expressive type system. His go-to example in this piece is that enforcing a function is called with an "int" instead of "double" and then talks about how…

For those who haven't followed the story: 2007 - the Clojure programming language is announced by Rich Hickey and gains quite a bit of traction over the next 5 or 6 years. It never becomes a "top 5" language, but it could still today be arguably considered a mainstream language. It's been endorsed as "the best general purpose programming language out there" by "Uncle" Bob Martin[1] (author of Clean Code) and Gene Kim[2] (auther of The Phoenix Project, the seminal DevOps book). The fact that Rich spent two years working on it without pay and without the commercial backing many other languages enjoy is a real testament to his commitment and his vision. A Clojure-related emacs package[3] quotes Rich when it starts a REPL: "Design is about pulling things apart." 2012 - the Datomic database is announced by Rich Hickey's company. The database is praised for its ingenuity and its "time travel" features. It was designed to be deployed anywhere in the beginning, but, over time, it became difficult to deploy outside of AWS environments and even the AWS deployment path was quite cumbersome--the Datomic marketing page used to feature a maze-like diagram of all the AWS-specific features needed to make the thing work (it would be nice to find a link to that picture); I'd think most companies would have trouble digesting that and integrating it into their technology "stack". 2020 - Nubank (a Brazilian fintech backed by at least one US venture firm and a large production user of…

> Linux actually does have the flavour of problem the Clean Code is modelling here, and it does indeed solve it the way Clean Code recommends Getting a bit desperate here, eh? On one hand, having tables of function pointers does not introduce any code constraints, you can switch to switches or anything else at a moment's notice; class hierarchies are much more rigid (some random Torvalds quote, "all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app"). On the other hand, Clean Code is fundamentally tied to OOP and classes. Here, straight from the horse's mouth [1]: "This expectation of polymorphism is the essence of OO programming. It is the reductionist definition; and it is inextricable from OO. OO without polymorphism is not OO. C and Pascal programmers (and to some extend even Fortran, and Cobol programmers) have always created systems of encapsulated functions and data structures. It does not require an OOPL to create and use such encapsulated structures. Encapsulation, and even simple inheritance, is obvious and natural in such languages. (More natural in C and Pascal than the others.) So the thing that truly differentiates OO programs from non-OO programs is polymorphism. You might complain about this by saying that polymorphism can be achieved by using switch statements or long if/else chains within f. This is true, so I must add one more constraint to OO. The mechanism of polymorphism must not create a…

I like the Uncle Bob explanation: the number of developers has a doubling rate of ~5 years due to the constant entry of new developers [1]. Over time, the number of inexperienced developers far outweighs the experienced ones. Inexperienced developers naturally gravitate toward complexity because they don't know any better. Couple that with a social drift toward hyper-specialization. That sort of hierarchy naturally creates minds that don't think at the systems level. This is the general theme of Buckminster Fuller's Operating Manual For Spaceship Earth: the shift toward hyper-specialization (or narrow focus) has long-term disastrous consequences. When you couple inexperience with narrow focus, you get messes. Part of this is to blame on the industry-standard thinking that because someone works for Company X, they're a competent, logical engineer (and should be granted authority/responsibility over essential products/projects). This is the downfall of "code tests" and "whiteboard coding." They don't evaluate for systems level thinking and so a developer with poor creativity and logic skills slips through the cracks because they're great at eeking performance out of a function which impresses the lollipop guild. [1] https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

I'd suggest going through all Uncle Bob Martin[1]s talks on clean code. He has a great article (2014), old, on why you may not want to build that framework at all[2] too: > Using a framework requires a significant commitment. By accepting the framework into your code, you surrender your control over the details that the framework manages. [...] > And yet despite the huge commitment you’ve made to the framework, the framework has made no reciprocal commitment to you at all. That framework is free to evolve in any direction that pleases its author. Another great source are the books, and/or youtube channel by Dave Farley[3] What set me on a journey is -decades ago- the pain I, as a developer felt when developing web-applications for my clients. But worse: the pain they felt for getting delivered crap. "Why am I delivering crap" was the question that set me to research frameworks, languages, design patterns and architecture. Drupal, Rails, Django, ASP: I've worked with it, and delivered crap with it. In general, I found that a framework matters. e.g. the simple act of reading ActiveRecord Critisism on wikipedia[4] got me thingking: > also due to the strong coupling of database interaction and application logic, This was true for project D, G and Y! This was why we failed to iterate at any speed at all. Because I can relate it immediate to Real And Actual Problems, Failed Projects, Slipped Deadlines, Burned out colleagues, and so on, all of wich I encountered during my…