The Codist

If you believe the various statistics, 70 or 80 percent of all software projects fail or are cancelled (for example, a little old but still relevant). Reading this kind of thing always makes me wonder what the definition of failure, and thus success, is?

One definition could be, any project which is not cancelled, and is in active use by someone, must therefore be a success. It's not very satisfying; it's like defining life as the absence of death. If I am technically alive, but my brain function is zero, it's not a very useful existence. I have seen many projects which were developed, put into production, used by a large number of people and actively updated, yet strategically speaking are destroying the company's future. If the software is buggy and unstable, is difficult to update based on the needs of the business, hurts customer retention and new business by its inability to function properly, and wastes large amounts of employee work time, then saying it's a success has a hollow feeling.

Yet in most companies today, there live many software systems which exhibit exactly this lame definition of success. Almost everyone I know who uses a computer system as part of their daily work (and are not developers themselves) tell me stories of software that just doesn't work. Workarounds, frustration, inability to get work done, poor interfaces and frequent downtime are common complaints, despite the often mission-critical nature of many of these systems. Every such application had managers, developers, architects, testers and above all decision makers involved in the process, yet the result was still crap. I bet too that many of these systems were at some point considered a "success" as they were rolled out to customers. But are they a success, simply because they are in use?

No, and they shouldn't be. In many places, however, it may be the only type of success you can get; the organization may simply be incapable of doing any better. What an ugly truth! You (of course not me we all say) write crap because you can't do any better.

Many projects are cancelled long before they reach real users. Yet are these to be considered failures? In most cases canceling a disaster before it happens is actually a good thing if it leads to a better system. Sometimes projects are cancelled or never even started due to poor decision making, fear, expense, or other reasons not related to the actual development. This of course muddies the definition of failure and success. Is canceling a bad project a success or finishing a pile of crap a failure? It makes your brain hurt.

A better definition might be, any project which is not cancelled, is actively in use, continually meets the needs and strategic goals of the organization with frequent updates, maintains a high degree of availability and stability, and no one complains about it, must be a success.

Sadly it's tough to find applications like this in most companies, so success might be an elusive quest. When you really look at what software is supposed to do, this definition makes sense. I need software to function to do my job, my company needs me to do my job, and the company's customers needs my company's services or products. If these goals are being met (and are able to change with the market) then there is a measure of success. Of course a lot of software is not strategically necessary for a company's business but ultimately if the business is affected even subtly then success still matters.

Writing successful software is hard work, but sometimes working on live failures may be even more difficult. One of the most difficult decisions to make is when to toss out the old and start over. Do you stick with the crap you know, or risk developing new crap you don't know as well? My philosophy has always been "when in doubt, throw it out" but that isn't so easy in larger systems, where the risk of a rewrite may be more expensive than dealing with the existing failure.

As an example, in 1993 we were finishing up our 5th major update to Deltagraph. We approached the publisher about starting on a rewrite in C++, as the original source was then 5 years old and written in C (with some object extensions that embarrass me now). With the company (at the time, Deltapoint) looking towards other products the decision was made to stick with the code, and we parted company at that point. Now 13 years later the current owner is still saddled with the same codebase, which makes updating (especially the Windows version) a living hell. By now the code has seen 100 engineers and 18 years of development, so I can only imagine how awful it is to work with. But in this case it is still a success, as it has provided customers with a superior product, and the companies that owned it (Deltapoint, SPSS and Red Rock) with a lot of revenue over the years. Would it be as successful if we had rewritten it (or for that matter anyone since then) in a more modern language?

So even my example is a muddy definition of success, the code sucks, its old, everyone hates to work on it (I suppose) but it still meets the needs of the company and the customers.

It looks like even defining success is a failure. The nature of our work as programmers is surely an odd way to make a living.