Reflections on Spartan Programming and the No-Debugger Principle

Abstract

In this not too scientific presentation, I briefly described my spartan programming methodology, and said why I believe debuggers should never be used. In a way, these two offer indirect means of coping with intractable problem of software quality: The idea is that of instead of directing efforts directly at the impossible and vague objective of “correctness” and “quality”, one should try to make the code more elegant (spartan programming) and better in other ways (no-debugger principle).

Some may appreciate the aesthetics of spartan programming and the indirect method of dealing with defets. Unfortunately, my non-methodological encounter with industry, and my “survey” of talking to many software industry leaders, lead me to two grim conclusions that contradict my underlying assumptions.

• Both software leaders and plain programmers seem to pay lip service to code quality, and sometimes even to elegance, but they are largely uninterested in these objectives. What these people (in my mind) find important are crucial issues such as timely delivery of products, the cost of correcting defects, and at the same time, trivial matters such as gadgets, lunch selection, and abusive electronic email messages spread in the internal network of the software house.

• My second (and arguably less dismaying) conclusion is that most professionals do not find the issue of quality challenging at all: they have each found his own methods and techniques of dealing with software faults. The variety of these methods and the considerable ingenuity in their invention, prove to me that the main challenge in systematically dealing with “quality” is to come up with an appropriate way of making “quality issues” directly and immediately drive concerns that matter: time of delivery, job security, income, and, perhaps abusive correspondence.

This written record of my presentation will briefly describe spartan programming and the no-debugger principle. My sample of the industry, and the conclusions I draw from it, are probably not as good as yours.