ArguingWithMyself
I was arguing with myself earlier this week. Well, not exactly, but rather with someone whose arguments were exactly parallel to my own when I was first picking up TDD. The issue was that it seemed like wasted motion (low-value activity) to create a test that fails, make it compile, write the code so that the test fails properly, and then write “fake”code so that it passes. As a starting procedure, it does sound a little daft.
This is the kind of thing that happens when we have incomplete instruction. I think we need to know what, how, and why. If one of those items is not given, or is misplaced by the novice, then we can't distinguish some useful techniques from a waste of time.
I had the “what” and the “how” without the “why”. By not understanding that we were first building a set of reliable tests, and that the tests were more valuable than the code, I missed the point.
I had another argument with a fellow who took rather an existential point of view. Given that the code is turned in with a set of running tests, why does it matter which comes first? I think I used that one too. I sort of knew, but didn't appreciate, how the process of TDD is engineered. That kind of appreciation took rather more practice and exposure. I had to go back and try to write some code (in Python, by the way) without tests before I appreciated how much the process had been helping me.
These were smart, fairly experienced people. As a result, they had a healthy BS filter. Their minds automatically would examine a new idea for signs of pedantic time-wasters and pointless activities. Smart people are like that. However, some items aren't really valuable alone, you have to have the context in which the value is high. This is my experience with agile principles and OOD principles, that a lot of sensible ideas are sensible in context but not as sensible outside of their context.
When I explained the larger context and the real value that is provided, it was easier to make a case that these techniques are worth trying. If I had simply jumped on the bandwagon, I could have probably started working in an agile way sooner, but I might not have learned these lessons in a deeper way that allows me to make a rational case for doing testing first and for following other rituals of the trade.
!commentForm
i won't argue with you....
either of you
either of you
It isn't immediately obvious that test-first is as much about process control as quality control. Maybe moreso.
The paradigm shift (forgive me) for me was learning to see software as always being in-process rather than an end result.
When the Wright brothers were trying to make the Kitty Hawk fly, there were famous phisicists write white papers explaning "why machines can't fly". The logic was that if machines could fly, pigs could also fly. Therefore machines could not fly. Period.
The Wright brother took the opposite approach. They too a kite, a large kite, and made sure it could be controlled from the earth to move left and right.
Then and only then they tried to control the kite sitting on top of it. Others were trying to design machines that would fly, but they were dying. Others wouldn't even care to try since famous phisicists were explaining why in theory that wouldn't work.
Nobody in America believed in the Wright brothers, so they went to Paris to show the Kitty Hawk. The rest is history.
So, people may believe in TDD or not. Probably there is no theory yet that explains why TDD works. But it works. That is all that matters. Explanations will arrive eventually and one of them will be good enough to apply as a theory.
The Wright brother took the opposite approach. They too a kite, a large kite, and made sure it could be controlled from the earth to move left and right.
Then and only then they tried to control the kite sitting on top of it. Others were trying to design machines that would fly, but they were dying. Others wouldn't even care to try since famous phisicists were explaining why in theory that wouldn't work.
Nobody in America believed in the Wright brothers, so they went to Paris to show the Kitty Hawk. The rest is history.
So, people may believe in TDD or not. Probably there is no theory yet that explains why TDD works. But it works. That is all that matters. Explanations will arrive eventually and one of them will be good enough to apply as a theory.
But the explanation does work. It works because it's supposed to, like pairing works.
I don't think its any kind of mystery of muscle memory or whatever. Understanding the context and the intent makes it much easier to digest. I think that not having it explained, only shown, is only good for winning over those who don't buy that it can work, but it doesn't work by mystery or faith. It's not a supernatural act.
But I think that there is a lot about TDD and agile that can definitely be taught. The secret seems to be listening enough to understand what they're not already understanding about it. That's a different skill than doing it, and I can't explain how that works. ;-)
I don't think its any kind of mystery of muscle memory or whatever. Understanding the context and the intent makes it much easier to digest. I think that not having it explained, only shown, is only good for winning over those who don't buy that it can work, but it doesn't work by mystery or faith. It's not a supernatural act.
But I think that there is a lot about TDD and agile that can definitely be taught. The secret seems to be listening enough to understand what they're not already understanding about it. That's a different skill than doing it, and I can't explain how that works. ;-)
Your point about seeing tests in the larger context is important. I remember that "ah, ha" moment when I began to see how all the XP practices fit together as an organic whole. They complement and reinforce each other. Another "ah, ha" moment was when I understood why it's "test first", not "test after"; because TDD is about driving what gets implemented, not just testing the results afterwards.
Add Child Page to ArguingWithMyself