10 ms·

Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry. It is my experience that good software comes from tea

Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry. It is my experience that good software comes from teams working together well, teams that are in some sort of harmony with each other AND the system they are building/using. They understand it and each other. Good software is not derived from a singular technique. I do like test-first approaches when I can, I like SOLID. I probably agree with Bob on a lot, actually. I think they are good techniques to employ. However, it has not been uncommon in my career to find people (and myself) getting dogmatic about these things and arguing over them. There are half baked attempts to change everything to an Entity. There are flaky test suites with a lot of mocks because someone is hot on TDD, but does not have the bandwidth to maintain the suite for the whole team. This blogicle is another example. As pointed out by other posters, REPL driven development can fold VERY well into a test driven workflow. However, that's not enough, he's actively saying it's not as good and you need to do The One True technique.

throwaway894345 6y ago
I think this is true in general. There are very few "always right" ideas in software development--virtually every choice is a function of a broader economic context. For example, if you work for a startup and you need to determine market fit quickly, it's more important to move fast than to have very high degrees of quality (although below a certain threshold, low quality impedes velocity) or performance. Economic context affects virtually everything, and the difference between good and great software engineers is the ability to understand economic context (and changes in economic context) and the technology/process ramifications.
ironmagma 6y ago
You can’t test everything. To believe we can is just hubris; even if we get every function to have coverage, we won’t have coverage of the full range of inputs unless all that’s being done is some very simple programming. The combinatorial explosion is fast. Testing definitely has value, but when testing you always have to make the assumption that you can’t test everything, and then the trick is deciding what to test versus what not to. I think people forget this and focus on having every function tested, every interface having coverage, etc.
- capableweb 6y ago
  Quickcheck, clojure.spec and similar efforts are getting damn close to it, and using clojure.spec raised my confidence in my code a lot, more than unit testing ever did. Since generative/property based testing is gaining more ground, we'll get better tools as well. Not to say there is not still a place for manually written unit tests.
  - stingraycharles 6y ago
    While I am a big fan of property based testing, it’s hardly able to “test everything”. It’s great for testing pure functions, but as soon as things have side effects, property based testing becomes very cumbersome. Unfortunately, this is precisely where a large amount of bugs originate from. And I say all this as someone who has pursued this very idea of property testing side effects for years and in the end had to admit failure. It just is too much work get right (eg uuids being generated not unique, to name just one example), and your test runs become incredibly slow, which is a killer in many REPL-driven workflows.
    - PopeDotNinja 6y ago
      I have a (probably horrible) joke reply to the question "what is a monad?" I say "that's where you put the real programming." I have also never done any serious with Haskell, so don't make the mistake of taking me seriously on this :)
      - gindely 6y ago
        however true the statement may be, it's not therefore an abandonment of pure functional programming. You don't have to program in `IO` or `MonadIO m => m`. Expressing your state in terms of pure functions of input events, as can be done with an FRP like Reflex, means you can test all your logic purely. You can be confident that you'll only request to launch the nukes when the nukes need to be launched. Then you have to make yourself confident that, when the system asks the nukes to launch, it sends the right signal. But that's mockable by running the system attached to device that reads the signal and reports its correctness. And making sure the nukes take off, aim correctly, and land on their target is not my department (says Werner von Braun).
drewcoo 6y ago
It read to me as a personal story about adopting new techniques. People usually: 1. stumble over differences from their normal approach 2. catch on and use it everywhere (Stockholm syndrome? Testing limits?) 3. finally find places it doesn't work and can apply judiciously Given that in our profession we're constantly learning and experimenting, Uncle Bob is still doing that to this day.
- billjings 6y ago
  But Bob didn't take a moment to see if or how he could integrate his existing knowledge into this new way of doing things, or ask if there might be something he's not seeing. I've taken those concerns to people in the clojure community, and they've been accommodating. That there are drawbacks to the REPL feedback loop is true. But they aren't the drawbacks Bob claims to have found here, because he ceased investigating at the point he felt his priors were confirmed.
jjtheblunt 6y ago
SOLID ?
- Jtsummers 6y ago
  https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID A set of principles for program design, specifically OO (and some flavors of OO at that), but some of the ideas are general enough to apply to most languages and paradigms.
  - jjtheblunt 6y ago
    thanks
sitkack 6y ago
I have seen Bob a couple of times in person. He is a good speaker, his rhetoric is strong, but he has some pretty large blind spots. He out of hand writes off formal methods and type systems, which is ridiculous given his stated goals around software quality. Testing is his singular solution for everything.
- PopeDotNinja 6y ago
  I remember watching a talk of Bob's where he pumped up how good his approach to coding was, and when asked to provide examples, he could/would/did not provide any. Seriously, if you can't demonstrate what you're talking about, I'm just gonna take you less seriously. I think it was this video, but I can't watch it all the way through right now -- https://youtu.be/ecIWPzGEbFc https://youtu.be/ecIWPzGEbFc
