C. Keith Ray

C. Keith Ray writes about and develops software in multiple platforms and languages, including iOS® and Macintosh®.
Keith's Résumé (pdf)

Wednesday, June 8, 2011


(repost from 2006.Aug.12 Sat)

Check out Dave Astel's paper (pdf) on TDD/BDD. Quotes:

[...] There are a score of books available on TDD, mine even won a Jolt award. So it seems that everything is rosy? Everyone who's doing TDD is fully understanding it and getting the full benefit, right?

Fat Chance!

Too few people I talk to really understand what it's really about. That means that many people who practice TDD are not getting the full benefit from it. What's wrong?

The focus on testing

Well... one thing is that people think it's about testing. That's just not the case.

Sure, there are similarities, and you end up with a nice low level regression suite... but those are coincidental or happy side effects. So why have things come to this unhappy state of affairs? Why do so many not get it?[...]

So with people thinking about testing, it's easy to come up with all sorts of negative reactions and reasons not to do it... especially when time gets short and the pressure's on.

By the way, I HATE saying TDD is "not about the testing". I have to say it now and then because of people not realizing it's about designing, rather than testing. The fact that the word "test" is in the name just helps confuse the issue. My preference for naming this design technique, is to call it "Behavior Driven Design". Or "Behavior-Spec Driven Design". With BSDD, I could say BSDD is about the behavior-specs, but mostly aboutdriving design.

Alistair Cockburn's "Executable Example Driven Design" (XXDD) is OK, but a bit long-winded. And I don't want to have say "Dos-equis Driven Design is not about beer." :-)

The problem is mental frameworks. People reject ideas that don't fit into their mental framework. You say "test" and the listener's mental framework comes up with these and other assumptions:

  • Testing can be done manually.
  • I can do implementing, someone else can do testing.
  • Testing looks for bugs.
  • Tests need something to test.
  • Testing is hard.
  • We can skip testing if we are good enough programmers, or time is short.

None of those assumptions directly applies to TDD. TDD can't be separated into tests written by one person and code written by another because the TDD cycle of test-code-refactor is a design process that one person (or a pair) goes through in cycles, where each cycle takes only minutes. TDD/BDD helps me find bugs, but that's not the purpose of TDD. TDD isn't TDD is you do the "test" part manually.

If you say "Test-Driven Development is not about the tests," that usually doesn't provide the zen-like kick in the brain-pan that the speaker intends. Instead, the phrase gets rejected because it doesn't fit into the listener's mental framework for "tests". The listener probably thinks you're nuts. He or she might just flip the "bozo bit" and stop listening to you.

If instead you say "Behavior Spec", the listener's mental framework will have fewer contradictory assumptions. For example:

  • Specs are written before coding.
  • Specs can provide examples.
  • Specs tell you what you need to implement.
  • Someone else can write specs and I can write the code.

Not all of those assumptions are true for BDD, but there are fewer contradictions to this idea of BBD that you're trying to introduce into someone's mental framework. Behavior Specs are written before the code exists (though only minutes before). Behavior Specs are executable examples. Behavior Specs tell you, more or less, what you need to implement next. There is still the contradictory idea that someone can write the Spec and someone else can write the code, but that isn't as difficult to overcome as all the other assumptions that come up with the word "test".

Thursday, June 2, 2011

What part of the brain calculates how a whip works?

Imagine a whip, in which each centimeter of the whip contains a data processor node, that calculates the position of the node in 3d space, the acceleration and velocity of the node in 3d space, the relative angle between this node and the next node, and the strength and angle of the pull on this node from the previous node, and so on.

Imagine each of these nodes gathering gigabytes of data, as a talented master of the whip, whose only control of this leather string of nodes comes from the handle in his hand, waves and curls the whip in the air, to snap it with precision, the tip exceeding the speed of sound, to clip a playing card or other some other target.

How much could we learn from examining and processing that data? What equations could we derive?

No doubt simulating this activity would take bank of CPUs some time to crank through the numbers. Far more time than the real-time action that took place.

How does a man do it? Practice, of course. And the more esoteric calculations are done in parts of our brain that are not subject to conscious reasoning. The parts that can predict the not-entirely parabolic path of ball thrown in baseball or football.

Would it not be interesting if the simulation of a whip could be repurposed to predict movements in currency-trading, stocks and bonds, real-estate prices, national economies?

In some limited situations the number of variables might not be that different. The forces and effects, velocity and acceration and position, could have analogs in this financial world.

How would a whip-weilder of finance practice? How would he get feedback? Could it be visible enough and fast enough to allow the esoteric calculating parts of his brain reliably direct his (financially metaphoric) hand?