The Magic Carpet of Crap

A couple of days ago, I read a blog post entitled “Code == Crap” or something to that effect. I didn’t agree with most of the post but the phrase “code is crap” really struck a chord with me.

Jerry Weinberg wrote in his book The Secrets of Consulting:
“No matter how it looks at first, it’s always a people problem.”
I agree with Jerry. All the problems that we try to solve are basically people problems at the root, and software will never dissolve* these problems (how I wish that everyone would take a couple of minutes to consider this).

Software will at best provide a resolution to the problem while at the same time giving us a new stack of problems to handle. This is why I think that code == crap and why I think that we should do as little of it as possible.

If you consider your most recent software project, how many of the 5 Whys do you have to ask before realizing it is a people problem that you’re trying to solve with software? I’ve tried it with a bunch of projects and problems now and never had to ask “Why” more than three times before a people problem has surfaced. Now, in many cases software is one of the least painful ways to work around a given problem but it has never so far, in my experience, dissolved any problems. Software has provided us with a patch or a workaround but the root cause of the problem still exists. And to make matters worse, we now have a bunch of new problems, related to the software we created, that we must tend to as well.

I’m a developer at heart and I love to see a beautiful piece of code, but only a fraction of the effort put into our software projects is related to actually solving our customers problem. We spend a majority of our time handling new problems that are related to our recently found “solution”. Documentation, quality assurance, project management, all maintainability issues etc are activities to make sure that our solution will cause as few new problems as possible; now and in the future.
All this work and the original problem is still out there!

The minute our code stops working, our customer is not only left with the original problem, but he now also has a truckload of files, tools and documents that we sold to him.

There’s no question that software often is a good thing. Software has improved our lives in so many ways. But the old problems that we tried to solve still lurk out there. We’ve used code to hide root causes and to sweep many a stinking problem under the carpet. So the next time you feel the urge to write some code, please take a minute to ask yourself just a couple of the old 5 Whys in order to see where the actual problem lies and to consider if software really is the best way to handle it.

The magic carpet of crap, sorry I mean code, can only hold so many problems before it gives us the ride of our life.

* In The Art of Problem Solving, Russell Ackoff makes a distinction between solving, resolving and dissolving problems:
“To solve a conflict is to accept the situation and find the best one can do within it. To resolve a conflict is to accept the situation and find a distribution of gains and/or losses among opponents for which they are willing to settle. … To dissolve a conflict is to change the situation in such a way as to remove the conflict.”

I like to use these distinctions when talking about different levels of problem solving because they often help us see beyond the obvious.