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.

Dancing for dollars

You’ve got to listen to this! Today I travelled in both space and time to planet UN-BE-LIE-VA-BLE and back. Actually, I only took the commuter train to the north side of Stockholm, but it sure felt like I passed through several dimensions of stupidity.

I was invited to a meeting for salespeople and managers, to what supposedly was an opportunity to learn from experts in the business.

The first presenter of the day was a seasoned manager/president/marketing director (you name it) who was now working as the president of a management consulting company. The theme of the presentation was “increased profitability and performance related pay”.

The topic alone was almost enough to make me miss out on this opportunity but I figure that sometimes it’s good to hear what “they” say, just in order to keep an open mind. I don’t feel so open minded anymore, however.

There was a lot of discussion about how to design effective systems of performance related pay. Most people seemed to agree that PRP was essentially a good thing, BUT I couldn’t hear one single success story where people actually enjoyed working for any of these companies. Everyone had a bunch of issues with their systems that they wanted to be fixed before they were entirely satisfied. One common problem was that the systems changed too often(!?!).

One guy at my table, who was very pro-PRP, told us how their system kept their sales people alert:

– I’m also payed the same way and my salary is very much depending on the sales performance of my staff so you can see how I keep the whip on them at all times.

When I asked if he would pass down a top sales person who was not driven by money the same way he was, the answer was a distinct “YES”. Such a person would not fit into his salary system.

Our speaker then proceeded to tell us how it is a good idea to update a performance related system every couple of years or so:

– You see, after a couple of years people will learn how to beat the system and will start to take advantage of any weaknesses in it.

I simply had to ask if he wasn’t able to see a bigger problem in this picture. If you design a system that people feel compelled to beat, don’t you think that the problem might lie somewhere else than in trying to foolproof the system? At this time the guy at my table spoke up again:

– Well, that happens every now and again. But we have a general clause in our contract stating that the company can intervene and withhold the payment if we suspect that someone is using any unforeseen side effects of our system.

I completely lost my breath at this point and failed to say anything else. However, I think that I got an explanation for this behaviour when we were told to be careful to take any soft values into consideration when trying to keep employees happy:

– You see, it’s very hard to handle these soft values, everyone feels differently. It’s much easier to just pay people according to the sales that they bring into the company.

Scotty, please beam me home to 2010 now. This place scares me.