…posted something really nasty about Ron Jeffries. I deleted it and asked him to moderate it.
My advice to him below is followed by his original comment underneath. I was amazed by it, and luckily, Ron is away, I think, so he won’t see it.
One to watch, I’m afraid.
Codeslinger - how would you feel if someone wrote about you like that? Even if you are correct, this barrage of insults makes you look like an immature jerk, and raises the question, how much do you know about this stuff, anyway?
Regardless, we don’t tolerate personal attacks on this forum. Moderate your comment or don’t make it.
I suggest you can get the same points across more effectively and less offensively, using the Socratic approach of asking dumb questions. He would start by saying “please forgive me asking, because I’m not an expert on this, but what happens if you put in + to start with?” And so on. Doing it the “please explain…” way is devastatingly effective, without the need to be nasty.
I’ve copied and pasted your original post below so you don’t lose the points you were making.
I’m doing this for your benefit, because I’m hoping you didn’t set out to be a deliberate jerk.
------------------- original comment -----------
A short essay going by the name
. . . . . PLUS THE PLUS PROBLEM . . . . .
in which I claim that Ron Jeffries:
- uses lousy TDD
- to create a bad calculator
- should better be using BDD
- excuses lack of design because of focus on tests
- weighs in with his „authority“ to make it look good
Perhaps he’s doing this deliberately to show more interesting problems up front, but, alas, he then fails to step back and solve some basic ones.
Let me ask you:
- What happens when you press + on a freshly started calculator?
- What happens if you press + two times in a row in midst of a calculation?
- Without looking at the code!
These are random questions, I’ve chosen them (and the headline) simply because the word PLUS appears several times in Ron’s article and it got stuck somehow.
Let me say that I’m not going to answer the above questions. I cannot answer them without looking at the code and even then it might take some time.
Let’s dive into the article
Ron is a proponent of TDD. He’s not saying so at the very beginning, which is perhaps a good thing, because he ignores the rule of „tiny steps“ and immediately dives in with a test where he wants to calculate “13*3=”.
What should he do true to TDD? Maybe turn the calculator on test that it shows “0”. At least that’s what I would expect from a common calculator. Oh, Ron’s calculator shows nothing? So be it, then test for an empty string. Why is Ron doing this? Well, it makes typing “13” into the caculator easier. If there’s already a “0” in the display you’ll have a special case.
Back to “13*3=” and how Ron is going to solve it. He’s got no program, so there will be a runtime error by Lua (good), then he creates a calculator skeleton that runs but fails its test (good).
In order to make the test pass, Ron changes the press function to accept everything.
WHAT?
I know that we’re not going to invent a key pad to protect the doors of Fort Knox, but at least a calculator that we can depend on. Ron’s claim seems to be that by further testing he will eliminate all bugs. I’m in doubt. Instead of allowing wanted functionality he allows everything and goes on to further single out some special cases. Yes, I know, in his article he thinks about limiting the display input to numbers, but when is he going to actually do this?
At this moment I can point you back to my original questions. Why is it difficult to answer them? Because Ron allows many things, then tries to limit the collateral damage. You don’t know what the calculator as a whole can do, you know that it’s got some special cases where it’s got some loosely defined functionality. It’s not the lack of tests that denies a clear answer (even if some kinds of test can definitely help), it’s the lack of “design”.
Tests and more tests
Ron writes some more tests. Ron gets annoyed by the underpowered test functions and combines them to make them more readable. Wow. Or less messy. The term “behavior” is lying around in the article, that’s the B of BDD. Why isn’t Ron using BDD then?
Time to explain.
TDD is - despite its name - not about tests. It’s about writing a specification and proving that the software fulfills it. The tests are the means to go this way. To avoid this confusion the term was changed to BDD, which essentially does the same and at the same time tries to get back your attention to another property of the underlying tests.
BDD proposes that you name your tests by describing the behavior.
function turning_on_the_calc_shows_nothing()
local c = Calculator()
-- A ronculator does not show 0. No no no. Don't you dare!
c:displayIs("")
end
This is a test that I understand.
function no_leading_zeroes()
local c = Calculator()
-- single 0 is OK
c:check("0", "0")
-- no "00" in the display!
c:check("0", "0")
end
The lack of what Ron calls “design”
Ron excuses the lack of “design” because of the focus on tests. The design will evolve nearly automatically. I say that Ron is denying a structured approach. I don’t say that TDD is bad, it is sometimes badly explained and in Ron’s case applied lousily. And please look at what BDD has to say about TDD. I don’t say that you cannot start with a simple design like Ron does, but please stay sane.
What Ron is doing is flailing around code patch after code patch which is absolutely necessary because he bombed away a wall and now needs to put bricks into place to repair the damage. That’s why you still don’t know if the + key is doing the right thing at all times. Yes, Ron is aware that there are problems and even names some of them, but with his “bombing technique” and opening up an endless gap, don’t you think it is difficult to come up with ideas of all (ALL!) problems that you now have to catch?
I have some strong opinions:
- Ron is not a good teacher.
- Ron is not a good programmer (and his article is at a basic skill level).
- Ron favors tests above thinking (and know you know why I’ve put “design” in quotes several times).
- This is not the writing of a man who claims to have soooooo much experience in this field.