Comment On What Could Possibly Be Worse Than Failure?

Earlier this week, I changed the name of the site to Worse Than Failure. A lot of readers weren’t too happy with the new name and many of you wondered why, of all names, did I choose Worse Than Failure. After all, what could possibly be worse than failure? In lieu of telling a specific story of failure today, I’d like to share my insights as to why there are – and will continue to be – so many spectacular WTFs (as in, for old time’s sake, What-The-F*s) in our industry, and why so many of them are, in fact, worse than failure.

In the almost-three years that I’ve been writing this blog, I have seen some of the most obscene perversions in information technology ever created. Heck, we all have. While quite a number of these disasters can be blamed on amateurish incompetence, so many defy all explanation. It’s as if highly-capable, incredibly-intelligent, and good-natured software engineers got together and said, "Let’s build the worst software ever created!"

Take a look back at The Customer-Friendly System. Or The Tool. Or any one of the countless similar monstrosities presented here. These are systems that our dear Paula Bean couldn’t program to save her life; no, they require a thorough knowledge of the technology with matching experience to create. So why would a person with such expertise design such a horrid system? Simply put, because they didn’t stop at failure.

What The Failure?

Failure, as they say, is the greatest teacher. This holds true in everything from chess ("one doesn’t get better by winning") to entrepreneurship ("failure is a part of success"). It goes without saying that, before one can learn from his failure, he must first recognize that he failed. And in most cases – Checkmate! Bankruptcy! – it’s pretty obvious. But information technology? Not so much.

According to the Standish Group’s CHAOS Report on Project Success Rates, "84% of projects fail or are significantly challenged." This directly contradicts common sense, which dictates that most projects are successful to some degree and run into a few bumps along the road.

For better or for worse – actually, for worse – once the code makes it to production and the initial bugs are worked out, it’s time to celebrate! Everyone’s hard work paid off and, despite a few delays and weekend crunches, the project finally went live. And before there’s even time for a post-mortem review, it’s time for the next project. Memories of the bitter arguments over poor design and hacks fade with time, and the project goes down in most people’s mind as a success. That’s right; to those that initially developed it, The Customer-Friendly System was a success.

That last point bears repeating. The consultants behind The Customer-Friendly System – a system that programmatically utilizes Visio documents to map its workflow – actually considered it to be successful. This means that they will take the techniques they learned from this project, and apply them over and over again. After all, it was through lessons from their previous "successes" that the system was even conceived in the first place.

Suc-cess (sek-ses’): Anything

Think back to all of the projects that you’ve played a key role on and that have made it into a production environment. Now how many of those projects would you consider a success? I’ll bet that for most people, the answer is all of them. For this developer it sure was; I used to consider all of the information systems that I worked on to be a success. No, they weren’t perfect – heck some were barely usable – but they worked. They mostly did what they were supposed to and they were accepted by the client. Surely, they weren’t a failure, right?

We are practically the only industry where completion and success are synonymous. If the foundation of a one-year-old home is crumbling and its roof is plagued with leaks, would anybody actually call that a success? Despite being filmed and produced on budget, is there anyone who would not be ashamed to have Gigli on their filmography? Of course not! So why are the products we create – complex information systems that should last at least fifteen years – be held to a different standard?

Now think back those projects of yours. How many would you say are maintainable by someone with less business knowledge and a weaker grasp of the system’s design? How many will not snowball into an unmaintainable mess? How many do you truly believe could last fifteen years? I’ll bet that number is quite a bit lower than all of them.

A Recipe for Failure

So where does this leave us? Do we actually have to wait until a system’s end-of-life before we can call our development work a success? Of course we do! We can, however, deem it a failure much sooner than that. But only if we’re willing to recognize that we failed.

It took me many, many years before I was willing to admit that the first few systems I single-handedly built were failures. Each of these applications was progressively worse than the previous and it was nothing short of miraculous that the third such system actually worked in production. Of course, I didn’t realize it at the time, but the techniques I had been using were so backwards and so wrong that they’d make for an excellent feature article on this site. I’ll share them some day, I promise.

At the time, I believed that the declining quality and ever increasing development difficulties arose out of the fact that each system was that much more complicated than the previous. But they weren’t. With each system I developed, I was becoming a much worse programmer.

I don’t remember how I broke out of this cycle or when I actually had that startling realization that I sucked, but it was probably around the time that I got my first look inside of an epic, multi-million dollar disaster of an application and asked myself, What The F*?

A Path Towards Worse-Than Failure

The path that I was headed down was the same path that the developers of this huge monstrosity had taken before me. They considered every project that they had ever completed to be a success. They weren’t arrogant (at first) – it simply was how they, and everyone else, defined success: making it to production.

Instead of realizing that the first applications they wrote were poorly designed, poorly programmed, and soon-to-be failure – like everyone’s first are – they chalked them off as a success and moved on to the next project. They developed more software. Bigger software. More expensive software. Wrong software. All because they kept thinking that the completion of the project meant that it was a success.

Had they simply admitted to earlier failure – and learned from it – they would have never created such an epic disaster. By imagining that their past projects were a success, they had done far worse than failure.

The Darkness at the End of the Tunnel

I wish that I could end this article on a positive note. Well, I suppose that I could say that I make sure that all the applications I develop and oversee are developed right and will last at least fifteen years (though, the thought of that still does scare me). But that isn’t going to change things one bit.

Our industry is moving at a much faster pace than ever before. System life-spans are getting shorter and shorter, and with the constant pushing of "new" technologies by vendors, many software developers simply don’t get why it’s so wrong to need a "complete rewrite" after only a few years. Heck, most won’t even stick around to see their code live past three years.

In closing, I hope that this helps explain not only what could possibly be worse than failure, but gives you an idea of why I like the new name so much. It’s my sincere hope that, regardless of its name, this blog will continue to educate and entertain through stories of "curious perversions in information technology." And hopefully, it might even help some get off that path of worse than failure.

(*) Speaking of absurdly complex and contrived systems, don’t hesitate to submit the one you’re working with. I haven’t had the opportunity to present such a system in a long time.