Programming for the Long Haul


Trevor Magnusson

This document lists some of the programming philosophies I have developed and learned over the past 21 years. During this time, HYDSYS code has grown from a handful of programs running on a 4.77MHz IBM PC under DOS to the comprehensive Windows system it is today. Along the way it has run on a Fujitsu FACOM mainframe, and a Sun workstation under Unix. In the future we expect elements of the current system to be migrated into published COM objects and possibly converted to / integrated with C++ and/or Java. Further ahead still we cannot see.

Long Haul programming has two aims:

What it's not...

When it's needed

Long haul has some costs and may not always be required. However, the more of the following criteria apply to the project, the greater the need for a long haul philosophy:

Long haul programming and SDLC

Long haul programmers sometimes find themselves at odds with managers familiar with SDLC methodologies. Projects of the sort that require long haul programming do not fall within traditional SDLC pigeon-holes:

Remote control


Funnelling is a technique for minimising the workload when changes need to be made.

Comments in code

Once of the most common criticisms of programmers is that they do not write enough comments in code. A "clever" programmer might respond "But this code is simple - anyone can understand it just by looking at the code." An even more clever programmer will realise that this "obviousness" depends on context - it's obvious because you've just been working in that area for a few days.

Interface / Implementation disparity

Some programming languages (C/C++ and Delphi) let you specify the full function declaration in the interface, then down in the implementation you can leave off all the functions' parameters.
DON'T do this. Keep the two declarations as identical as possible.


Along with comments, good code layout makes debugging, enhancement and redevelopment easier.

Reliance on third-party tools - "kid in a candy store"

The more your code is tied in with third-party tools or non-standard language features of the compiler, the harder it will be if you ever need to switch tools or compiler / language.
There is obviously a balance to be struck here.

Reinventing the wheel

It is inefficient to have lots of programs with the same algorithm, coded slightly differently by different programmers. Don't spend lots of time developing something if it has already been done. Teamwork and communication help here.


The night of the long knives

Kill Kill Kill! (obsolete code).

Yes, I'm repeating myself.
Deleting lines of code is even more rewarding that writing some fantastically cool program or module.

Assert your assumptions - "trust no one"

If you assume that certain conditions will be in place when writing code, put in some Assert calls so that if those conditions do not hold, a helpful error message will be displayed. Better yet, minimise the assumptions you make.

Muzik-Smith's law

Tony Muzik-Smith, one of the programming stars of HYDSYS in the 90’s, was once asked by a first-year computer science student what single piece of practical advice he would give to beginner.

Magnusson's addendum to Muzik-Smith's law


Long Haul programming minimises the impacts of unforeseen changes.
Long Haul programming can be distilled into two pieces of advice:

Copyright 2005 Trevor Magnusson