Hacker News Reader

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

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.

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.

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

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.

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.

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.

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.

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 :)

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

If you can't capture the side effects to determine if they're correct, you can't test it period. Property based testing, unit testing, or integration testing, doesn't matter.

> You can’t test everything.

The problem with that (tautological) statement is that too many people read it as: "you can't test everything, so don't bother testing anything".

People believe that even if you don’t say it, however. While TDD I’m sure started with good intentions, the reason it hasn’t seen as wide adoption as it could have, in my opinion, is that it is frequently stated as requiring that everything be developed from tests.

I find it much more convincing if someone were to say, “test what’s easy” instead, that’s all.

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!)

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.

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

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.

That was a dramatic failure of TDD, contrasted with Peter's enlightened solution.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

thanks