Uncle Bob and Silver Bullets
hillelwayne.com
Uncle Bob and Silver Bullets
1–10 of 228 posts
Re: Uncle Bob and Silver Bullets
#2Well written! I’ve always cringed when I’ve read anything that Uncle Bob writes. It almost seems like his entire existence depends on the acceptance of unit testing, and the unjustified dismissal of tools, especially type systems, seems to me something a only a novice would do when evangelizing their favorite lang (we’ve all been there, right?...), until they get more experience with other methods and approaches.
Re: Uncle Bob and Silver Bullets
#3The problem is that the more tools you add, the more mistakes you make in the tools.
This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything. then you get communication failures because not everybody is Einstein.
So it is always a trade off.
And it would help if we stopped calling automated testing as testing and described what it is - a domain specific type system checker.
If we realised we always build a system and a compiler for that system we might stop reinventing the wheel so much.
Re: Uncle Bob and Silver Bullets
#4The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…
I don't get why automated testing is a "domain specific type system checker". Not saying it's not, I just don't get it. Maybe that's because my automated tests are pretty free-form and tend to be more about throwing mud at an algorithm and seeing if the results stick.
Your last line is bang on, though. We build a system, and a compiler (or processor) for that system. It doesn't matter if everything is "data driven" if your data is code and the thing it's driving is an interpreter.
Re: Uncle Bob and Silver Bullets
#5The article just focused on Uncle Bob's asking for "unit tests" in "Tools are not the answer". But I believe Bob just asked a rhetorical question over there. If someone is not writing unit tests at the very first place, he doesn't need to ask any other kind of tests furthermore, which are likely be less and less people raising hands.
Re: Uncle Bob and Silver Bullets
#6The problem is that the more tools you add, the more mistakes you make in the tools. This is the same debate we had previously about formal methods. They don't eliminate errors, they just move them to the testing systems and where there are several the gaps between them. Communication becomes more difficult between the people involved and you rapidly start looking for the Chief Programmer Solomon who knows everything…
Formal methods, in theory, don't eliminate errors. In practice, though, they do, as dramatically demonstrated by fuzzing CompCert C compiler.
Re: Uncle Bob and Silver Bullets
#7Well written! I’ve always cringed when I’ve read anything that Uncle Bob writes. It almost seems like his entire existence depends on the acceptance of unit testing, and the unjustified dismissal of tools, especially type systems, seems to me something a only a novice would do when evangelizing their favorite lang (we’ve all been there, right?...), until they get more experience with other methods and approaches.
It's hard to build your consultant image by telling people that multiple methods and tools might work. It's easier to market a simple cure.
Also, the point to "stop making shitty software" is not the same as "stop making mistakes". You can ship high quality software even while being human, it's just slower and more costly.
And while I agree with the article in general, I do believe the current balance has shifted towards too fast iteration and shoddy quality. Just look at the recent iOS/OSX releases. But even that might make business sense, because of the even shittier alternatives.
Re: Uncle Bob and Silver Bullets
#8More nihilism, this time in programming circles.
It's a turbulent age. I can't wait for it to pass.
Re: Uncle Bob and Silver Bullets
#9I'm usually pretty skeptical of Uncle Bob's stuff, but in this case I think that both Hillel and Bob are a little right. Tools do make a difference, as Hillel says, and can be used to mitigate risk. The key word there is mitigate, though. Bob is right in that the root cause of that risk is a lack of discipline. Such risk will persist, mitigated by tools or not, so long as that lack of discipline persists.
I think that "discipline" is a bit of trigger word for some folks, though. It can be seen to imply a personal failing, but as Bob's post explains "undisciplined" programming is usually a combination of personal and systemic problems. The programmers who created the hypothetical bad code shouldn't have created it, but they also shouldn't have been asked to, or placed under requirements that made bad code, over a long enough time, inevitable. You can have undisciplined cultures in the same way as you can have undisciplined programmers, PIs, requirements, or problem domains.
What's more, all of those are problems that it's important to be aware of. If anything, Hillel's article pushes a bit far (understandably) in the other direction, hinting that a failure of discipline is so inevitable as to be a waste of time to fight against.
It's important to do both: mitigate the impact of failures caused by lack of discipline, and understand and try to address the causes of that lack. Easier said than done, of course.
Re: Uncle Bob and Silver Bullets
#10Here is the post this post is in response to:
http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe...
I don’t interpret the original piece as saying any of these tools and techniques are not useful.
I interpret it as saying average developer mindset needs to shape up.
I tend to agree. I work with guys who believe in formal reasoning tools (we collaborated with Amazon’s ARG for example[1]), and use all these tools. These guys are almost compelled to write these tools and evangelize using the tools in an effort to help, because the developers around them don’t carefully reason about their code and it makes the guys who care crazy.
So you have two camps. People who believe correctness is important, and people who think continuous deployment is an answer to bugs. The first group is trying to help the second group through tools that can become part of the SDLC.
I read “Uncle Bob” as suggesting that’s not enough, it’s not the root cause — the second group needs to care.
I see nothing in his post that suggests the tools shouldn’t be used. (“I think that good software tools make it easier to write good software.“) But if the crowds in his talks aren’t using unit tests, are they really going to be using TLA+?
First, do no harm, then use like Light Table, Model Driven Engineering, and TLA+.
I take that as his point, and it seems painfully valid.
1. https://www.slideshare.net/mobile/AmazonWebServices/aws-rein...