Martin's attitude on this isn't surprising attitude, unfortunately. When surgery was first becoming a discipline, surgeons also didn't feel the need to wash their hands and resisted it, even...
But if you're actually interested in making software better, then you should realize that being careful and using tools that prevent mistakes are not mutually exclusive — using tools that prevent mistakes frees up your mental energy to focus on preventing higher level errors, rather than worrying about null pointer exceptions and double-frees.
Martin's attitude on this isn't surprising attitude, unfortunately. When surgery was first becoming a discipline, surgeons also didn't feel the need to wash their hands and resisted it, even though it objectively improved outcomes. I say it's not surprising, but it is ironic given that he is pushing his own methodology for improving code — writing tests. But I guess telling you to use the static analyzer or a strongly typed language doesn't make him money. But buying his books and videos about writing unit tests does!
As for the political stuff, I haven't read or seen any talks where he did those things, but can totally believe it. We watched some of his coding videos at work and they were utterly bizarre. These are videos put out by O'Reilly books and based on the Clean Code book. Every video starts with 5-10 minutes of a completely unrelated astronomy lesson. He never returns to these lessons and they appear to be added solely so he can write off his astronomy equipment from his income tax. (He also uses hundreds of tchotchkes from conferences he attended for apparently the same reason.) That part's just odd, but the disturbing part is how he does several little vignettes in each video where he dresses up as different characters with strange voices and acts out scenes that supposedly explain a point he's trying to make. Some are just stupid, like his Sherlock Holmes or Captain Kirk and Spock impressions. But some are really disturbing like "Randy," who I guess is supposed to be a flighty Microsoft software engineer, but whom I seriously thought was supposed to be a guy with a mental illness when he first showed up in the video. They're degrading, poorly acted, filmed, and edited, and basically pointless.
I think the section you're reacting to might be misinterpreting Martin's position. In particular this line: That's stark and a bit hyperbolic. I can't speak for him, but a more charitable...
I think the section you're reacting to might be misinterpreting Martin's position. In particular this line:
[T]he solution to the software apocalypse is not more tools. The solution is better programming discipline.
That's stark and a bit hyperbolic. I can't speak for him, but a more charitable interpretation might be that new tools aren't necessarily going to help when the whole corporate culture is screwed up. I doubt he's literally against all progress in improving programming tools, though I haven't paid much attention recently and perhaps he's gotten more dogmatic.
Keep in mind that as a consultant (which is his background) you get brought into bad situations and see people doing bad stuff. Often, if they had the right attitude, the tools they already have could be used to do so much more. (Other times, their process and tools really are terrible. It depends on the situation.)
It sounds like he's really not good at video, though.
Anecdotal, I can't think of a single instance, short of maybe built-in testing frameworks, where he's for improvement. (This can probably be easily disproved, though) Robert Martin genuinely...
I doubt he's literally against all progress in improving programming tools
Anecdotal, I can't think of a single instance, short of maybe built-in testing frameworks, where he's for improvement. (This can probably be easily disproved, though)
...a more charitable interpretation might be that new tools aren't necessarily going to help when the whole corporate culture is screwed up.
Keep in mind that as a consultant (which is his background) you get brought into bad situations and see people doing bad stuff.
Robert Martin genuinely believes that if a programmer is under schedule pressure and takes shortcuts to fulfill it, then it's the fault of the programmer, and not the managers/higher-ups who decided on the schedule. There's a conflict of interest there, of course; since it's the higher-ups that pay his invoices, and they hired him, then they must be right! It's all those damn overworked programmers' fault!
He believes that programmers should "just do a better job" programming, and yet admonishes methods that allow programmers to do just that.
He believes that "the solution to the software apocalypse – the solution to bad code – is more code" is inherently faulty, and yet his entire career hinges on advocating for exhaustive testing at the expense of everything else, which hinges on, you guessed it, writing more code, while deriding things that actually reduce the amount of code one has to write, or intentionally refusing to understand such things. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it."
He doesn't even understand what the halting problem is, which is insane for someone saying that programmers should be better and more disciplined.
[snip -- had a bunch more examples here, but they had far too much vitriol, maybe I'll save them for my own blog post or something]
This seems like an uncharitable interpretation of encouraging workers to resist management pressure. I think programmers often do have more pull than they realize since programmers aren't so easy...
Robert Martin genuinely believes that if a programmer is under schedule pressure and takes shortcuts to fulfill it, then it's the fault of the programmer, and not the managers/higher-ups who decided on the schedule. There's a conflict of interest there, of course; since it's the higher-ups that pay his invoices, and they hired him, then they must be right! It's all those damn overworked programmers' fault!
This seems like an uncharitable interpretation of encouraging workers to resist management pressure. I think programmers often do have more pull than they realize since programmers aren't so easy to replace. Much of what Agile is about (or at least was back when I learned it; it's drifted a lot) is helping programmers push back against unreasonable requests and how to find more productive ways to collaborate with managers to come up with schedules that are realistic.
I just realized I may be heavily biased against this because I've seen how horribly it can go wrong. Good programmers aren't easy to replace. Barely competent programmers are a dime a dozen....
I just realized I may be heavily biased against this because I've seen how horribly it can go wrong.
This seems like an uncharitable interpretation of encouraging workers to resist management pressure. I think programmers often do have more pull than they realize since programmers aren't so easy to replace.
Good programmers aren't easy to replace. Barely competent programmers are a dime a dozen.
Much of what Agile is about (or at least was back when I learned it; it's drifted a lot) is helping programmers push back against unreasonable requests and how to find more productive ways to collaborate with managers to come up with schedules that are realistic.
"Agile" is a worthless designation these days, unfortunately; lots of companies claim to use it. When I was looking for a new job, more companies claimed that they were agile than claimed to use proper source control.
Pushing back assumes something fundamental that a lot of people take for granted: that management is acting flexibly and in good faith. I've personally seen developers laid off because sales promised a client something by a deadline, the developers said that the deadline was ridiculous, management ignored it, and the developers missed it.
Yes, how much pull you have depends on the person and that’s political. It’s going to depend a lot on the circumstances. Having someone with clout who can advocate for the programmers seems...
Yes, how much pull you have depends on the person and that’s political. It’s going to depend a lot on the circumstances. Having someone with clout who can advocate for the programmers seems important for correcting this kind of imbalance?
I think it’s one thing consultants often do, though. The same advice has more weight coming from an outsider. But ideally the goal is to correct the imbalance so the consultant doesn’t have to do it.
Not every company can be helped, though, and sometimes the best advice would be to find another job as soon as you can.
I agree that “agile” is not a useful keyword when looking for a job. If they say they do a particular flavor then that might be a bit more interesting.
I'm honestly happy that Sam Hughes started this whole anti-Clean Code trend. I've always viewed Robert Martin as a programming charlatan, and was constantly shocked to see people recommending his...
I'm honestly happy that Sam Hughes started this whole anti-Clean Code trend. I've always viewed Robert Martin as a programming charlatan, and was constantly shocked to see people recommending his work as a way to improve their skill.
Can you explain what you mean by "charlatan"? I think he puts way too much emphasis on testing (though I do testing myself and think it's very helpful in certain limited circumstances). I think...
Can you explain what you mean by "charlatan"? I think he puts way too much emphasis on testing (though I do testing myself and think it's very helpful in certain limited circumstances). I think some of his ideas about things like 3 line functions are ridiculous. But I don't feel like he's trying to deceive anyone. What is the deception you feel he's committing?
When I wrote "charlatan", I straight-up meant "writes poor quality code and gets by solely on marketing and blog posts". However, I've looked for the examples I was thinking of, and after googling...
Can you explain what you mean by "charlatan"?
When I wrote "charlatan", I straight-up meant "writes poor quality code and gets by solely on marketing and blog posts". However, I've looked for the examples I was thinking of, and after googling a few phrases, it seems like my brain somehow combined Robert Martin and another blogger (who I'll call YB); I found the articles I was thinking of under YB's name. As such, I take back the outright "charlatan" accusation.
However, that does not eliminate the "was constantly shocked to see people recommending his work as a way to improve their skill" sentiment I had, or my dislike for him.
But I don't feel like he's trying to deceive anyone. What is the deception you feel he's committing?
A few things. (What follows are lots of arbitrary feelings that I'll try to put into words, which I'm terrible at doing.)
I feel that his pumping up and inflation of the power and successes of TDD, as a TDD consultant, borders on deception. (Mind you, I don't have anything against TDD itself, or dislike him because of his TDD practices. Kent Beck is someone I respect; arguably, he's the one that popularized TDD.) He entwines TDD and professionalism in an iff relationship. He unironically views himself as a modern-day Ignaz Semmelweis, the doctor that popularized washing hands to reduce mortality rates, and TDD as the software dev version of good hygiene. He gives examples of large, visible, well-known software failures, and how TDD would avoid them... and then never follows up on how. The examples he usually gives are all dismissable:
Healthcare.gov - literally too many flaws to list, most of which TDD or Martin's "software craftsmanship" spiels definitely wouldn't fix, such as standard government contract shenanigans and masses of inexperienced programmers.
Toyota and their "unintended acceleration" issues - this was a case of bad code in general, and the general fuckery that supposedly went on in the codebase wouldn't be changed that much with the introduction of TDD, since there would be ways to work around it; a more fundamental course on programming would be needed. They didn't even have code reviews, FFS. At that point, who knows what the actual advantages of moving from relatively sane code to TDD would have been. (Not even mentioning the actual things wrong with the non-software... programmers latched onto this one because having a program described as having 10,000 global variables and being called spaghetti code in court is something that grabs attention)
Another possible deception, but largely biased: most of us don't actually know about Martin's production code quality. For a long time, the only publicly available example of his code was FitNesse, which was viewed as pretty damn ugly, even for its time. (Disclosure: While writing this, I noticed that he has several projects on Github these days, but I honestly haven't gone through them because life threw a curveball at me recently and I just want to finish typing this. May do so later.)
And one more, for the road:
I think he puts way too much emphasis on testing
Another possible deception that you may be aware of: testing, over everything else, including modern tools that a good chunk of programmers use. Type systems? Forget those, write unit tests to check inputs. Languages/options that inherently eliminate bugs? Nope, write tests instead. Static analysis or compiler checks? Pfffft what. Advocating for tests is one thing, but advocating for testing being the main tool you use during software development is folly when you have so much more available to you and deny it.
I've got a few more examples, but those are the ones that stick out the most. Not sure if I fully addressed your question, so I'm open to followups.
Edit: Motherf-- just reread the article and your other comment, and saw how much of that I repeated. Welp.
I've always found this zealotry for 'tests' over types to be particularly weird. Ultimately they are both tools which help improve our confidence in our code: they each work better in different...
Another possible deception that you may be aware of: testing, over everything else, including modern tools that a good chunk of programmers use. Type systems? Forget those, write unit tests to check inputs. Languages/options that inherently eliminate bugs? Nope, write tests instead. Static analysis or compiler checks? Pfffft what. Advocating for tests is one thing, but advocating for testing being the main tool you use during software development is folly when you have so much more available to you and deny it.
I've always found this zealotry for 'tests' over types to be particularly weird. Ultimately they are both tools which help improve our confidence in our code: they each work better in different contexts and are not mutually incompatible. So, just use the right tool at the right time?
I actually conceptualise tests and types identically: they are both just predicates! A type is a predicate that I can use outside of run-time and a test is a predicate I can use at run-time with a simulated input. Asserts and error-handling flows are predicates we use at run-time with real input. In many languages types are usually only concerned with checking that functions will plug together properly, but they can also be used to reify valid and invalid domain states, even at the value level (dependent types), which are also what we use tests and predicates in our domain code for! I'd love to see a programming language which reifies all of these things in the same way, where I could define a regular predicate function and then use it as a type at run-time.
Yes, there is test zealotry, but I haven't seen anyone advocate using tests instead of types in a language that has a static type system? (How would that even work?) What I have seen, though, is...
Yes, there is test zealotry, but I haven't seen anyone advocate using tests instead of types in a language that has a static type system? (How would that even work?)
What I have seen, though, is arguments by people who are using a scripting language like Ruby or Python, saying that if you write comprehensive tests, they can give you most of what types give you. (This is back when static vs. dynamic types was a live debate; nowadays even scripting languages are getting static type systems retrofitted so it seems that debate is more or less over?)
A bit of historical context: it looks like Martin started his company in 1991, which is four years before Java even existed. The Agile movement got started with Smalltalk. Many ex-Smalltalk programmers look back at Smalltalk with nostalgia, especially compared to C++ and Java in the early days.
I feel like a lot of this pushback doesn't take history into account; some of these arguments didn't age well, but it was less clear at the time when the nice tools we have now didn't exist or weren't very good. (Clean Code is itself 12 years old and some of its ideas go back to Smalltalk too. In particular, Smalltalk programmers liked writing tiny methods with long names, so you would know which arguments to pass in.)
At the time I approached these ideas with curiosity. Not having programmed in Smalltalk myself, I wondered what I missed and why people were nostalgic about it. But despite dabbling with Smalltalk a bit, I never got into it myself, and I've always been somewhat skeptical that it was as nice an environment as people remember. I find Smalltalk systems pretty hard to understand.
I haven't seen exactly that, but my first development job was at a company that fetishized TDD to a degree that I dare say nobody else can match. Uncle Bob and Kent Beck are the holy ones, and...
but I haven't seen anyone advocate using tests instead of types in a language that has a static type system
I haven't seen exactly that, but my first development job was at a company that fetishized TDD to a degree that I dare say nobody else can match. Uncle Bob and Kent Beck are the holy ones, and their guidance was followed religiously. I once got into a debate with one of the other devs who took the TDD gospel to heart, about writing a test for a CSS file.
I look back on my time there as the developer equivalent of military boot camp. They had their Agile/TDD/xtreme programming process, and they followed it to the letter, no exceptions. It definitely instilled some habits that I still use today, but it was also quite detached from the reality of how everyone else on the planet does software development.
I once worked at a startup that did extreme programming and we had a somewhat different take on it. The “extreme” is more along the lines of “let’s see what happens if we turn the dials all the...
I once worked at a startup that did extreme programming and we had a somewhat different take on it. The “extreme” is more along the lines of “let’s see what happens if we turn the dials all the way to 11.” We probably would have discussed if there is some way to test a CSS file, but that doesn’t mean we necessarily would have done it or stuck with it.
There is supposed to be a spirit of experimentation. You try things and then periodically talk about if you should keep doing it or abandon it.
It was nice to work at a place where everyone there was willing to try. Sadly, though we wrote some decent code, the concept was wrong and the startup failed. We should have pivoted, but “pivoting” wasn’t really a thing yet.
Yeah, this explains it very well. I get where you're coming from. I didn't know if there was something bigger I was missing. I think we're on the same page. I read a lot of skeptic-related web...
I've got a few more examples, but those are the ones that stick out the most. Not sure if I fully addressed your question, so I'm open to followups.
Yeah, this explains it very well. I get where you're coming from. I didn't know if there was something bigger I was missing. I think we're on the same page. I read a lot of skeptic-related web sites and when I hear "charlatan", I think of people like Peter Popoff or Silvia Browne who are outright frauds. I put Martin in the category of deluded believer. I think he's getting high his own supply.
Martin is widely respected and followed in the software industry, having coauthored the Agile Manifesto, written several books, and given many talks. However, I've personally found his technical ideas to be consistently dogmatic and sloppy, he repeatedly makes sexist remarks and made many people feel uncomfortable and unwelcome at conferences and communities he's in, and I find his views on race and politics extremely harmful. This post is a primer on why I think Martin's views on software are frequently unhelpful and incorrect, as well as an overview of some of his comments on race, gender, and politics.
On the contrary to a lot of posts here, I found Robert C. Martin's SOLID principles to be very helpful early in my career, and still consider them when I work on projects, although certainly not...
On the contrary to a lot of posts here, I found Robert C. Martin's SOLID principles to be very helpful early in my career, and still consider them when I work on projects, although certainly not to an obsessive, completionist capacity.
Presidential Politics
Martin tweeted a quote from Trump, voted for Trump, and has said that there's "plenty to agree with" in Trump's policies.
This is a strange addition knowing that this post is supposed to be framed as a takedown, and reminds me of an earlier thread on Tildes where OP and several commenters were implying that supporting Trump's administration is, by default, "bad". Navigating to the linked tweets, nothing Martin says sounds unreasonable, and he comes off as level-headed overall.
Thanks, I actually somehow missed that post where he rants about the "left-wing media." While I don't think simply voting for Trump is evidence that Martin is a reactionary, I think his verbiage...
Thanks, I actually somehow missed that post where he rants about the "left-wing media." While I don't think simply voting for Trump is evidence that Martin is a reactionary, I think his verbiage in his rant echoes a lot of the conspiracy theory-talk seen on alt-right forums, and paints him pretty clearly as a reactionary.
That said, I still think parts of Wesley's post are half-baked or painting with broad brushstrokes. This part is particularly confusing:
What does this sentence mean? I took the time to navigate to the links to figure it out. The first is an apology for using sexist language on his blog. The second is an extended analogy for James Damore's firing from Google. Is the implication that: if you believe James Damore's firing from Google was wrong, that you are therefore, sexist or espousing sexist ideas? In the post, Martin even suggests that Damore's belief in the biological differences between men and women is incorrect. I don't get the impression that Martin is contradicting himself here.
Martin's attitude on this isn't surprising attitude, unfortunately. When surgery was first becoming a discipline, surgeons also didn't feel the need to wash their hands and resisted it, even though it objectively improved outcomes. I say it's not surprising, but it is ironic given that he is pushing his own methodology for improving code — writing tests. But I guess telling you to use the static analyzer or a strongly typed language doesn't make him money. But buying his books and videos about writing unit tests does!
As for the political stuff, I haven't read or seen any talks where he did those things, but can totally believe it. We watched some of his coding videos at work and they were utterly bizarre. These are videos put out by O'Reilly books and based on the Clean Code book. Every video starts with 5-10 minutes of a completely unrelated astronomy lesson. He never returns to these lessons and they appear to be added solely so he can write off his astronomy equipment from his income tax. (He also uses hundreds of tchotchkes from conferences he attended for apparently the same reason.) That part's just odd, but the disturbing part is how he does several little vignettes in each video where he dresses up as different characters with strange voices and acts out scenes that supposedly explain a point he's trying to make. Some are just stupid, like his Sherlock Holmes or Captain Kirk and Spock impressions. But some are really disturbing like "Randy," who I guess is supposed to be a flighty Microsoft software engineer, but whom I seriously thought was supposed to be a guy with a mental illness when he first showed up in the video. They're degrading, poorly acted, filmed, and edited, and basically pointless.
I think the section you're reacting to might be misinterpreting Martin's position. In particular this line:
That's stark and a bit hyperbolic. I can't speak for him, but a more charitable interpretation might be that new tools aren't necessarily going to help when the whole corporate culture is screwed up. I doubt he's literally against all progress in improving programming tools, though I haven't paid much attention recently and perhaps he's gotten more dogmatic.
Keep in mind that as a consultant (which is his background) you get brought into bad situations and see people doing bad stuff. Often, if they had the right attitude, the tools they already have could be used to do so much more. (Other times, their process and tools really are terrible. It depends on the situation.)
It sounds like he's really not good at video, though.
Anecdotal, I can't think of a single instance, short of maybe built-in testing frameworks, where he's for improvement. (This can probably be easily disproved, though)
Robert Martin genuinely believes that if a programmer is under schedule pressure and takes shortcuts to fulfill it, then it's the fault of the programmer, and not the managers/higher-ups who decided on the schedule. There's a conflict of interest there, of course; since it's the higher-ups that pay his invoices, and they hired him, then they must be right! It's all those damn overworked programmers' fault!
He believes that programmers should "just do a better job" programming, and yet admonishes methods that allow programmers to do just that.
He believes that "the solution to the software apocalypse – the solution to bad code – is more code" is inherently faulty, and yet his entire career hinges on advocating for exhaustive testing at the expense of everything else, which hinges on, you guessed it, writing more code, while deriding things that actually reduce the amount of code one has to write, or intentionally refusing to understand such things. "It is difficult to get a man to understand something, when his salary depends upon his not understanding it."
He doesn't even understand what the halting problem is, which is insane for someone saying that programmers should be better and more disciplined.
[snip -- had a bunch more examples here, but they had far too much vitriol, maybe I'll save them for my own blog post or something]
This seems like an uncharitable interpretation of encouraging workers to resist management pressure. I think programmers often do have more pull than they realize since programmers aren't so easy to replace. Much of what Agile is about (or at least was back when I learned it; it's drifted a lot) is helping programmers push back against unreasonable requests and how to find more productive ways to collaborate with managers to come up with schedules that are realistic.
I just realized I may be heavily biased against this because I've seen how horribly it can go wrong.
Good programmers aren't easy to replace. Barely competent programmers are a dime a dozen.
"Agile" is a worthless designation these days, unfortunately; lots of companies claim to use it. When I was looking for a new job, more companies claimed that they were agile than claimed to use proper source control.
Pushing back assumes something fundamental that a lot of people take for granted: that management is acting flexibly and in good faith. I've personally seen developers laid off because sales promised a client something by a deadline, the developers said that the deadline was ridiculous, management ignored it, and the developers missed it.
Yes, how much pull you have depends on the person and that’s political. It’s going to depend a lot on the circumstances. Having someone with clout who can advocate for the programmers seems important for correcting this kind of imbalance?
I think it’s one thing consultants often do, though. The same advice has more weight coming from an outsider. But ideally the goal is to correct the imbalance so the consultant doesn’t have to do it.
Not every company can be helped, though, and sometimes the best advice would be to find another job as soon as you can.
I agree that “agile” is not a useful keyword when looking for a job. If they say they do a particular flavor then that might be a bit more interesting.
I'm honestly happy that Sam Hughes started this whole anti-Clean Code trend. I've always viewed Robert Martin as a programming charlatan, and was constantly shocked to see people recommending his work as a way to improve their skill.
Can you explain what you mean by "charlatan"? I think he puts way too much emphasis on testing (though I do testing myself and think it's very helpful in certain limited circumstances). I think some of his ideas about things like 3 line functions are ridiculous. But I don't feel like he's trying to deceive anyone. What is the deception you feel he's committing?
When I wrote "charlatan", I straight-up meant "writes poor quality code and gets by solely on marketing and blog posts". However, I've looked for the examples I was thinking of, and after googling a few phrases, it seems like my brain somehow combined Robert Martin and another blogger (who I'll call YB); I found the articles I was thinking of under YB's name. As such, I take back the outright "charlatan" accusation.
However, that does not eliminate the "was constantly shocked to see people recommending his work as a way to improve their skill" sentiment I had, or my dislike for him.
A few things. (What follows are lots of arbitrary feelings that I'll try to put into words, which I'm terrible at doing.)
I feel that his pumping up and inflation of the power and successes of TDD, as a TDD consultant, borders on deception. (Mind you, I don't have anything against TDD itself, or dislike him because of his TDD practices. Kent Beck is someone I respect; arguably, he's the one that popularized TDD.) He entwines TDD and professionalism in an
iffrelationship. He unironically views himself as a modern-day Ignaz Semmelweis, the doctor that popularized washing hands to reduce mortality rates, and TDD as the software dev version of good hygiene. He gives examples of large, visible, well-known software failures, and how TDD would avoid them... and then never follows up on how. The examples he usually gives are all dismissable:Another possible deception, but largely biased: most of us don't actually know about Martin's production code quality. For a long time, the only publicly available example of his code was FitNesse, which was viewed as pretty damn ugly, even for its time. (Disclosure: While writing this, I noticed that he has several projects on Github these days, but I honestly haven't gone through them because life threw a curveball at me recently and I just want to finish typing this. May do so later.)
And one more, for the road:
Another possible deception that you may be aware of: testing, over everything else, including modern tools that a good chunk of programmers use. Type systems? Forget those, write unit tests to check inputs. Languages/options that inherently eliminate bugs? Nope, write tests instead. Static analysis or compiler checks? Pfffft what. Advocating for tests is one thing, but advocating for testing being the main tool you use during software development is folly when you have so much more available to you and deny it.
I've got a few more examples, but those are the ones that stick out the most. Not sure if I fully addressed your question, so I'm open to followups.
Edit: Motherf-- just reread the article and your other comment, and saw how much of that I repeated. Welp.
I've always found this zealotry for 'tests' over types to be particularly weird. Ultimately they are both tools which help improve our confidence in our code: they each work better in different contexts and are not mutually incompatible. So, just use the right tool at the right time?
I actually conceptualise tests and types identically: they are both just predicates! A type is a predicate that I can use outside of run-time and a test is a predicate I can use at run-time with a simulated input. Asserts and error-handling flows are predicates we use at run-time with real input. In many languages types are usually only concerned with checking that functions will plug together properly, but they can also be used to reify valid and invalid domain states, even at the value level (dependent types), which are also what we use tests and predicates in our domain code for! I'd love to see a programming language which reifies all of these things in the same way, where I could define a regular predicate function and then use it as a type at run-time.
Yes, there is test zealotry, but I haven't seen anyone advocate using tests instead of types in a language that has a static type system? (How would that even work?)
What I have seen, though, is arguments by people who are using a scripting language like Ruby or Python, saying that if you write comprehensive tests, they can give you most of what types give you. (This is back when static vs. dynamic types was a live debate; nowadays even scripting languages are getting static type systems retrofitted so it seems that debate is more or less over?)
A bit of historical context: it looks like Martin started his company in 1991, which is four years before Java even existed. The Agile movement got started with Smalltalk. Many ex-Smalltalk programmers look back at Smalltalk with nostalgia, especially compared to C++ and Java in the early days.
I feel like a lot of this pushback doesn't take history into account; some of these arguments didn't age well, but it was less clear at the time when the nice tools we have now didn't exist or weren't very good. (Clean Code is itself 12 years old and some of its ideas go back to Smalltalk too. In particular, Smalltalk programmers liked writing tiny methods with long names, so you would know which arguments to pass in.)
At the time I approached these ideas with curiosity. Not having programmed in Smalltalk myself, I wondered what I missed and why people were nostalgic about it. But despite dabbling with Smalltalk a bit, I never got into it myself, and I've always been somewhat skeptical that it was as nice an environment as people remember. I find Smalltalk systems pretty hard to understand.
I haven't seen exactly that, but my first development job was at a company that fetishized TDD to a degree that I dare say nobody else can match. Uncle Bob and Kent Beck are the holy ones, and their guidance was followed religiously. I once got into a debate with one of the other devs who took the TDD gospel to heart, about writing a test for a CSS file.
I look back on my time there as the developer equivalent of military boot camp. They had their Agile/TDD/xtreme programming process, and they followed it to the letter, no exceptions. It definitely instilled some habits that I still use today, but it was also quite detached from the reality of how everyone else on the planet does software development.
I once worked at a startup that did extreme programming and we had a somewhat different take on it. The “extreme” is more along the lines of “let’s see what happens if we turn the dials all the way to 11.” We probably would have discussed if there is some way to test a CSS file, but that doesn’t mean we necessarily would have done it or stuck with it.
There is supposed to be a spirit of experimentation. You try things and then periodically talk about if you should keep doing it or abandon it.
It was nice to work at a place where everyone there was willing to try. Sadly, though we wrote some decent code, the concept was wrong and the startup failed. We should have pivoted, but “pivoting” wasn’t really a thing yet.
Yeah, this explains it very well. I get where you're coming from. I didn't know if there was something bigger I was missing. I think we're on the same page. I read a lot of skeptic-related web sites and when I hear "charlatan", I think of people like Peter Popoff or Silvia Browne who are outright frauds. I put Martin in the category of deluded believer. I think he's getting high his own supply.
On the contrary to a lot of posts here, I found Robert C. Martin's SOLID principles to be very helpful early in my career, and still consider them when I work on projects, although certainly not to an obsessive, completionist capacity.
This is a strange addition knowing that this post is supposed to be framed as a takedown, and reminds me of an earlier thread on Tildes where OP and several commenters were implying that supporting Trump's administration is, by default, "bad". Navigating to the linked tweets, nothing Martin says sounds unreasonable, and he comes off as level-headed overall.
Thanks, I actually somehow missed that post where he rants about the "left-wing media." While I don't think simply voting for Trump is evidence that Martin is a reactionary, I think his verbiage in his rant echoes a lot of the conspiracy theory-talk seen on alt-right forums, and paints him pretty clearly as a reactionary.
That said, I still think parts of Wesley's post are half-baked or painting with broad brushstrokes. This part is particularly confusing:
What does this sentence mean? I took the time to navigate to the links to figure it out. The first is an apology for using sexist language on his blog. The second is an extended analogy for James Damore's firing from Google. Is the implication that: if you believe James Damore's firing from Google was wrong, that you are therefore, sexist or espousing sexist ideas? In the post, Martin even suggests that Damore's belief in the biological differences between men and women is incorrect. I don't get the impression that Martin is contradicting himself here.