When talking about methods of managing the complexity of Project Integrity Management, the discussion inevitably turns to software solutions. This is a natural progression of logic for people who spend a large portion of their waking hours (and in some cases, a large portion of their sleeping hours) thinking about software. When a software developer or software project member sees a problem, their first reaction is to find a software product to solve it. The unfortunate truth of the situation though is a simple axiom that I came up with years ago to help guide the requirements gathering phase of a project:
“You can’t solve a problem with software that you can’t solve on paper.”
In other words, software can only solve a problem if that solution has already been figured out logically and codified in the logic that the software operates on. For this reason, my software requirements gathering sessions are always done with nothing more than paper, a whiteboard, and the people who know the processes in a room together. Crazy, huh? A software developer who will only use paper and whiteboards. This approach does two things. It forces the people who already have the knowledge of how to solve the problems that your software is intended to solve to break the processes in their brains down into individual steps, and more importantly, it exposes the gaps that exist in their own manual processes. Until those gaps are filled and they can explain how they do the task manually, the software solution cannot exist.
The reason I bring this up is because the software that I have seen for “Configuration Management” is woefully inadequate for the task. People who create this software clearly do not understand the complexity of the problem they are approaching. How can I make such a bold statement without actually talking with them? I look at the tools they use. As I talked about in the article titled “When all you have is a hammer…”, they are obviously attempting to solve complex problems by using whatever tools they have lying around. A prime example of this is the ubiquitous Treeview control.
If you have ever used a modern computer, you are familiar with the TreeView control. It is everywhere. Most operating systems make wide use of it, particularly for navigating their filesystem. In Windows Explorer (or “My Computer” to many), the TreeView allows users to organize and find files that are represented as icons in folders. When a folder is clicked, the treeview expands to show folders and files within the selected one.
It is a cozy, well-understood metaphor.
“You can’t solve a problem with software that you can’t solve on paper.”
Like most metaphors though, it is limiting. I will explain. Have you ever really thought about the whole “folders and files” metaphor? How well does it map to something real? That is, after all, the whole purpose of metaphors…to access knowledge you already have and apply it to a new concept. Ask yourself the following questions about the Windows “filing cabinet” metaphor of folders and files and consider whether or not the metaphor is doing more harm than good:
- Do you really keep your printers in a file folder named “Printers and Faxes” in your filing cabinet at home? Do they fit?
- Do you also keep your expensive camera in your file drawer with your scanner?
- When you want to schedule a task, do you have a folder for that in your file cabinet?
- Do you have a very large file in your file cabinet called “Administrative Tools” with various tools in it?
- Do you keep folders inside folders..inside folders…inside folders…inside folders…with one document in the innermost one? Why would you do that?
Of course, the answer to these questions is almost certainly “no”, but what does that prove? Everybody understands what it means, so why bring it up? Because the only reason “everybody” knows what it means is because the same “everybody” had to unlearn something for it to make sense. Consider this example.
If you were to sit your grandmother who had never used a computer down in front of one and start explaining to her that everything on the computer was stored in files, just like her filing cabinet, she would intuitively understand it at some level because at some point in her life, she learned how to use a standard paper filing system. As you progressed through the various folders (“My Documents”, “My Pictures”, etc. she would probably have little trouble understanding the metaphor, although she may think it odd that you keep your photos and audio “records” in a file cabinet. But when you clicked on a folder called “Printers and Faxes”, what would she expect to see there? If she is like my grandmother, she would expect to see owners manuals for her printer and her fax machine, and maybe the receipts from when she purchased them. She would certainly NOT expect to see an actual laser printer there, any more than she would expect to open a paper file and find one crammed into it.
Here is the problem with metaphors. While they save a lot of learning up front by allowing someone to transfer knowledge that they already have to a new concept, they soon start taking those gains away in the form of learning the ways that the metaphor is bent to apply to the new concept. Files on a computer are LIKE files in a filing cabinet, but they are not REALLY files in a filing cabinet. Since they are not identical, there must be differences, and those differences are where we get into trouble. The more the target of the metaphor (in this case, the computer) strays from the actual item (a filing cabinet or physical desktop), the less useful the metaphor becomes, sometimes with disastrous unintended consequences.
When I was a teenager, I had thousands of hours logged riding my bicycle. I would literally ride miles per day on asphalt, dirt roads, gravel, and even through the woods. I could ride my bike across a large log crossing a stream without falling off and could jump over progressively higher ramps until I eventually crashed and bled (that is how we knew we had reached our limit). In short, I was a good bike rider.
A friend of mine had a cousin who got a motorcycle that he was very proud of. It was a small street bike in pretty good shape. He brought it over to my friend’s house to show us, then insisted on taking my friend for a ride. I followed along behind them on my bicycle to a new highway that was being built. There were no cars on it. Heck, there wasn’t even any asphalt yet…just miles and miles of red dirt. He asked me if I wanted to “take ‘er for a spin”, which I took to mean riding on back of it like my friend had. To my shock, he jumped off and said “go ahead”.
“I’ve never driven a motorcycle” I said. “I’ll probably wreck it.” I was telling the truth.
“Oh, there’s nothing to it!” he insisted, “Its just like riding a bicycle, only you don’t have to peddle!”
I got on and he showed me the throttle (I didn’t have one of those on my bike). Just keep it in first gear and ride a little ways up”, he said, grinning, “it’s simple!”.
Against my better judgement, but at his insistence, I started out by giving it a little gas and suddenly I was putting along at a few miles per hour. Cool. I did a wide turn around and came back to him. “Go again!” he shouted, “and give it some gas this time!”. I did. It felt great. It was much better than being on a bicycle! I cruised about two hundred yards and was really getting the feel for it when I hit a patch of sand.
This happened to me all the time on my bike, and I knew just how to handle it. I applied the brakes a little to slow down and regain control. Surprisingly, this made things worse and I started to seriously swerve towards the embankment. Although I was only travelling at fifteen miles per hour or so, it suddenly seemed to be way too fast. I decided to just stop and start over, so I applied the back brake and front brake heavily at the same time and coasted to a nice smooth…arc…over the handlebars and onto the dirt road. The motorcycle flipped over beside me and sputtered out. I lay there wondering if I had broken my neck on my first motorcycle ride.
By the time my friend and his cousin came running up, I was on my feet surveying the damage. I was scraped up, but not badly. His motorcycle on the other hand was pretty messed up. The turn signals on one side were hanging by wires and the front wheel was having serious disagreements with the handlebars on which way was forward.
“You crashed my bike, you idiot!” he yelled.
Motorcycle controls
“I apologized profusely as he put the front wheel against a nearby tree and twisted the handlebars back straight, then sadly examined his broken turn signals. “My brand new bike! What happened?” he asked.
I pointed out the swerve marks in the sand leading up to the tragic spot. “I hit some sand and lost control. I don’t understand what happened. It tried to stop and it flipped. It’s like I hit a hole in the road, but there isn’t one there.” I blabbered, completely puzzled at what had happened.
“Why didn’t you just hit the brakes?” he asked.
“I did…that is the weird part. As soon as I hit the brakes, it flipped.” I explained.
“Show Me”, he said.
As this story illustrates, metaphors give, and they also take away. At some point, all metaphors break down and differences appear.
So I got on the bike and applied the brakes again, just as I had. The brake felt spongy. “I think your back brake is messed up”, I said.
“Brake?”, he yelled, “you really ARE an idiot! That isn’t the back brake…it’s the CLUTCH!”. He pointed to the lever on the left handlebar that I was squeezing. “You put on the front brake and the clutch! No wonder it flipped!”
“That’s the clutch?” I said meekly, “On my bike it is the back brake. You said that it was just like riding a bike, only without having to pedal. So I thought that was the back brake.”
“Oh. Yea”, he said, much more calmly. “I forgot to tell you. The back brake is down by your foot”.
Because he offered up a metaphor that I so completely understood, I was overly confident in my ability to control the motorcycle. When someone says that something is “just like” something else, it is always wise to press them further, because if a motorcycle was “just like” a bicycle, it would be a bicycle, not a motorcycle. Instead, it was “very similar with some extremely important differences”.
As this story illustrates, metaphors give, and they also take away. At some point, all metaphors break down and differences appear.
The Tired Desktop Metaphor
DOS Command Line
Early in the days of computers, the concept of a “desktop” was popular. This did not mean “a computer that could sit on your desk”, but rather it was a metaphor for using an otherwise extremely intimidating device. Anyone who has used Unix, Linux, or DOS can attest to the fact that, although the command line is powerful, it is extremely hard to grasp in any meaningful way. The desktop concept provided an abstraction from the true nature of the beast and mapped existing knowledge to operations in the computer. For example, instead of “text files”, you could work with “documents”, Within those documents, you could cut, copy, and paste; these were concepts familiar with nearly all office workers of the time since publishing was a manual process. If you wanted to put a picture in a paper document, you literally cut it out with scissors and pasted onto the paper.
Initially the desktop metaphor was a real hit. It let people jump right in and start using a computer without any real computer knowledge. It was such a hit, in fact, that Bill Gates created a fortune on the concept with the introduction of the “Windows” operating system, which leaned heavily on the desktop metaphor.
Windows 3.11 Desktop
With the Windows desktop, the user was presented a “desktop” with different tools on it, much as a real desk of the 1980s may have on it. It did not have a stapler (although I always thought it should…to stick files together as a group, but that came later as Windows Briefcase”), but it did have a clipboard, a clock, a calendar, and various other tools that made sense in the context of a desktop. And most importantly, it had a file cabinet called “File Manager” whose icon was a yellow file cabinet.
Over the years, as the capabilities of the computers and operating systems evolved, Microsoft struggled to keep the desktop metaphor. Odd items started showing up that most people wouldn’t really have on their desk such as a mailbox, other people’s computers (Network) and a strange piece of machinery that was apparently attached to the front left edge of the desk called a “Start Button”, which had absolutely no discernible function in the real word.
Windows 3.1 File Manager
This is not to say that these changes were not improvements, as they most certainly were. They made using a computer easier, more efficient, and in many cases, all around better. But at the same time, they stretched the desktop metaphor to the point that it is no longer recognizable a metaphor. Looking at the Windows 7 desktop, there is obviously complete abandonment of the original idea of mapping tasks on the computer to tasks in the physical world. Yet the metaphor lives on. Why? Because its what people know. But not the original metaphor. Someone who cut their virtual teeth on Windows XP would have no better idea of how to operate Windows 3.1 than someone who had never seen a computer. In fact, they would be more frustrated because they have learned the extensive metaphor “breakers” and accepted them as common knowledge.
Windows 7 Explorer
Meanwhile, we are still trying to organize our filesystems into file cabinets and folders. Even the name filesystem is left over from the metaphor. Now instead of providing us free knowledge, the metaphor is holding developers back. In conforming to the age-old desktop (and more importantly, filing cabinet) metaphor, they are actually limited in what they can do with software. The metaphor has come back to collect its dues.
This doesn’t just happen in the computer world. I was unfortunate enough to be hired by a huge consulting firm as a senior developer in their brand spanking new software development center (as in “at the center of nowhere) . The place was designed to provide work areas for 200+ developers, but at the time I was hired, there were fewer than fifty, so there was a large area of the operations floor we referred to as “the back forty” that was not being used. We would sometimes walk through it to get to a server room on the other side of it, and one day one of the young developers in my charge stopped and surveyed the huge area filled with cubicles, shelves, whiteboards, etc. but no people.
“Man, this is nice!” he said, looking around, “This place is really big! What are these big metal things?” He was referring to a row of no less than fifty large vertical filing cabinets that lined the central walkway.
“Those are filing cabinets,” I said, opening a drawer to show him.
“What are they for?” he asked.
“Filing papers”, I replied, amazed at his ignorance.
“What papers?”
“Hmm…you’re right. I don’t know.”
It dawned on me that whoever had designed the development center had somehow calculated how many filing cabinets would be needed for 200 developers. Developers who were not familiar with filing cabinets and would certainly never use them.
The Metaphor Lives On
dBx Solutions is pleased to announce the upcoming release of a full line of Guardian™ branded software products.
