Nick Mudge Ignition Software Consulting & Development

Marc wrote Confessions of a Terrible Programmer. Some insightful things in there about writing great software.

Here's a quote:

Over the years I’ve learned more ways to hide my programming failings. One technique: let the program crash—This works, just stay with me. I’d joined a development project where the original developers had so many problems with run-time exceptions that they simply starting including "null exception handlers", i.e., catch all unexpected exceptions, suppress them, and keep on going. Needless to say, the system would run fine for awhile, sometimes hours, and then slowly start to...hmm..."veer off".

When I got the chance to redesign the system, one thing I immediately forbade was those null exception handlers (though handlers for recognized exceptional conditions were permitted). If an exception occurred, I wanted it to propagate up until it took the application down so that we would know about it and could fix it right then and there. I got my wish, but was almost found out in the process. The program manager got wind that we were seeing a lot of system crashes during testing, and he wanted to know why the redesigned system was crashing so much more often than the one it was replacing. Explaining that we were uncovering errors and getting them fixed now, and fixed right, didn’t really give him the warm fuzzy he was looking for, as there were deadlines approaching and the reported error rate wasn’t declining as fast as he liked. The team stuck with this practice, though, and when we were done (on time and on budget) the system ran reliably and correctly for days under both light and heavy loads.

This made me laugh:

Now if you look at my code you might find it to be pretty bad, and that’s normal, pretty much any programmer that looks at almost any other programmer’s code will judge it to be a pile of offal and then proclaim that the only way to fix it is to rewrite it. (I wonder why this is?)

This was an insightful comment by masklinn on

Thing is, well-defined, strong, extensive type systems (such as Ada's, OCaml's or Haskell's) are test cases that were already built for you by the authors of the language.

Even better, there are automated test generators that can leverage the language's type system to automatically generate test cases, see Haskell's QuickCheck and SmallCheck.

I'm not arguing against dynamic typing, I love Python, Ruby and Erlang and would use any of them over Java any time of the day, but the thing is, for every type annotation you write or every type your compiler infers in a good static type system you will need to write multiple test cases in a dynamically typed language.

Soo, if you have a type system worth using (which Java's isn't), you can see it as specifications autogenerating series of tests for you.


28 September 2007


Just a small correction: Bruce Cockburn didn't write "Confessions of a Terrible Programmer", I did. Bruce is a very talented Canadian musician, but I don't think he does much programming :-)

Nick Mudge
28 September 2007

Oh thanks. Correction made.
Name: (required)
Email: (required)
What has four legs, rhymes with bat and says, "Meow?" (One word answer.)
Spam Filter: