Working Up

by Dwayne Phillips

How much oversight, process, testing, and any activity other than writing software should you do? The answer lies in the consequences of failure. Don’t let the quest for better destroy your software project.

• How much effort should you spend testing software?
• How much management oversight should software projects have?
• How much effort should go into all activities other than programming?

I have asked myself these questions for years. I am not alone in my puzzlement in this area.

I have had the privilege of working on software projects that ranged from tiny embedded systems to supercomputer signal processing. I have worked in structured, large-process, heavily managed projects and one-man just-code-like-hell projects.

The answer to my questions?

It depends on the consequences of failure.

I believe that Microsoft learned a long time ago that if a failure means you hit the Control-Alt-Delete keys and wait two minutes, don’t put much effort into anything but programming.

I know that if a software failure means you break concrete and dig out an embedded system to reprogram it, you spend a lot of time and effort testing, reading, re-rereading, and more testing of the code before you release it.

This seems pretty simple. Nevertheless, I see people expend large amounts of resources on software where a failure means only a reboot. There is a good enough measure of software. When the software is good enough, stop working on it. Move on to the next great thing.

The quest for better often destroys software projects.