Archive for January, 2014

Back in the 1940s a guy named Dvorak got it into his head that the way we type is wrong. Our fingers transit too far across the keyboard, he argued, and as a result our motions are inefficient and slow. Dvorak rearranged the standard QWERTY keyboard to make typing more efficient, eliminating the design constraints which had originally informed the layout we all learned to type on.

In theory, that should make for a faster typist though it does take some getting used to. For me, this marks the jumping off point and possibly a painful transition. This entire post was touch typed using the Dvorak layout and, despite quite a bit of practice on a very helpful typing tutor, I can’t remember typing this slowly since middleschool.

Rotors with Alphabet Rings

One of the projects I have been working on with VirPack has been the establishment of a developer’s training program and central to that program has been Robert Martin’s materials on Clean Code.  While many of Martin’s ideas have sparked some interesting discussions at VirPack, none has been more controversial than his discussion of Test Driven Development.  Martin holds to a three-part cycle: Fail, Pass, Re-factor – in which you write just enough of a test to fail, just enough code to pass, and sometimes re-factor to clean up before cycling back to failure.  This results in a number of areas, particularly in Martin’s examples, where tests seem to be written merely to justify an action everyone agreed was necessary in the first place — say, a test to see if you can construct an object which is then run, and fails, because the object does not yet exist.

While I am pretty well sold on Martin’s coding philosophy I decided to take my coworkers objections under advisement but with a grain of salt.  Most of the Kata and examples that Martin works through are very simple; they have to be in order to be short enough and accessible enough to communicate the points he is trying to make about software development but that simplicity also means that the early fixed-costs of TDD seem very big compared to the actual “meat” of the problem he is trying to solve.

So I set out to try out true TDD on a project which I knew was going to be complicated.  Martin’s examples of things like a bowling score calculator had just a few plausible test cases and a mere handful of interesting results which could emerge from a complete examination of all possible execution paths.  I wanted something much bigger and much more complicated and the historian in me knew just where to look. (more…)