• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

The Backwards Bicycle and learning TDD

 
Marshal
Posts: 64710
226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
NOTE: This thread was split off from here: https://coderanch.com/t/698904/engineering/Software-Design-Rays-Interest-Rate

Junilu Lacar wrote:. . . Backwards Brain Bicycle video on YouTube . . . very similar to my experience in learning TDD. . . .

I hope nobody organised your learning like a reversed bicycle. The reversed bicycle is designed to deceive the user, who implicitly uses it like a normal bicycle. It should be possible to learn the reverse bicycle, but it takes a long time. Probably as long as it takes people to learn a new programming paradigm.

The ironic thing about that bicycle is that a bicycle at speed is inherently stable, and it is not controlled by turning the handlebars. If the rider in that video, which I have seen before, ever got up to speed (> 6mph), the bicycle would have become stable and could be controlled by the rider's moving his weight about. Until he stops, when the whole rigmarole starts again. The same applies to glasses which make the world appear to be in a different direction; they are almost impossible to learn to use.
 
Sheriff
Posts: 13517
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Junilu Lacar wrote:. . . Backwards Brain Bicycle video on YouTube . . . very similar to my experience in learning TDD. . . .

I hope nobody organised your learning like a reversed bicycle. The reversed bicycle is designed to deceive the user, who implicitly uses it like a normal bicycle. It should be possible to learn the reverse bicycle, but it takes a long time. Probably as long as it takes people to learn a new programming paradigm.


Actually, it was I who finally figured out that it helps to learn TDD in kind of a backwards way. In many ways, TDD is the Backwards Bicycle of programming.

The order of the steps in TDD as implied by the "Red - Green - Refactor" mantra does tend to deceive people who are trying to learn it. Because TDD tells them to "First, write a test and see it fail," people naturally think that's the first thing they have to learn to do. You could try to learn it that way but many people have a hard time with that approach. Just last Saturday, I was at a local meetup where people do pair-programming and try to learn TDD and one of the guys there said to me "I've read the books, I've watched the videos but I always have the same problem: I sit there looking at a blank screen and for the life of me, I can't wrap my head around how I'm going to write a test without any code already in place." This is a common experience and one that I went through myself.

Writing a test first before you even have any production code goes against the grain of what people are probably used to, which is writing the test after, if they even habitually write tests at all. I have found that people with the most experience in test-after style development have the hardest time unlearning that skill and reconfiguring their brains to think differently. It's a very uncomfortable feeling and I think it directly contributes to the high attrition rate of people trying to adopt the technique. It doesn't help that there are some people who teach TDD who either don't realize this or simply dismiss it as something that people just have to "get over."

I've even had other coaches tell me that they never experienced that sort of thing, that they took to TDD like a duck to water. Well, good for them, I would say. That doesn't mean that everyone's experience will be like theirs nor should we expect it to be. However, I believe that most people have the same experience I went through. How else can you explain the relatively low adoption rate? Many people try to learn it but most people just give up after the first few tries. I didn't give up because I knew this technique made sense. I was determined to learn it so I tried again and again for two years until, just like how the guy in the Backwards Bicycle video describes it, "... something in my brain clicked and I could suddenly do it! It was like a switch had been turned on in my head!"

Writing that first test is "the Wall" that many programmers have to power through if they want to learn TDD and that's not an easy thing to do.

That's why I start with refactoring now when I teach TDD rather than with unit testing. Refactoring provides a gentler path to TDD. Not many people know how to refactor but they can easily relate to it. Most people have a natural ability to recognize good code, especially when they see it compared to bad versions of the same idea. At the same time, most programmers are not very sensitive to code smells either. The evidence of that can be found right here in these forums. True, many of our forum members are beginners and inexperienced programmers but I have seen many "experienced" programmers who can't name more than a handful of code smells, much less recognize them readily in their code, and much less tell you the appropriate refactoring techniques they can use to deal with those smells.

There are 70 refactoring techniques in the Refactoring book by Fowler. Most people don't know this but there are 22 code smells catalogued in that same book. Twenty-two. And most people can't even name more than five. Even I can't name ten off the top of my head. But people can easily tell you two refactoring techniques: Rename and Extract.

What do these two techniques go back to? Kent Beck's Four Rules of Simple Design, specifically: #2 Code clearly expresses intent and #3 Code contains no duplication. Rename and Extract are the associated refactoring techniques, respectively.

TDD is about design. Refactoring is about design. If you want to learn how to do TDD, learn about design and how to improve designs through refactoring. Once you have that under your belt, it's easier to think of the first test because your focus turns to laying out the design in the test code instead of verifying behavior that's not even there in the first place. That, as Uncle Bob would say, is just crazy.
 
Campbell Ritchie
Marshal
Posts: 64710
226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . "First, write a test and see it fail," . . .

So, I would write a test method which expects a failure, maybe an IllegalArgumentException if I pass a negative argument, then write a method that takes a number as its argument and throws such an exception for negative arguments?
That is a bit like if somebody asked me how to get to the Station, and I started, “Well, the station's on Zetland St, so you go in from Zetland St, but now let's work out how to get to Zetland St.” That is backwards indeed

. . . I've even had other coaches tell me that . . . they took to TDD like a duck to water. . . .

You hear the same from people who go from procedural to OO programming. It takes time to “get your head round” the new paradigm. Winston Gutkowski confesses to taking (I think) two years to start thinkking in objects. Fortunately it didn't take me quite as long. Then you find that teachers who have never had that difficulty can't teach. Bernard Shaw (??) might have said, “Those who can, do; those who can't, teach,” but that is a misunderstanding of what teaching is. If you can do it, you don't know how you can do it and you therefore cannot explain the process to anybody else.

"... something in my brain clicked and I could suddenly do it! It was like a switch had been turned on in my head!" . . .

That is when the motion is transferred from cerebral control to cerebellar control. The coordination then comes naturally. It is a similar process to learning any motor activity, e.g. walking. Once a child tranfers control of their feet from cerebrum to cerebellum, they can go places reliably and save their brainpower for more useful things . . . or more mischievous things.
 
Junilu Lacar
Sheriff
Posts: 13517
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:

Junilu Lacar wrote:. . . "First, write a test and see it fail," . . .

So, I would write a test method which expects a failure, maybe an IllegalArgumentException if I pass a negative argument, then write a method that takes a number as its argument and throws such an exception for negative arguments?
That is a bit like if somebody asked me how to get to the Station, and I started, “Well, the station's on Zetland St, so you go in from Zetland St, but now let's work out how to get to Zetland St.” That is backwards indeed



Perhaps, but I don't really see it like that. I see it being more in line with design thinking and in particular, prototyping and testing. One fellow panelist in a presentation I gave on TDD recently reminded me of a really good way to put it: "Write the code you wished you could write." The first part of your reply that I quoted above alludes to that. You expressed the behavior of code you don't have yet and you do that as test code. That's prototyping using a test as your prototyping framework.
 
Junilu Lacar
Sheriff
Posts: 13517
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's another way I show that people think "backwards" from the way they should be if they want to learn TDD:

E.W.Dijkstra wrote:Program testing can be used to show the presence of bugs, but never to show their absence!


People can easily recognize if their perspective is aligned with this statement or not. If your perspective on testing is not aligned with this statement, then you're thinking about testing backwards from how you should be if you want to learn how to do TDD.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!