---

Welcome to Duncan White's Practical Software Development (PSD) Pages. I'm Duncan White, an experienced and professional programmer, and have been programming for well over 20 years, mainly in C and Perl, although I know many other languages. In that time, despite my best intentions:-), I just can't help learning a thing or two about the practical matters of designing, programming, testing, debugging, running projects etc. Back in 2007, I thought I'd start writing an occasional series of articles, book reviews, more general thoughts etc, all focussing on software development without all the guff.

---

Aside: Tussock Hopping - Incremental Development

• I use an incremental development technique called tussock hopping which refers to making a series of small atomic changes, each of which essentially make a single change and it's immediate dependencies (eg. add a parameter to a function - and all it's calls). Each change hopefully takes your code from working -> broken -> working, and after each change you should retest your code to establish that it's ok, and then commit the new version into your version control system (eg. git or svn).
• I call it tussock-hopping by analogy with crossing a dangerous marsh by jumping from tussock to tussock and trying not to fall into the boggy bits.
• Note that I tussock hop at a micro-level too: while entering a new "block" structure (function/if/while/repeat/for) within a single function, I have trained myself to first type the whole structure:

      if( x > y * 10 )
      {
      	# then part: add me
      } else
      {
      	# else part: add me
      }
  

  before going back and filling in the then and else parts - entering the desired code in place of the comments, at the same indentation level as the comments. Why do this? Each time I save my code, it's more likely to be structurally (and hence syntactically) correct, indentation flows naturally, confusion is reduced and it forces (within a single function) clarity of thought in a top down fashion.
• Of course, many editors/IDEs can assist you in ways like this, but I recommend working this way whether or not your editor provides you any encouragement. Personally, I'm a long time vi user to expert level (yippee! editor wars time:-). To be serious, whatever editor you use, you should follow the Pragmatic Programmer's sage advice:

  Tip 22: learn how to use a single editor well - the editor should be an extension of your own hand, configurable, extensible and programmable.

  (You can read my review of the Pragmatic Programmer here).
• You might think such editor extensions have to be large and complex beasts. and be put off building them yourself. In fact, they're really simple - literally half an hour's work! Check out this article in which I develop a simple tool which generates Perl subroutine ("function") stubs from a simpler format.

---

d.white@imperial.ac.uk

Back to my Practical Software Development Top Page.

Written: Jan 2013

---