- BiteCode_dev 6y ago
  People like this need to be put into managing a team of visual basic devs at an obscure local DMV IT department, and force them to make projects after projects until they realize that if they want something done in those situations, they have to get dumber.
PopeDotNinja 6y ago
Having been on the receiving end of code reviews where the reviewer uses clean code dogma against me like a weapon of mass destruction, I am much more a fan of letting the small stuff that can't be easily caught via automation slide. There's no one true technique, even if you are coding for yourself. There just isn't. That's like saying there's one true way to paint, and code is more art than science.
- amw-zero 6y ago
  Well, there are helpful code / design review comments that can't be automated. I totally agree that if it's a tiny issue, just let it go. There's only so much feedback people can hear and actually respond to. But there are also helpful things to say.
gambler 6y ago
> Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry. His lectures and books really are harmful. Beginners read them and get the impression that you can design good software by following a bunch of simplistic rules of thumb. In reality, you need to understand what trade-offs you're making when committing to certain design decisions and, even more importantly, you need to be able to discuss this with other people. For example, it's not "small functions are good", it's "when you make a function smaller, here are the benefits and here are costs". Primitive, sloganistic thinking is the bane of software engineering profession right now.
- amw-zero 6y ago
  I don't think he's harmful. I think you take the good with the bad with him. He's way too convicted to trust blindly, but he also talks about some great topics that aren't widely discussed. So, if you consider him the leader of a religion, you'll be led astray. But if you just read critically, you'll see that he definitely has a lot of insight to take away. Just discard the stuff that you don't agree with.
sktrdie 6y ago
I think Bob is a very insightful person and has great intuition and probably more experience than any of us. Sure he has certain bias towards certain things; who doesn't really? Saying that his posts are harmful is a bit of a stretch.
- charlieflowers 6y ago
  Even smart, highly qualified people (which Bob is) are prone to cognitive bias. One such bias is, the more you have espoused something, the more fervently you believe in it, and the harder it is for you to acknowledge any shortcomings of it. So I agree with the parent ... his writings are in many cases harmful. They're a mix of good and bad, but often net harmful.
- nojito 6y ago
  How much experience can someone have who hasn’t coded professionally in probably 15 years? Look at how much growth happened in the last 15 years.
- Silhouette 6y ago
  I think Bob is a very insightful person and has great intuition and probably more experience than any of us. Why on earth would you think that? Saying that his posts are harmful is a bit of a stretch. Mentor your first few people who keep defending rookie mistakes with "But Uncle Bob said..." and you might change your mind about that. Bob Martin says some sensible things, but he also says some things that are at best debatable and at worst outright contradicted by the evidence base, and he says all of them with great conviction and presumed authority so that his target audience can't tell the difference. That alone makes him dangerous as a source of advice.
- wglb 6y ago
  > more experience than any of us. I have been developing for 54 years. I have been through all manner of design philosophies, from Structured Programming, to Object Oriented Programming, to Agile, to TDD along with hack-it-till-it-works. If you don't do the engineering, which he does not teach, you are going to struggle. I believe this is a harmful post.
