The Occasional Reminder
Once in a while, something comes up in conversation that reminds me why I choose practices like TDD and Refactoring.
I was recently discussing the reasons why organizations and individuals choose to or not to adopt TDD with a developer who works for a non-agile company. One thing that he said resonated with me quite a bit. I've heard this before, but it was nice to hear it again, and from a guy who is not working in an agile environment. He said something to the effect of "we're all always testing our code, it's just that some of us do it manually rather than automating it".
The second program I ever wrote (we all know what the first was) was a primitive musical scale generator that worked something like this:
>Welcome! Enter a root:
D
>What type of scale would you like?
Harmonic Minor
>D E F G A Bb C# D
Thinking back to how I went about this, the process worked something like this:
* Write some code to print "Welcome! Enter a root:" on the command line
* Make sure it works by executing the code
* Write some code to read in a response and echo it to the console
* Make sure it works by executing the code and verifying that what I type in is echoed
* Now that I know that the right stuff is read, add a prompt "What type of scale would you like?"
* Write some code to read in a response and echo it to the console
* Make sure it works by executing the code and verifying that what I type in is echoed
* Write some code to print out the notes in a C major scale (something like 'print "C D E F G A B C"')
* Make sure it works by executing the code:
>Welcome! Enter a root:
C
>What type of scale would you like?
Major
>C D E F G A B C
Next step was an F scale (that fact should clue you musicians out there as to what sort of music I play ;) ):
* Write some code to print out the notes in an F major scale
* Add a conditional that decides whether to write the notes in the C scale or the F scale based on the input.
* Make sure it works by executing the code:
>Welcome! Enter a root:
C
>What type of scale would you like?
Major
>C D E F G A B C
>Welcome! Enter a root:
F
>What type of scale would you like?
Major
>F G A Bb C D E F
At this point, I set out to have it calculate the correct notes - change some code, run it to make sure it still worked, change some code, run it to make sure it still works, etc. I didn't realize it at the time - in fact I didn't realize it until this morning - but I was refactoring!
No wonder I love this stuff so much!
!commentForm
Great example! But weren't you changing behavior? "Add a conditional" doesn't sound like refactoring, exactly (but point taken).
There are lots of examples of the same sort of thing. Some time ago the well-respected Joel Spolsky wrote a piece extolling the benefits of BDUF, but his example actually illustrated JEDI and responding to change. (I can't tell whether HTML is supported here, so I'll just put a URL in as text): http://www.davenicolette.net/agile/index.blog?entry_id=1305965
When I first got involved with agile development, I had 25 years experience in traditional IT. The principles and practices of agile reminded me of the way we used to work long ago. http://www.davenicolette.net/agile/index.blog?entry_id=1142611
We used to build software the agile way (generally), but didn't use the buzzword. Somewhere along the way we got buried in bureaucracy. In a sense, we're process addicts in recovery. It feels good to be clean!
Regarding what sort of music you play, the clues are sparse. We can eliminate Indian ragas, traditional Chinese music, ancient Greek music, etc. If you're talking about any form of music based on blues harmony, and you were working with an agile mindset, then your first priority would be I and your second priority would be IV. That fits your clue, but what's the third feature on the backlog? If it's G, then we're on track for some blues-based style, but we're also on track for Tchaikowsky. If it's Bb, then it begins to look (sound?) like Hindemith. Not enough clues yet. Need to talk to the Product Owner for clarification.
There are lots of examples of the same sort of thing. Some time ago the well-respected Joel Spolsky wrote a piece extolling the benefits of BDUF, but his example actually illustrated JEDI and responding to change. (I can't tell whether HTML is supported here, so I'll just put a URL in as text): http://www.davenicolette.net/agile/index.blog?entry_id=1305965
When I first got involved with agile development, I had 25 years experience in traditional IT. The principles and practices of agile reminded me of the way we used to work long ago. http://www.davenicolette.net/agile/index.blog?entry_id=1142611
We used to build software the agile way (generally), but didn't use the buzzword. Somewhere along the way we got buried in bureaucracy. In a sense, we're process addicts in recovery. It feels good to be clean!
Regarding what sort of music you play, the clues are sparse. We can eliminate Indian ragas, traditional Chinese music, ancient Greek music, etc. If you're talking about any form of music based on blues harmony, and you were working with an agile mindset, then your first priority would be I and your second priority would be IV. That fits your clue, but what's the third feature on the backlog? If it's G, then we're on track for some blues-based style, but we're also on track for Tchaikowsky. If it's Bb, then it begins to look (sound?) like Hindemith. Not enough clues yet. Need to talk to the Product Owner for clarification.
The next scale would be Bb. Interesting that you would think that would point to Hindemith. He was known for incorporating the harmony (and to some extent, phrasing) of the music that got me playing music. But I'd bet that he learned C, then G, then D in his youth. I was just working in the opposite direction.
re: changing behaviour: Yes, adding the conditional was there to get the F scale to print. That was adding observable behaviour. Once the behaviour (ask for C and you get C, ask for F and you get F) was working as expected, changing the internals from a map (of sorts) to a calculation was refactoring.
PS - there are other music clues in my earlier blogs on this site.
re: changing behaviour: Yes, adding the conditional was there to get the F scale to print. That was adding observable behaviour. Once the behaviour (ask for C and you get C, ask for F and you get F) was working as expected, changing the internals from a map (of sorts) to a calculation was refactoring.
PS - there are other music clues in my earlier blogs on this site.
I would say jazz.
If I remember correctly in an earlier blog you compared TDD to improvisation.
Also in this example the roots move in perfect 4ths (c -> f -> Bb etc... ) which is a very common root motion in jazz standards ( for example in the ii-V-I progression ).
If I remember correctly in an earlier blog you compared TDD to improvisation.
Also in this example the roots move in perfect 4ths (c -> f -> Bb etc... ) which is a very common root motion in jazz standards ( for example in the ii-V-I progression ).
Clearly, I didn't take to TDD and refactoring as easy as you. I remember my first couple programs were written by typing everything out, compiling it, watching the errors fly, spending several hours trying to fix those errors, running it, watching the errors fly, spending several more hours trying to fix those errors, etc. It was only after those failures that I started to use some incramental methods. Often times though, I felt bad about using them; like somehow I /had/ to use these simple methods because I wasn't good enough to get the program right the first time. I wonder if that's one reason why some are skeptical about TDD. If you were perfect, there'd be no need.
I agree!
Jazz, I would think. All the Things You Are, etc., etc.
Add Child Page to TheOccasionalReminder