Uncle Bob and Silver Bullets (2017)
hillelwayne.com
hillelwayne.com
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
curl 'http://localhost:8080/files/../../../../../../etc/passwd'
curl 'http://localhost:8080/files/?responder=deleteFile&filename=../../../../../../Users/dalke/This_is_a_file.txt'
POST /files/../../ HTTP/1.1
containing a header with
Content-Disposition: form-data; name="file"; filename="I_escaped.txt"
http://localhost:8080/files?responder=%3Cscript%3Ealert%28%22hi!%22%29%3C/script%3E
Content-Disposition: form-data; name="file"; filename="\0foo.txt"
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.
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;
}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)
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.
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.
Well I sure wish more people would get the damned message - maybe if enough people listened he wouldn’t have to keep saying it.
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
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
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.
Edit: The title should probably include the “(2017)” tag.
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.
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?
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 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).
Are you serious?
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.
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.
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.
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.
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.
And unit tests with static types are even more useful still!
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.
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.
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.
* 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.
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.
What it can't tell me is that the lights go on when I flip the switch.
His opinions do change though, if slowly. Perhaps in 10 years he'll try Common Lisp.
What’s so bad with adding discipline into the mix too?
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?
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.
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.
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).
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'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...
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.
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 :)
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.
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
But do you have thoughts on the actual article?
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?
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?
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.
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 .
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 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.
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.
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.