fizixer 6y ago
Bob Martin belongs to the OO-evangelism camp that emerged from the OO fad of mid-1990s. Another OO-evanglist who belongs to this camp is Ron Jeffries. For a textbook example of how much of a snake-oil OO-evangelism is, checkout the sudoku solver fiasco involving Ron Jeffries and Peter Norvig (you'll find plenty of search results regarding this).
- inopinatus 6y ago
  I’m no fan of Bob Martin, but the Ron Jeffries fiasco was a failure of TDD, not of OOP. The meandering inability to focus on writing a solution, instead becoming lost in modelling the problem, is a hallmark of the tunnel vision that TDD engenders. He’d have screwed it up in Prolog.
- wglb 6y ago
  That was a dramatic failure of TDD, contrasted with Peter's enlightened solution.
gilbetron 6y ago
Last year I came up with a new term for a type of developer: The Medium Developer. Medium in that they have a medium amount of experience (3-7 years, not that all in that range fall in this category), and Medium in that they have a medium amount of talent (not bad, not great), and Medium in that the religiously consume and spout Medium articles. They are the most zealous type of developer I've encountered. They believe TDD is the One True Way, or they think CI/CD with iterations in the minutes where you constantly commit to master prevents all bugs, or that SOLID is the word of the developer gods. They are awful to work with and be around. All of those concept I mentioned have benefits in them, but not as a religion. Medium programmers lack nuance and deep experience and are dismissive of those that do, they see it as weakness. When their favorite technique doesn't take them to the holy Nirvana of software, they lash out at other, less zealous developers and blame their lack of discipline. Completely shitty people - I just hope they grow out of it. But they are seductive in their intensity and (bad) managers love to hear how they have a simple solution to all their woes - rather than software development being inherently difficult (because you only have to do a specific hard things once, but that's another discussion!)

throwaway894345 6y ago

I think this is true in general. There are very few "always right" ideas in software development--virtually every choice is a function of a broader economic context. For example, if you work for a startup and you need to determine market fit quickly, it's more important to move fast than to have very high degrees of quality (although below a certain threshold, low quality impedes velocity) or performance. Economic context affects virtually everything, and the difference between good and great software engineers is the ability to understand economic context (and changes in economic context) and the technology/process ramifications.

ironmagma 6y ago

You can’t test everything. To believe we can is just hubris; even if we get every function to have coverage, we won’t have coverage of the full range of inputs unless all that’s being done is some very simple programming. The combinatorial explosion is fast. Testing definitely has value, but when testing you always have to make the assumption that you can’t test everything, and then the trick is deciding what to test versus what not to. I think people forget this and focus on having every function tested, every interface having coverage, etc.

capableweb 6y ago
Quickcheck, clojure.spec and similar efforts are getting damn close to it, and using clojure.spec raised my confidence in my code a lot, more than unit testing ever did. Since generative/property based testing is gaining more ground, we'll get better tools as well. Not to say there is not still a place for manually written unit tests.
- stingraycharles 6y ago
  While I am a big fan of property based testing, it’s hardly able to “test everything”. It’s great for testing pure functions, but as soon as things have side effects, property based testing becomes very cumbersome. Unfortunately, this is precisely where a large amount of bugs originate from. And I say all this as someone who has pursued this very idea of property testing side effects for years and in the end had to admit failure. It just is too much work get right (eg uuids being generated not unique, to name just one example), and your test runs become incredibly slow, which is a killer in many REPL-driven workflows.
  - PopeDotNinja 6y ago
    I have a (probably horrible) joke reply to the question "what is a monad?" I say "that's where you put the real programming." I have also never done any serious with Haskell, so don't make the mistake of taking me seriously on this :)
    - gindely 6y ago
      however true the statement may be, it's not therefore an abandonment of pure functional programming. You don't have to program in `IO` or `MonadIO m => m`. Expressing your state in terms of pure functions of input events, as can be done with an FRP like Reflex, means you can test all your logic purely. You can be confident that you'll only request to launch the nukes when the nukes need to be launched. Then you have to make yourself confident that, when the system asks the nukes to launch, it sends the right signal. But that's mockable by running the system attached to device that reads the signal and reports its correctness. And making sure the nukes take off, aim correctly, and land on their target is not my department (says Werner von Braun).

drewcoo 6y ago

It read to me as a personal story about adopting new techniques. People usually: 1. stumble over differences from their normal approach 2. catch on and use it everywhere (Stockholm syndrome? Testing limits?) 3. finally find places it doesn't work and can apply judiciously Given that in our profession we're constantly learning and experimenting, Uncle Bob is still doing that to this day.

billjings 6y ago
But Bob didn't take a moment to see if or how he could integrate his existing knowledge into this new way of doing things, or ask if there might be something he's not seeing. I've taken those concerns to people in the clojure community, and they've been accommodating. That there are drawbacks to the REPL feedback loop is true. But they aren't the drawbacks Bob claims to have found here, because he ceased investigating at the point he felt his priors were confirmed.

jjtheblunt 6y ago

SOLID ?

Jtsummers 6y ago
https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID A set of principles for program design, specifically OO (and some flavors of OO at that), but some of the ideas are general enough to apply to most languages and paradigms.
- jjtheblunt 6y ago
  thanks

sitkack 6y ago

I have seen Bob a couple of times in person. He is a good speaker, his rhetoric is strong, but he has some pretty large blind spots. He out of hand writes off formal methods and type systems, which is ridiculous given his stated goals around software quality. Testing is his singular solution for everything.

PopeDotNinja 6y ago
I remember watching a talk of Bob's where he pumped up how good his approach to coding was, and when asked to provide examples, he could/would/did not provide any. Seriously, if you can't demonstrate what you're talking about, I'm just gonna take you less seriously. I think it was this video, but I can't watch it all the way through right now -- https://youtu.be/ecIWPzGEbFc https://youtu.be/ecIWPzGEbFc
BiteCode_dev 6y ago
People like this need to be put into managing a team of visual basic devs at an obscure local DMV IT department, and force them to make projects after projects until they realize that if they want something done in those situations, they have to get dumber.

PopeDotNinja 6y ago

Having been on the receiving end of code reviews where the reviewer uses clean code dogma against me like a weapon of mass destruction, I am much more a fan of letting the small stuff that can't be easily caught via automation slide. There's no one true technique, even if you are coding for yourself. There just isn't. That's like saying there's one true way to paint, and code is more art than science.

amw-zero 6y ago
Well, there are helpful code / design review comments that can't be automated. I totally agree that if it's a tiny issue, just let it go. There's only so much feedback people can hear and actually respond to. But there are also helpful things to say.

gambler 6y ago

> Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry. His lectures and books really are harmful. Beginners read them and get the impression that you can design good software by following a bunch of simplistic rules of thumb. In reality, you need to understand what trade-offs you're making when committing to certain design decisions and, even more importantly, you need to be able to discuss this with other people. For example, it's not "small functions are good", it's "when you make a function smaller, here are the benefits and here are costs". Primitive, sloganistic thinking is the bane of software engineering profession right now.

amw-zero 6y ago
I don't think he's harmful. I think you take the good with the bad with him. He's way too convicted to trust blindly, but he also talks about some great topics that aren't widely discussed. So, if you consider him the leader of a religion, you'll be led astray. But if you just read critically, you'll see that he definitely has a lot of insight to take away. Just discard the stuff that you don't agree with.

sktrdie 6y ago

I think Bob is a very insightful person and has great intuition and probably more experience than any of us. Sure he has certain bias towards certain things; who doesn't really? Saying that his posts are harmful is a bit of a stretch.

charlieflowers 6y ago
Even smart, highly qualified people (which Bob is) are prone to cognitive bias. One such bias is, the more you have espoused something, the more fervently you believe in it, and the harder it is for you to acknowledge any shortcomings of it. So I agree with the parent ... his writings are in many cases harmful. They're a mix of good and bad, but often net harmful.
nojito 6y ago
How much experience can someone have who hasn’t coded professionally in probably 15 years? Look at how much growth happened in the last 15 years.
Silhouette 6y ago
I think Bob is a very insightful person and has great intuition and probably more experience than any of us. Why on earth would you think that? Saying that his posts are harmful is a bit of a stretch. Mentor your first few people who keep defending rookie mistakes with "But Uncle Bob said..." and you might change your mind about that. Bob Martin says some sensible things, but he also says some things that are at best debatable and at worst outright contradicted by the evidence base, and he says all of them with great conviction and presumed authority so that his target audience can't tell the difference. That alone makes him dangerous as a source of advice.
wglb 6y ago
> more experience than any of us. I have been developing for 54 years. I have been through all manner of design philosophies, from Structured Programming, to Object Oriented Programming, to Agile, to TDD along with hack-it-till-it-works. If you don't do the engineering, which he does not teach, you are going to struggle. I believe this is a harmful post.

fizixer 6y ago

Bob Martin belongs to the OO-evangelism camp that emerged from the OO fad of mid-1990s. Another OO-evanglist who belongs to this camp is Ron Jeffries. For a textbook example of how much of a snake-oil OO-evangelism is, checkout the sudoku solver fiasco involving Ron Jeffries and Peter Norvig (you'll find plenty of search results regarding this).

inopinatus 6y ago
I’m no fan of Bob Martin, but the Ron Jeffries fiasco was a failure of TDD, not of OOP. The meandering inability to focus on writing a solution, instead becoming lost in modelling the problem, is a hallmark of the tunnel vision that TDD engenders. He’d have screwed it up in Prolog.
wglb 6y ago
That was a dramatic failure of TDD, contrasted with Peter's enlightened solution.

gilbetron 6y ago

Last year I came up with a new term for a type of developer: The Medium Developer. Medium in that they have a medium amount of experience (3-7 years, not that all in that range fall in this category), and Medium in that they have a medium amount of talent (not bad, not great), and Medium in that the religiously consume and spout Medium articles. They are the most zealous type of developer I've encountered. They believe TDD is the One True Way, or they think CI/CD with iterations in the minutes where you constantly commit to master prevents all bugs, or that SOLID is the word of the developer gods. They are awful to work with and be around. All of those concept I mentioned have benefits in them, but not as a religion. Medium programmers lack nuance and deep experience and are dismissive of those that do, they see it as weakness. When their favorite technique doesn't take them to the holy Nirvana of software, they lash out at other, less zealous developers and blame their lack of discipline. Completely shitty people - I just hope they grow out of it. But they are seductive in their intensity and (bad) managers love to hear how they have a simple solution to all their woes - rather than software development being inherently difficult (because you only have to do a specific hard things once, but that's another discussion!)