So, what's an example of TDD "done right"? It should be his "FitNesse" program, right? (http://fitnesse.org/ ) Which means that finding problems in that code should point out areas where TDD is insufficient, right?
It contains its own web server, so I looked at just that part.
1) There was a directory traversal attack, in several places. This gave access to my /etc/passwd
6) The password hashing scheme was trivially broken, that is, given the hash I could construct a password which generated the same hash. Take a look - it still uses the same hash algorithm! https://github.com/unclebob/fitnesse/blob/master/src/fitness...
These meant the system was totally p0wnable.
And I found a few public servers using FitNesse as the web server.
I reported all of these years ago, and at least some of them were fixed. If these security issues are still present now, there's been plenty of time to fix them.
My analysis helped confirm my view that TDD generates happy-path tests, and strengthen my complaint that TDD, at least in the "red-green-refactor" formalism, ignores the rest of the testing/design that needs to be done even at that development stage where TDD is most effective.
6) The password hashing scheme was trivially broken, that is, given the hash I could construct a password which generated the same hash. Take a look - it still uses the same hash algorithm! https://github.com/unclebob/fitnesse/blob/master/src/fitness...
What fresh hell is this?
private byte[] encrypt(byte[] lock, byte[] key) {
int keyIndex = 0;
for (int i = 0; i < lock.length; i++) {
byte lockByte = lock[i];
byte keyByte = key[keyIndex++];
lock[i] = (byte) (lockByte + keyByte);
if (keyIndex == key.length)
keyIndex = 0;
}
return lock;
}
What's going on with all the Uncle Bob hate nowadays? I last heard about him ~6-8 years ago when people were preaching his sentiments about clean code and TDD.
I agree with some of his stuff, e.g. he was the one who convinced me how important tests are.
Also the blog author is exaggerating in lots of places e.g.:
"Safer Languages: The ‘Dark Path’." In the linked article he says "It’s not the fact that Swift and Kotlin are statically typed that has me concerned. Rather, it is the depth of that static typing." (I myself don't agree with Uncle Bob, I think nullable types are an awesome thing)
> What's going on with all the Uncle Bob hate nowadays?
Sensible people have always hated him and his bullshit - what products has he ever produced? I remember when he started posting his nonsense on Stack Overflow - boy, did he run out of there with his tail between his legs.
Really? Is that you criteria for whether someone knows something worthwhile about programming? What did Stroustrup create? How about Dijsktra? Tannenbaun? Herb Sutter? There is more than one way to contribute to the advancement of the state of the art and Martin has done plenty to advance it.
I'll take Knuth's ideas on goto over Dijsktra's any day, not just because Knuth has been the better thinker and writer, but also because he wrote TeX and other software.
Remember when structured programming was going to fix everything? Well, neither do I, but it still had a ton of momentum as a panacea when I was learning to program. Grown-ups with access to real computers would sniff at our BASIC machines and quote Djikstra at us.
Hm, I just checked the user page for an "Uncle Bob." It looks like he had 6 accepted answers out of a total of 10.
On all but one of the accepted answers a lot of the comments are simply kudos. Plus on most of his non-accepted answers, he has comments thanking him for his answer.
If I had judged StackOverflow by this user page alone, I would probably would have been persuaded to use StackOverflow. :)
Where's the "tail between his legs" post you are referring to?
> Where's the "tail between his legs" post you are referring to?
I didn't mention a post. He came to stack overflow, posted a few answers for which he obviously expected instance acceptance, and then, once he realised that no-one particularly wanted anything to do with him, immediately disappeared.
I don't find evidence for the claim that he expected instant acceptance for any of the posts he made. What's your evidence for that claim?
I also don't find evidence that "no-one particularly wanted anything to do with him." Especially given that the majority of his answers were the accepted answer, why do you claim this?
Finally, what's the relevance of him "immediately" ceasing his posts? Users of crowd-sourced services have all kinds of usage patterns for all kinds of reasons. Frankly, I find fatuous to notice a sudden lack of use and jump to the conclusion that it must be due to the user having been humiliated or shamed (which is what "tail between legs" refers to).
I'm guessing they're referring to the fact that he only answered questions from March to October 2009. That's a short time, but we shouldn't really expect people to donate time answering questions on SO either.
TBF, I think a lot of us joined it in the early days, contributed a bit, found it not to our liking or that it wasn't where we wanted to spend a lot of time for some reason, and moved on. Someone moving on after a few, apparently, positive encounters doesn't really indicate anything other than that they moved on.
Sensible people should have a rather high bar for hating people.
> what products has he ever produced?
His impact hasn't so much been physical products as teaching.
He has taught a lot of useful stuff. For me there is one particular conference 12 or so years ago that I still thibk of again and again.
It is about refactoring methods and it was brilliant and by following the resulting code becomes much easier to reason about. Some reason needs ro be applied, but less than if I hadn't learned those ideas.
Please don't post personal invective like this to HN. Maybe you don't owe $UNCLE any better, but you owe this community better if you're posting to it, because the global effect of this kind of thing is destructive of what we want HN to be.
He's been really active lately pushing his methods and insulting people who don't agree with him. He's also thrown a few tantrums over the last year or so that gotten him more negative attention.
There's a difference between engaging people in conversation over disagreements and flat out insulting people. Grown men throwing temper tantrums is never pleasant and should not be encouraged, and to be honest it was never "the way" for most people.
I do like his style, but not because it is a good style, or should be emulated. But because it is entertaining, and is getting rare (among people worth listening too, anyways)
By "the way" I mean the alpha males of days gone by who were so certain of their correctness that... they acted like Uncle Bob
For one thing, on Stack Overflow there's a steady drumbeat of replies and comments that take Martin's writings and aphorisms as being the alpha and omega of software quality.
Martin has a lot of good advice (along with some dubious attitudes) for someone relatively new to programming, but he most definitely does not have the last word on the issue.
I think it's partially that he reminds me of a motivational speaker that end of the day just ends up saying things that are incredibly simplistic and not really useful. His message is basically "unit tests are good!", and it's like, cool, got anything else? Youre famous for this? I also think the "uncle" thing comes across painfully pretentious. I'm 35, if you're not actually my uncle I'm sure not calling you that.
Funny paradox though: if they were that useful he probably wouldn't need to say it all the time :) (To be clear I'm not anti-unit test, they're fine, but they're a very small part of a much larger picture)
Awesome - thank you. I had no idea. I suppose there are a lot of sayings like that in different languages. Which does not make much sense unless you know that language.
Well designed Static Types are better than Unit Tests. They only fail because they are hard, because c++ is hard, because our present cultural reality is optimized for Time to Market, because we dont teach computer science to kids in elementary school and because if it works, it works, we ship it and move on.
I propose that Unit Tests have arisen in popularity solely because of the rise of Python, as a band aid to the complexity that rises as an untyped code base gets large.
Matt Godbolt does a great job giving an overview of the power of static types to ensure correctness in this C++ On Sea Talk [1].
I've worked in places where people evangelize Unit Tests. But it is certainly true that no one really code reviews the Unit Tests that hard. People generally skim the tests file to see how many tests there are and give it the thumbs up. But then they seriously review the feature code. If TDD is to truly followed, shouldnt we review the tests more thoroughly than the implementation? Does anyone actually do that?
My basic assertion is that, in practice, no one _really_ follows TDD. I think it's more of an easy political win. If you evangelize TDD, you look like a "real programmer" who cares about Stability and Reliability, but are you actually following through with that? Are you rejecting pull requests because some test case isn't present? Are you primarily reviewing the tests above the implementation? Is it actually feasible to test every code path in an untyped language? I would propose that it is not. That correctness can only come through the compiler, through a static type system.
This is basically the other extreme. Why must we pick a side? Static types are useful. Unit tests are useful.
One of my projects involves a bunch of graphics code. A lot of tricky math and special cases. When I was trying to refactor that code, I added a bunch of unit tests to make sure images would continue to be rendered correctly. And they prevented me from shipping a bunch of rendering bugs! Bugs that the type system would have let slip through, because the function signatures didn't change.
> This is basically the other extreme. Why must we pick a side? Static types are useful. Unit tests are useful.
I did not say that Unit Tests are not useful. I am merely proposing that they are less useful than Static Typing and hypothesizing on why TDD is common, and commenting on my experience with TDD evangelists.
There's more than 1 class of problems that unit tests solve though. I'd still want pretty good testing over my business logic heavy code. I'd also like to point out that Python's typing module + mypy is, while still not perfect, quite good as a tacked-on type system.
Also I believe unit tests as a concept first gained popularity in the Java ecosystem, not Python, which kind of negates the assertion that they are popularized because of Python's typing shortcomings.
No, it was from the smalltalk guys, who later designed Eclisped and came to Java. But it was from smalltalk and never caught up until PHP, Ruby and python came strong.
I remember reading Kent Beck's TDD book many years ago. Most of the example code is in Java.
There's one chapter that uses Python, but that's just to show how a TDD framework could be implemented in a language which (at that time) didn't have one.
That's a very broad statement. There are classes of bugs that can be detected by the compiler, and there are classes of bugs that cannot. Both of these statements are also true for Unit Tests.
They tell you if you broke a class of things, and I think that class of issues is pretty broad:
* when you remove a method from a class, no user of that class calls that method
* when you change the return type of a method, all users of that method are updated to handling the new type
* in type systems with nullability, they make sure all users handle null values, and they make sure methods with non-null return types never return a null value
There are functional changes which can break your code which won't be caught by the type system, but there are a lot of details which the type system will make sure you check when you make changes.
-Warning -Werror -Wall -Wextra will tell you plenty.
And you can add -Wconversion if you want to be clear on int conversion, and maybe -WShadow if you want to be sure you code is easily understandable.
I did TDD five time. Twice with python, one with Go, onw with Rust and once with Common lisp. It was usefull with python, not great with Go and especially Common lisp (i mean, debugging while the code is held is better than debugging with tests, and Common lisp is a really good language to prototype, and TDD takes that out). And Miserable with Rust. With rust i'll test functionality and unsafe code, but i won't ever do TDD again, even if you paid me FU money.
TDD is more of a Java thing and it has a lot to do with the lack of a good type system in Java. TDD essentially lets you create a class that encapsulates a type and then enforce the contract for that type through the tests. Modern type systems tend to just let you do it directly so the unit tests are a little less useful.
If you really want to cover as much of the cases as possible in your tests, you end up all this bespoke mocking, spying, argument capturing and asserting stuff. Your test suite tends to be completely designed around some third party mocking library. True TDD evangelists will tell you that you will learn to write your feature code to enable the usage of the mocking library to test it. That is giving a lot of power to your mocking library.
It is a substantial effort to onboard your team to the unit testing framework. It is a substantial effort to read the unit tests and review them.
At a lot of shops, it's an unspoken fact that the tests are more complex than the feature code. That the tests take longer to write than the feature code. And that frankly no one really cares if you just skip a whole class of tests because you couldnt figure Mockito out.
The test suite ends up being huge. The code inside the test suite only makes sense to a small subset of the developers and the large majority of the test suite never actually produces value. We've all seen the teams that ignore their failing test suite. We've all seen the team that spends a sprint trying to speed up their test suite.
I cant prove it, I dont have data, but in my opinion, these giant, unwieldy test suites are largely a by product of the lack of strong typing in javascript & python.
The thing that I hold near to my heart on this topic is that no system is better than having an architectural leader on your team who can answer questions and guide the team. Our task is to create higher level languages that allow a single leader to review more code, because each code review is smaller. By creating "bolted on" systems like Unit Tests that produce physically more code, we are wasting the architects time. Over time, I believe we will move towards code that is trivially verifiable on sight, and we will move away from code that is complex and hard to manually verify.
The underlying point people miss is that you might have the best tool in the world, but without any discipline to start using it and continue using it, it will go unused. Discipline matters.
Edit: relevant to the other thread, this is a pattern with writings about Uncle Bob. When you read him directly disagreements are usually not so clear-cut as detractors make them. Clean Code is the tech book that I've argued with most, still worth reading, as opposed to certain other tech books. But I grant that he expresses himself increasingly poorly when moving from books to blogs to tweets, and even his books are written in a 'school of martial arts' style (admitted to in the preface/intros), i.e. presenting His Way without the side detours into alternatives and innumerable context-sensitive exceptions. This makes it easy to mischaracterize him as saying things like "don't ever comment code, comments are bad!" but if you read his book/code you will in fact find some comments. Perhaps his beliefs are slightly more nuanced?
I'm sure they are. He makes his living as a software process consultant, right?
And the author of the original article is right: Bob Martin is dismissive of tools that aren't unit tests, and "discipline" in Bob's article is the discipline to... write unit tests. Your "underlying point" is just making an uninteresting truism out of a more specific argument.
I mean I'm not a fan of Strunk and White either, and the fact that E.B. White often violated the rules from Strunk and White to good effect when writing his own prose doesn't redeem the book, if anything it damns it.
The author's getting tripped up on whether Uncle Bob is suggesting to use "correctness techniques" and missing the forest for the trees a bit. Uncle Bob's central theme of advice is basically to stop thinking in cargo cults. "If I just do X Technique / use X Tool, my code will be better" is a fast track to "I am doing all 100 Techniques / using all 100 Tools and my code still has bugs. Maybe I just need new Techniques / Tools."
Nothing is enough. As humans, we build things shittily. And the chaos of the universe also makes sure that everything slowly becomes shitty over time. You should consider techniques as a small part in a grander scheme, which is the holistic implementation, operation, and maintenance of the products your code makes up.
I have been running systems for a while. I've seen a lot of code - some of it even good. It still makes for shitty products, because the people writing the code are thinking more about the code than how it's operated/maintained/supported and how the user experiences it. There is no technique or tool or code that can ensure the rest. Show me the best code in the world and I will show you an unhappy user.
Bob's article dismisses a whole host of techniques as a setup to preaching the "discipline" of unit testing. You're projecting a bunch of your own frustration with user experience and software lifecycle issues onto his vagaries.
User experience is its own engineering domain, by the way, and most people, including developers, are terrible at it without exposure to the best ideas in it. It's not just a matter of "thinking" about user experience (or lifecycle requirements, for that matter).
This style of rebuttal article has me too jaded to focus on the topic and see behind the hegemonic politics.
I would have ignored the post and not commented except that the referenced R. Martin article is the same style of immediate reference invocation diatribe and they both suffer from the same short comings. Turtles all the way down.
Alas, this comment is more of the same, shame on me. Please learn from our mistakes.
i didn’t learn anything useful by reading the linked article but i have learned a lot by reading uncle bob’s books. they have made a huge difference to the enjoyment i get from coding, and to the quality of my code. if you haven’t, i highly recommend taking a look and making your own judgement.
Sorry but I have to join the bashing.
Some years ago I wanted to get better at programming so I picked up his material. It took me less than 10 hours to realise he was just peddling the same thing as the Gang of Four book that was released in 1994.
I'm sorry but I'm not interested in your design patterns that only need to exist because your OOP language lacks more powerful constructs.
A lot has happened in terms of language design since 1994. If you are still stuck in Java 5 or something like that, please go ahead and read his books otherwise you will be better served by learning a modern language like Swift, Kotlin, Rust, etc...
I've been aware of Bob for quite a while during is career. His TDD discussions are good, and useful in some contexts. One of the very best craftsman programmers I know won't program any other way.
One thing that I see as counterproductive is his very strong opinions. One of his books calls out Java as not being object oriented or extensible due to the way that exceptions propagate.
The other thing to be aware of is that some problems cannot be solved by the incremental approach. The most famous one that I am aware of is an adherent to TDD tried to develop a program to solve sudoku. Bob complimented him on his honesty at trying publically, but didn't admit that the TDD approach didn't work.
TDD is probably a good approach for certain classes of problems, but whether or not those are interesting is my question.
Perhaps in his journey he will discover languages where variables don't have type, but values stored there do.
Not that this makes much of a difference since a lot of the academic production isn't coming from people building products but are still incredibly important to help us build software. A lot of the distributed systems work (like stuff Leslie Lamport did) wasn't part of a product but are all seminal to the systems we have nowadays, they might not even exist as they do if people in academia weren't doing research on it.
So you shouldn't stop listening to Uncle Bob because he hasn't built famous software products, but because a lot of the stuff he says is just bullshit not backed by any research or real world experience :)
Academia is (one would hope) built on a logical, provable process. The material should be peer reviewed. Ideally you can independently reproduce findings in a lab. If not, you should absolutely scrutinize it.
Martin's work is purely anecdotal, delivered with an authoritative tone. I might excuse that from a John Carmack, who built systems that changed an industry. Yet I've found Carmack's writing quite humble.
Thinking of the smartest people I've worked with over my career, none of them used the rhetoric of Martin. But they all made their living building software, not selling books and corporate training.
I kind of agree with your comment here and with what mlinhares responded with. There are a few engineers I enjoy following who give good, and actionable advice.
One is Scott Wvlaschin especially if you're interested in Functional Programming
Another is James Sinclair[0].
A couple other names, Ryan Florence and Michael Jackson (the dev, not the singer).
And one last one is Kent Dodds.
These are mostly people on the front end (since that's where I work). I've found content put out by all of them (articles, videos, tutorials etc) to be excellent and if not directly practical insightful.
They also all actively write software. I recommend taking a look when you have a chance. Better than uncle bob
You're right. On first read I thought it made a tongue-in-cheek turn to why you might listen to him anyway, got disgusted, and stopped reading. My mistake there. But really, why write a whole article about a number of pieces of clothing the emperor's not wearing?
SOLID principles, Release-Reuse Equivalency Principle (REP), Common Closure Principle (CCP), Common Reuse Principle (CRP), Acyclic Dependency Principle (ADP), Stable Dependencies Principle (SDP), Stable Abstractions Principle (SAP)... i'm sure there are others. Oh and a little thing called Agile software development, along with being a major early proponent of XP before agile existed.
If you're an object oriented developer, his design patterns are a big part of the normal definition of "good code." If you're in any kind of short project oriented work, his project practices are a go-to resource.
I know he's been a software developer since the 70s, but I don't know what, if any products he was hired for became famous. Is that an important bar for someone who talks about software quality amd development process?
Actually, yes it is. I'm aware of his "contributions"; you don't have to patronize me.
What important software, products, or systems have the authors of the Agile manifesto created? What did most of them do for a living when they wrote it, and what have they done since?
Not the GP, and I agree with some of the Uncle Bob skepticism -- often his fervor outweighs his content.
But several signers of the Agile Manifesto have done outstanding things. The Agile Manifesto itself is also outstanding (it may seem obvious now, but it was not obvious to the world it was published to).
Ward Cunningham invented the wiki for chrissakes.
So let's not throw out the baby with the bathwater.
OK, the wiki is clever, but it is not really a demonstration of the power of agile methods. I'd bet money it wasn't test-driven or sprinted or crc-carded or whatever into existence. Ward may as well have also invented an excellent salad dressing, as far as that bears on agile.
Not a big fan of the patterns movement either; not that there's anything wrong with any of the GoF patterns.
The agile manifesto is vague enough that people tend to project their aspirations onto it. It was true then and it's true now. I'm also old enough to remember when most of it was called "extreme programming", so it wasn't exactly a revelation at the time.
Almost no developers in the world make a career out of telling other people how to develop software. Since Bob does, his credentials, which are one part of "why should I listen to this guy?", do matter.
Martin had a publicly available product in the 2000s, FitNesse.
If someone promotes a given coding methodology, then inspecting code developed using that methodology may give insight into the limits of that methodology. See my comments about FitNesse posted elsewhere here, at https://news.ycombinator.com/item?id=26158917 .
No patronising intended; one can never be sure of another's context on here. I try to assume positive intent and honest, direct questions.
Now that I have a sense of what you know, I'm having a hard time answering your reiterated question without being patronising. Maybe I don't understand it.
You're asking if the creators of the most influential software development practice in the industry have ever done anything _else_ influential. And when someone points to the SOLID principles, which are arguably some of the most influential software design patterns of the last 30 years, that's not acceptable.
It's fine if you, personally, don't like software design patterns or SOLID principles, or if you've got some other iconoclasting thing going on. But you can't deny that that is an important system which has impacted our entire industry - particularly on questions of software quality - much more than many famous products. Candy Crush, Wordpress, and Excel are the first products that come to mind, and having seen the codebase for two of those... they don't have anything to add to discussions of software quality. :)
But if you're aware of Uncle Bob's contributions, then I presume familiarity with the contributions of others like Martin Fowler, Kent Beck, Ward Cunningham, Jeff Sutherland, etc. So I'm not sure what would convince you that these people have some worthwhile opinions to consider. They were lead developers at consulting companies and large research labs, all with decades of experience by that time.
I dunno, does it impress you that Kent Beck worked at facebook, or that he wrote the precursor to and first versions of JUnit? Or that he did the famous Christler C3 compensation system?
Is the most influential software development practice in the industry any good, or is it just another fad? How would you know?
Is your idea of software quality any good? How would you know? Why are you impressed with these guys? I'm not. I don't want to do what they do.
I'm much more impressed with Excel than anything I've seen from methodology gurus. I can only imagine how real-world crufty that code base is, but a lot of cruft is the residue of solving real, non-trivial problems. I know for a fact Excel has had a lot of that baked in over decades.
Did you ever see the blog posts where one of the original agile guys tried to write a sudoku solver with his methodology?
I make the following conjecture without proof: it is demonstrable that agile methods and design patterns are better suited to counting fruit at a grocery than to solving interesting problems with computers.
The article by Bob Martin accuses developers that do not follow his methods of being "undisciplined" and "sloppy" - that is sufficient grounds to question, not attack, his qualifications for doing so.
Not here though. Part of being a good HN contributor is learning to resist the temptation that comes up, when hitting the most provocative part of an article, to rush to the comments to address it.
I got fed up with Robert Martin years ago.
11 years ago I wrote an essay on "Problems with TDD" - http://www.dalkescientific.com/writings/diary/archive/2009/1... .
Martin was rather against my viewpoint.
So, what's an example of TDD "done right"? It should be his "FitNesse" program, right? (http://fitnesse.org/ ) Which means that finding problems in that code should point out areas where TDD is insufficient, right?
It contains its own web server, so I looked at just that part.
1) There was a directory traversal attack, in several places. This gave access to my /etc/passwd
2) This GET request deleted a file:
3) This uploaded a file to an arbitrary location:
4) There was a non-persistent cross-site scripting vulnerability due to incorrectly escaped HTML:
5) An uploaded file with an embedded NUL in filename would result in an infinite loop in the server:
6) The password hashing scheme was trivially broken, that is, given the hash I could construct a password which generated the same hash. Take a look - it still uses the same hash algorithm! https://github.com/unclebob/fitnesse/blob/master/src/fitness...
These meant the system was totally p0wnable.
And I found a few public servers using FitNesse as the web server.
I reported all of these years ago, and at least some of them were fixed. If these security issues are still present now, there's been plenty of time to fix them.
My analysis helped confirm my view that TDD generates happy-path tests, and strengthen my complaint that TDD, at least in the "red-green-refactor" formalism, ignores the rest of the testing/design that needs to be done even at that development stage where TDD is most effective.
6) The password hashing scheme was trivially broken, that is, given the hash I could construct a password which generated the same hash. Take a look - it still uses the same hash algorithm! https://github.com/unclebob/fitnesse/blob/master/src/fitness...
What fresh hell is this?
What's going on with all the Uncle Bob hate nowadays? I last heard about him ~6-8 years ago when people were preaching his sentiments about clean code and TDD.
I agree with some of his stuff, e.g. he was the one who convinced me how important tests are.
Also the blog author is exaggerating in lots of places e.g.: "Safer Languages: The ‘Dark Path’." In the linked article he says "It’s not the fact that Swift and Kotlin are statically typed that has me concerned. Rather, it is the depth of that static typing." (I myself don't agree with Uncle Bob, I think nullable types are an awesome thing)
> What's going on with all the Uncle Bob hate nowadays?
Sensible people have always hated him and his bullshit - what products has he ever produced? I remember when he started posting his nonsense on Stack Overflow - boy, did he run out of there with his tail between his legs.
Really? Is that you criteria for whether someone knows something worthwhile about programming? What did Stroustrup create? How about Dijsktra? Tannenbaun? Herb Sutter? There is more than one way to contribute to the advancement of the state of the art and Martin has done plenty to advance it.
> What did Stroustrup create?
Are you serious?
Maybe C++ could be considered a product, but that did not seem to be what the OP meant.
I'll take Knuth's ideas on goto over Dijsktra's any day, not just because Knuth has been the better thinker and writer, but also because he wrote TeX and other software.
Remember when structured programming was going to fix everything? Well, neither do I, but it still had a ton of momentum as a panacea when I was learning to program. Grown-ups with access to real computers would sniff at our BASIC machines and quote Djikstra at us.
Hm, I just checked the user page for an "Uncle Bob." It looks like he had 6 accepted answers out of a total of 10.
On all but one of the accepted answers a lot of the comments are simply kudos. Plus on most of his non-accepted answers, he has comments thanking him for his answer.
If I had judged StackOverflow by this user page alone, I would probably would have been persuaded to use StackOverflow. :)
Where's the "tail between his legs" post you are referring to?
https://stackoverflow.com/users/73476/uncle-bob
> Where's the "tail between his legs" post you are referring to?
I didn't mention a post. He came to stack overflow, posted a few answers for which he obviously expected instance acceptance, and then, once he realised that no-one particularly wanted anything to do with him, immediately disappeared.
I don't find evidence for the claim that he expected instant acceptance for any of the posts he made. What's your evidence for that claim?
I also don't find evidence that "no-one particularly wanted anything to do with him." Especially given that the majority of his answers were the accepted answer, why do you claim this?
Finally, what's the relevance of him "immediately" ceasing his posts? Users of crowd-sourced services have all kinds of usage patterns for all kinds of reasons. Frankly, I find fatuous to notice a sudden lack of use and jump to the conclusion that it must be due to the user having been humiliated or shamed (which is what "tail between legs" refers to).
I'm guessing they're referring to the fact that he only answered questions from March to October 2009. That's a short time, but we shouldn't really expect people to donate time answering questions on SO either.
TBF, I think a lot of us joined it in the early days, contributed a bit, found it not to our liking or that it wasn't where we wanted to spend a lot of time for some reason, and moved on. Someone moving on after a few, apparently, positive encounters doesn't really indicate anything other than that they moved on.
> Sensible people have always hated him
Sensible people should have a rather high bar for hating people.
> what products has he ever produced?
His impact hasn't so much been physical products as teaching.
He has taught a lot of useful stuff. For me there is one particular conference 12 or so years ago that I still thibk of again and again.
It is about refactoring methods and it was brilliant and by following the resulting code becomes much easier to reason about. Some reason needs ro be applied, but less than if I hadn't learned those ideas.
Please don't post personal invective like this to HN. Maybe you don't owe $UNCLE any better, but you owe this community better if you're posting to it, because the global effect of this kind of thing is destructive of what we want HN to be.
https://news.ycombinator.com/newsguidelines.html
He's been really active lately pushing his methods and insulting people who don't agree with him. He's also thrown a few tantrums over the last year or so that gotten him more negative attention.
That was the way, once upon a time.
I really like his stuff, I disagree with him a lot, good. I cannot be bothered with people I agree with all the time, boring
There's a difference between engaging people in conversation over disagreements and flat out insulting people. Grown men throwing temper tantrums is never pleasant and should not be encouraged, and to be honest it was never "the way" for most people.
I agree with you, really.
I do like his style, but not because it is a good style, or should be emulated. But because it is entertaining, and is getting rare (among people worth listening too, anyways)
By "the way" I mean the alpha males of days gone by who were so certain of their correctness that... they acted like Uncle Bob
Big Swinging Dicks
Not really a rare thing among programmers, see Linus Torvalds :)
For one thing, on Stack Overflow there's a steady drumbeat of replies and comments that take Martin's writings and aphorisms as being the alpha and omega of software quality.
Martin has a lot of good advice (along with some dubious attitudes) for someone relatively new to programming, but he most definitely does not have the last word on the issue.
Wait, why do you consider this article "hate"? It gives many examples of supposedly bad advice and makes a point to say they are wrong.
I think it's partially that he reminds me of a motivational speaker that end of the day just ends up saying things that are incredibly simplistic and not really useful. His message is basically "unit tests are good!", and it's like, cool, got anything else? Youre famous for this? I also think the "uncle" thing comes across painfully pretentious. I'm 35, if you're not actually my uncle I'm sure not calling you that.
> unit tests are good
Well I sure wish more people would get the damned message - maybe if enough people listened he wouldn’t have to keep saying it.
Funny paradox though: if they were that useful he probably wouldn't need to say it all the time :) (To be clear I'm not anti-unit test, they're fine, but they're a very small part of a much larger picture)
> I also think the "uncle" thing comes across painfully pretentious. I'm 35, if you're not actually my uncle I'm sure not calling you that.
It's a well known idiom:
https://en.m.wikipedia.org/wiki/Bob's_your_uncle
You might not think it's funny but it seems a lot of people so.
Also: if anyone gets annoyed by it then for a lot of people that seems to make it even funnier.
Just saying.
Awesome - thank you. I had no idea. I suppose there are a lot of sayings like that in different languages. Which does not make much sense unless you know that language.
I think it's just really dated and comes across weird.
Hah fair enough I had no idea! Today I learned.
I think that is a different idom.
The sense of "Uncle" in Uncle Bob is someone that is older than you and may or may not know more than you do, but is authoritarian about it.
I just wanted to point out that this article is from 2017, so it’s definitely not part of some sort of recent hate fest.
Edit: The title should probably include the “(2017)” tag.
Well designed Static Types are better than Unit Tests. They only fail because they are hard, because c++ is hard, because our present cultural reality is optimized for Time to Market, because we dont teach computer science to kids in elementary school and because if it works, it works, we ship it and move on.
I propose that Unit Tests have arisen in popularity solely because of the rise of Python, as a band aid to the complexity that rises as an untyped code base gets large.
Matt Godbolt does a great job giving an overview of the power of static types to ensure correctness in this C++ On Sea Talk [1].
I've worked in places where people evangelize Unit Tests. But it is certainly true that no one really code reviews the Unit Tests that hard. People generally skim the tests file to see how many tests there are and give it the thumbs up. But then they seriously review the feature code. If TDD is to truly followed, shouldnt we review the tests more thoroughly than the implementation? Does anyone actually do that?
My basic assertion is that, in practice, no one _really_ follows TDD. I think it's more of an easy political win. If you evangelize TDD, you look like a "real programmer" who cares about Stability and Reliability, but are you actually following through with that? Are you rejecting pull requests because some test case isn't present? Are you primarily reviewing the tests above the implementation? Is it actually feasible to test every code path in an untyped language? I would propose that it is not. That correctness can only come through the compiler, through a static type system.
1: https://www.youtube.com/watch?v=nLSm3Haxz0I
i feel like uncle bob’s opinion on static types arose when he became an aficionado of clojure, which doesn’t have them.
You can actually find his opinion forming even earlier, e.g. here's something from 2003: https://www.artima.com/weblogs/viewpost.jsp?thread=4639
His opinions do change though, if slowly. Perhaps in 10 years he'll try Common Lisp.
He mentions Python as a correlated factor in his love of unit tests. He also reveals how 'trendy' his mindset and strong opinions are.
This is basically the other extreme. Why must we pick a side? Static types are useful. Unit tests are useful.
One of my projects involves a bunch of graphics code. A lot of tricky math and special cases. When I was trying to refactor that code, I added a bunch of unit tests to make sure images would continue to be rendered correctly. And they prevented me from shipping a bunch of rendering bugs! Bugs that the type system would have let slip through, because the function signatures didn't change.
> This is basically the other extreme. Why must we pick a side? Static types are useful. Unit tests are useful.
I did not say that Unit Tests are not useful. I am merely proposing that they are less useful than Static Typing and hypothesizing on why TDD is common, and commenting on my experience with TDD evangelists.
I agree that Unit Tests are useful and valuable.
> Static types are useful. Unit tests are useful.
And unit tests with static types are even more useful still!
There's more than 1 class of problems that unit tests solve though. I'd still want pretty good testing over my business logic heavy code. I'd also like to point out that Python's typing module + mypy is, while still not perfect, quite good as a tacked-on type system.
Also I believe unit tests as a concept first gained popularity in the Java ecosystem, not Python, which kind of negates the assertion that they are popularized because of Python's typing shortcomings.
No, it was from the smalltalk guys, who later designed Eclisped and came to Java. But it was from smalltalk and never caught up until PHP, Ruby and python came strong.
I remember reading Kent Beck's TDD book many years ago. Most of the example code is in Java.
There's one chapter that uses Python, but that's just to show how a TDD framework could be implemented in a language which (at that time) didn't have one.
Static types don't tell you if you broke something when you changed the code.
That's a very broad statement. There are classes of bugs that can be detected by the compiler, and there are classes of bugs that cannot. Both of these statements are also true for Unit Tests.
That depends on the type system, although in practice encoding this information isn't easy I readily admit.
They tell you if you broke a class of things, and I think that class of issues is pretty broad:
* when you remove a method from a class, no user of that class calls that method
* when you change the return type of a method, all users of that method are updated to handling the new type
* in type systems with nullability, they make sure all users handle null values, and they make sure methods with non-null return types never return a null value
There are functional changes which can break your code which won't be caught by the type system, but there are a lot of details which the type system will make sure you check when you make changes.
Not entirely. Types let me know whenever I try to connect a water pipe to the electricity. Or when I forget to wire up the grounding.
What it can't tell me is that the lights go on when I flip the switch.
-Warning -Werror -Wall -Wextra will tell you plenty.
And you can add -Wconversion if you want to be clear on int conversion, and maybe -WShadow if you want to be sure you code is easily understandable.
I did TDD five time. Twice with python, one with Go, onw with Rust and once with Common lisp. It was usefull with python, not great with Go and especially Common lisp (i mean, debugging while the code is held is better than debugging with tests, and Common lisp is a really good language to prototype, and TDD takes that out). And Miserable with Rust. With rust i'll test functionality and unsafe code, but i won't ever do TDD again, even if you paid me FU money.
TDD is more of a Java thing and it has a lot to do with the lack of a good type system in Java. TDD essentially lets you create a class that encapsulates a type and then enforce the contract for that type through the tests. Modern type systems tend to just let you do it directly so the unit tests are a little less useful.
Another factor is the complexity of the tests.
If you really want to cover as much of the cases as possible in your tests, you end up all this bespoke mocking, spying, argument capturing and asserting stuff. Your test suite tends to be completely designed around some third party mocking library. True TDD evangelists will tell you that you will learn to write your feature code to enable the usage of the mocking library to test it. That is giving a lot of power to your mocking library.
It is a substantial effort to onboard your team to the unit testing framework. It is a substantial effort to read the unit tests and review them.
At a lot of shops, it's an unspoken fact that the tests are more complex than the feature code. That the tests take longer to write than the feature code. And that frankly no one really cares if you just skip a whole class of tests because you couldnt figure Mockito out.
The test suite ends up being huge. The code inside the test suite only makes sense to a small subset of the developers and the large majority of the test suite never actually produces value. We've all seen the teams that ignore their failing test suite. We've all seen the team that spends a sprint trying to speed up their test suite.
I cant prove it, I dont have data, but in my opinion, these giant, unwieldy test suites are largely a by product of the lack of strong typing in javascript & python.
The thing that I hold near to my heart on this topic is that no system is better than having an architectural leader on your team who can answer questions and guide the team. Our task is to create higher level languages that allow a single leader to review more code, because each code review is smaller. By creating "bolted on" systems like Unit Tests that produce physically more code, we are wasting the architects time. Over time, I believe we will move towards code that is trivially verifiable on sight, and we will move away from code that is complex and hard to manually verify.
Adding this John Blow youtube video where I feel he illustrates a good aspect of type systems.
https://www.youtube.com/watch?v=2J-HIh3kXCQ
If you read Uncle Bob’s post he does say “tools are fine” and that he’s invested in them too.
What’s so bad with adding discipline into the mix too?
The underlying point people miss is that you might have the best tool in the world, but without any discipline to start using it and continue using it, it will go unused. Discipline matters.
Edit: relevant to the other thread, this is a pattern with writings about Uncle Bob. When you read him directly disagreements are usually not so clear-cut as detractors make them. Clean Code is the tech book that I've argued with most, still worth reading, as opposed to certain other tech books. But I grant that he expresses himself increasingly poorly when moving from books to blogs to tweets, and even his books are written in a 'school of martial arts' style (admitted to in the preface/intros), i.e. presenting His Way without the side detours into alternatives and innumerable context-sensitive exceptions. This makes it easy to mischaracterize him as saying things like "don't ever comment code, comments are bad!" but if you read his book/code you will in fact find some comments. Perhaps his beliefs are slightly more nuanced?
I'm sure they are. He makes his living as a software process consultant, right?
And the author of the original article is right: Bob Martin is dismissive of tools that aren't unit tests, and "discipline" in Bob's article is the discipline to... write unit tests. Your "underlying point" is just making an uninteresting truism out of a more specific argument.
I mean I'm not a fan of Strunk and White either, and the fact that E.B. White often violated the rules from Strunk and White to good effect when writing his own prose doesn't redeem the book, if anything it damns it.
The author's getting tripped up on whether Uncle Bob is suggesting to use "correctness techniques" and missing the forest for the trees a bit. Uncle Bob's central theme of advice is basically to stop thinking in cargo cults. "If I just do X Technique / use X Tool, my code will be better" is a fast track to "I am doing all 100 Techniques / using all 100 Tools and my code still has bugs. Maybe I just need new Techniques / Tools."
Nothing is enough. As humans, we build things shittily. And the chaos of the universe also makes sure that everything slowly becomes shitty over time. You should consider techniques as a small part in a grander scheme, which is the holistic implementation, operation, and maintenance of the products your code makes up.
I have been running systems for a while. I've seen a lot of code - some of it even good. It still makes for shitty products, because the people writing the code are thinking more about the code than how it's operated/maintained/supported and how the user experiences it. There is no technique or tool or code that can ensure the rest. Show me the best code in the world and I will show you an unhappy user.
Bob's article dismisses a whole host of techniques as a setup to preaching the "discipline" of unit testing. You're projecting a bunch of your own frustration with user experience and software lifecycle issues onto his vagaries.
User experience is its own engineering domain, by the way, and most people, including developers, are terrible at it without exposure to the best ideas in it. It's not just a matter of "thinking" about user experience (or lifecycle requirements, for that matter).
This style of rebuttal article has me too jaded to focus on the topic and see behind the hegemonic politics.
I would have ignored the post and not commented except that the referenced R. Martin article is the same style of immediate reference invocation diatribe and they both suffer from the same short comings. Turtles all the way down.
Alas, this comment is more of the same, shame on me. Please learn from our mistakes.
i didn’t learn anything useful by reading the linked article but i have learned a lot by reading uncle bob’s books. they have made a huge difference to the enjoyment i get from coding, and to the quality of my code. if you haven’t, i highly recommend taking a look and making your own judgement.
Sorry but I have to join the bashing. Some years ago I wanted to get better at programming so I picked up his material. It took me less than 10 hours to realise he was just peddling the same thing as the Gang of Four book that was released in 1994.
I'm sorry but I'm not interested in your design patterns that only need to exist because your OOP language lacks more powerful constructs.
A lot has happened in terms of language design since 1994. If you are still stuck in Java 5 or something like that, please go ahead and read his books otherwise you will be better served by learning a modern language like Swift, Kotlin, Rust, etc...
I've been aware of Bob for quite a while during is career. His TDD discussions are good, and useful in some contexts. One of the very best craftsman programmers I know won't program any other way.
One thing that I see as counterproductive is his very strong opinions. One of his books calls out Java as not being object oriented or extensible due to the way that exceptions propagate.
The other thing to be aware of is that some problems cannot be solved by the incremental approach. The most famous one that I am aware of is an adherent to TDD tried to develop a program to solve sudoku. Bob complimented him on his honesty at trying publically, but didn't admit that the TDD approach didn't work.
TDD is probably a good approach for certain classes of problems, but whether or not those are interesting is my question.
Perhaps in his journey he will discover languages where variables don't have type, but values stored there do.
Discussed at the time: https://news.ycombinator.com/item?id=15415278
What interesting software, systems, or products has "Uncle Bob" developed? Why should I listen to anything he says?
Not that this makes much of a difference since a lot of the academic production isn't coming from people building products but are still incredibly important to help us build software. A lot of the distributed systems work (like stuff Leslie Lamport did) wasn't part of a product but are all seminal to the systems we have nowadays, they might not even exist as they do if people in academia weren't doing research on it.
So you shouldn't stop listening to Uncle Bob because he hasn't built famous software products, but because a lot of the stuff he says is just bullshit not backed by any research or real world experience :)
Academia is (one would hope) built on a logical, provable process. The material should be peer reviewed. Ideally you can independently reproduce findings in a lab. If not, you should absolutely scrutinize it.
Martin's work is purely anecdotal, delivered with an authoritative tone. I might excuse that from a John Carmack, who built systems that changed an industry. Yet I've found Carmack's writing quite humble.
Thinking of the smartest people I've worked with over my career, none of them used the rhetoric of Martin. But they all made their living building software, not selling books and corporate training.
I kind of agree with your comment here and with what mlinhares responded with. There are a few engineers I enjoy following who give good, and actionable advice.
One is Scott Wvlaschin especially if you're interested in Functional Programming
Another is James Sinclair[0].
A couple other names, Ryan Florence and Michael Jackson (the dev, not the singer).
And one last one is Kent Dodds.
These are mostly people on the front end (since that's where I work). I've found content put out by all of them (articles, videos, tutorials etc) to be excellent and if not directly practical insightful.
They also all actively write software. I recommend taking a look when you have a chance. Better than uncle bob
[0]https://jrsinclair.com/
+1 on Kent Dodds. Clear thinking and good insight.
The article is about disagreeing with Robert Martin, not about why you should listen to him.
You're right. On first read I thought it made a tongue-in-cheek turn to why you might listen to him anyway, got disgusted, and stopped reading. My mistake there. But really, why write a whole article about a number of pieces of clothing the emperor's not wearing?
I feel like we could ask that about any author. But we don't go down that road in every post.
But do you have thoughts on the actual article?
SOLID principles, Release-Reuse Equivalency Principle (REP), Common Closure Principle (CCP), Common Reuse Principle (CRP), Acyclic Dependency Principle (ADP), Stable Dependencies Principle (SDP), Stable Abstractions Principle (SAP)... i'm sure there are others. Oh and a little thing called Agile software development, along with being a major early proponent of XP before agile existed.
If you're an object oriented developer, his design patterns are a big part of the normal definition of "good code." If you're in any kind of short project oriented work, his project practices are a go-to resource.
I know he's been a software developer since the 70s, but I don't know what, if any products he was hired for became famous. Is that an important bar for someone who talks about software quality amd development process?
Actually, yes it is. I'm aware of his "contributions"; you don't have to patronize me.
What important software, products, or systems have the authors of the Agile manifesto created? What did most of them do for a living when they wrote it, and what have they done since?
Not the GP, and I agree with some of the Uncle Bob skepticism -- often his fervor outweighs his content.
But several signers of the Agile Manifesto have done outstanding things. The Agile Manifesto itself is also outstanding (it may seem obvious now, but it was not obvious to the world it was published to).
Ward Cunningham invented the wiki for chrissakes.
So let's not throw out the baby with the bathwater.
OK, the wiki is clever, but it is not really a demonstration of the power of agile methods. I'd bet money it wasn't test-driven or sprinted or crc-carded or whatever into existence. Ward may as well have also invented an excellent salad dressing, as far as that bears on agile.
Not a big fan of the patterns movement either; not that there's anything wrong with any of the GoF patterns.
The agile manifesto is vague enough that people tend to project their aspirations onto it. It was true then and it's true now. I'm also old enough to remember when most of it was called "extreme programming", so it wasn't exactly a revelation at the time.
Almost no developers in the world have publically available products. Especially not in the 2000s.
Why are you, and other posters, so obsessed with needing to see something public?
The vast majority of software is made behind closed doors, the source will never be public, and no-one outside a company will ever know about it.
Stop invalidating other people's experience just because you can't inspect their code.
Almost no developers in the world make a career out of telling other people how to develop software. Since Bob does, his credentials, which are one part of "why should I listen to this guy?", do matter.
Yes they do, 100,000s do. They're called consultants and businesses use them every day.
Martin had a publicly available product in the 2000s, FitNesse.
If someone promotes a given coding methodology, then inspecting code developed using that methodology may give insight into the limits of that methodology. See my comments about FitNesse posted elsewhere here, at https://news.ycombinator.com/item?id=26158917 .
No patronising intended; one can never be sure of another's context on here. I try to assume positive intent and honest, direct questions.
Now that I have a sense of what you know, I'm having a hard time answering your reiterated question without being patronising. Maybe I don't understand it.
You're asking if the creators of the most influential software development practice in the industry have ever done anything _else_ influential. And when someone points to the SOLID principles, which are arguably some of the most influential software design patterns of the last 30 years, that's not acceptable.
It's fine if you, personally, don't like software design patterns or SOLID principles, or if you've got some other iconoclasting thing going on. But you can't deny that that is an important system which has impacted our entire industry - particularly on questions of software quality - much more than many famous products. Candy Crush, Wordpress, and Excel are the first products that come to mind, and having seen the codebase for two of those... they don't have anything to add to discussions of software quality. :)
But if you're aware of Uncle Bob's contributions, then I presume familiarity with the contributions of others like Martin Fowler, Kent Beck, Ward Cunningham, Jeff Sutherland, etc. So I'm not sure what would convince you that these people have some worthwhile opinions to consider. They were lead developers at consulting companies and large research labs, all with decades of experience by that time.
I dunno, does it impress you that Kent Beck worked at facebook, or that he wrote the precursor to and first versions of JUnit? Or that he did the famous Christler C3 compensation system?
Is the most influential software development practice in the industry any good, or is it just another fad? How would you know?
Is your idea of software quality any good? How would you know? Why are you impressed with these guys? I'm not. I don't want to do what they do.
I'm much more impressed with Excel than anything I've seen from methodology gurus. I can only imagine how real-world crufty that code base is, but a lot of cruft is the residue of solving real, non-trivial problems. I know for a fact Excel has had a lot of that baked in over decades.
Did you ever see the blog posts where one of the original agile guys tried to write a sudoku solver with his methodology?
I make the following conjecture without proof: it is demonstrable that agile methods and design patterns are better suited to counting fruit at a grocery than to solving interesting problems with computers.
Please don't cross into personal attack on HN. Articles can be interesting regardless of whom they're about or by.
https://news.ycombinator.com/newsguidelines.html
The article by Bob Martin accuses developers that do not follow his methods of being "undisciplined" and "sloppy" - that is sufficient grounds to question, not attack, his qualifications for doing so.
Not here though. Part of being a good HN contributor is learning to resist the temptation that comes up, when hitting the most provocative part of an article, to rush to the comments to address it.