AA6YQ

The suite of amateur radio applications I began developing in 1990 are still under active development, with an estimated tens of thousands of users around the world. I typically make several new public releases per month.

The current number of reported but uncorrected defects across this suite? Zero.

I once gave a presentation to a group of Senior Department of Defense managers on the role that management must play in the transition to modern software engineering. After I introduced risk-driven iterative development and it's ability to reduce waste and improve predictability by identifying and resolving big risks before making large investments, one of them suddenly rose and exclaimed

"If I had a nickel for every time we flushed $50M down the toilet, I'd be a rich man!"

There is enormous waste in the Department of Defense. Eliminating it would provide all of the funding needed - and then some.

In my experience, a continuous stream of frequent iterations is very effective, but the driver for the early iterations must be "eliminate risk", not "deliver value". Sources of risk include novel functionality, the architecture's ability to support the functional and non-functional requirements, dependencies on external teams/tools/services, and politics.

Focusing on value delivery before the big risks are eliminated often results in facing a nasty decision: rip up a lot of already-laid track, or live with a sub-optimal organization and/or project structure.

I develop and support DXLab, a suite of interoperating, free (but not open-source) applications for the worldwide amateur radio community; these applications continuously populate databases with realtime information, and interact with many other applications and physical devices (radios, antenna rotators) via serial ports, DDE, UDP, and TCP links. Since the first public release 22 years ago, my policy has been "all reported defects are corrected within 24 hours". Interaction with the user community is direct - via an online group. I typically make public releases bearing new functionality 2-3 times per month.

This policy's results have been excellent: users are focused on learning to better exploit the applications and suggesting new functionality rather than complaining about long-deferred defect repairs; even minor, easily worked-around defects create a negative user community mindset that can snowball. The absence of defects increases user confidence, and reduces user-perceived complexity.

Missing machines from DEC, Data General, Interdata, Burroughs, Univac, Amdahl, Magnusson, Four Phase, Tandem, Symbolics, Rational, MassPar, Convex, Sun, Apollo, Control Data, Cray, Prime, Scientific Data Systems, Xerox, Wang, Computer Automation, General Automation, Microdata, etc.

Not even close...