This contract limits our liability—Read it carefully!
After two decades as an avid systems analyst, obsessed computer programmer, and reluctant programming manager, I began my own consulting firm, specializing in training, teaching and writing. When teaching, I try to give battle-tested tips, and tell eclectic stories to illustrate my points (and see if anyone’s awake). I decided to collect some of them into this book.
Occasionally, when asked about some play or movie, I’ve realized that although I had disliked it at first, it passed the think test: I had found myself thinking about it in the days that followed. And so I hope with this book. It does not always have answers, often just more questions. You might love it or you might hate it, but if you find yourself thinking about it later, I’ve been successful.
These stories don’t always give an explicit moral—usually because I don’t know what the moral is, yet. I’ve been free with my opinions, some of which I even agree with, and try to share a certain offbeat thought process. You should think from analogy, and even life generally, so many of these stories might not immediately seem to relate directly to information systems analysis.
And you’ll find lots of contradictions here. Like any good list of aphorisms, some are opposites. You’ll find impossible proverbs, parable paradoxes, fighting fables, contradictory kotowaza, and muddy maxims: Don’t bite off more than you can chew—but if you aim for the stars you might reach the moon; Look before you leap—but he who hesitates is lost; You snooze, you lose—but sleep on it.
I didn’t do extensive research, so some are apocryphal stories, which I define as stories that should be true even if they aren’t. I lived in Texas when in grade school, so I appreciate the tall tale, and my Irish heritage would never let the truth ruin a good story.
So the book is nebulous, ambiguous, and filled with off-topic and contradictory stories that might not even be true.
Come to think of it, that pretty much describes a systems analyst’s life!
My father was in the U.S. Air Force, so my family lived in many places. My first memories in life are of the Philippine Islands, and I went to Kubasaki Junior High and High Schools in Okinawa, Japan. I was fortunate to have lived off the military base in downtown Naha, and so had closer contact with the culture of the East than most of my classmates. After some years as a systems analyst, burnt-out, I moved to Tokyo for six months to re-new myself, and deepened my acquaintance with Japanese culture, history and philosophy. I was struck by the applicability of many of Eastern philosophy’s beliefs to computers.
It’s surprising how many Japanese concepts are already in English. For example, that incontestable intellectual and social arbiter, the Microsoft Word ® Spellchecker, accepts as normal English words: aikido, anime, banzai, bushido, daimyo, dojo, geisha, haiku, hara-kiri, judo, jujitsu, jujutsu, kaizen, kamikaze, kana, kanji, karaoke, karate, keiretsu, kendo, kimono, kohai, ninja, origami, pachinko, sake (saké), samurai, sashimi, sempai, sensei, seppuku, shogun, sukiyaki, sushi, tsunami, zaibatsu, and of course Zen. I am not Zen Buddhist by religion, but I do agree with many Eastern ideas and tenets, and have found them surprisingly helpful in analysis, and so I use them as a theme throughout this book.
The central tenet of Buddhism is: There is suffering in the World; which has a cause; and can end. The way to end suffering is laid out in the Noble Eight-fold Path. All analysts know there is always suffering involved in the quest for a good system. Thinking this book might reduce the suffering of the long-suffering systems analysts who read it, I chose the Eight-fold path as a more-or-less arbitrary organizational theme for the book. The book is organized into eight chapters around the eight topics in the chapter titles, loosely paralleling the Noble Eight-Fold Path. Thank you for taking this journey with me. Before we start, we’ll ponder the Three Guiding Principles that underlie Systems Analysis and this book: The Middle Way; Embrace Contradiction; and the Many Ways to the Mountaintop. These three principles affect much we will talk about throughout this book.
THREE PRINCIPLES
1. Choose the Middle Way.
2. Embrace Contradiction.
3. There are Many Ways to the Mountaintop.
The first principle is that of the Middle Way. The principle advises avoiding extremes. Although not reported to be a practicing Buddhist, Goldilocks understood the principle well. Imagine her looking at some Entity-Relationship Diagrams (ERDs): “This ERD is too sketchy”; “This ERD is too detailed”; “This ERD is ju-u-u-ust right.” Much of this book will involve finding a middle way between two extremes. For example, you must thoroughly analyze every situation while avoiding analysis paralysis. For specifications, tests, and edits—almost everything—you must copy Goldilocks and get it just right. By following the middle way, you will avoid extremes, as they are rarely the best way, and by finding the middle ground between two competing ideas, you can get the best of both.
Soto Zen Master Taisen Deshimaru (1914-1982) said, “Harmonizing opposites by going back to their source is the distinctive quality of the Zen attitude, the Middle Way: embracing contradictions, making a synthesis of them, achieving balance.” Life is a contradiction, and the cosmos is oxymoronic. Oxymoron is constructed from the Greek words meaning sharp and dull. Sounds like a contradiction, both sharp and dull at the same time. So an oxymoron is a phrase that has a seeming contradiction, but in fact often contains a profound truth. Shakespeare was right: Parting is such sweet sorrow, although sorrow is certainly not sweet. Be careful with the word, because if you call someone who doesn’t know the meaning of the word “oxymoronic” you might get punched, but to a true Zen analyst, oxymoronic is a great compliment.
As a systems analyst you must embrace contradiction. Systems analysis is contradiction. In fact, it’s a riddle inside a conundrum that’s part of a mysterious puzzle. Remember, genius is the ability to hold two completely contradictory opinions at the same time. As with The Force in the Star Wars movies, you must learn to trust your intuition, and let your gut guide you when your head can’t.
Beware the nagging question. If you feel uneasy, there’s probably a reason, and in analysis, minor contradictions can lead to major consequences later. If there is something you don’t understand there must be something wrong. So you must dig and dig until you resolve the issue. You’re in peril if your gut disagrees with your head.
Wait! Isn’t that the opposite of what I just said in the previous paragraph? So what should you do, accept a contradiction and live with it, or not proceed until you eliminate it??? The answer, of course, is “Yes”.
After years of research, computer science has finally discovered the one true best methodology—at least a hundred of them, in fact! Each guru will tell you his is the only way, but no way is always right. When asked to compare various methods of attaining enlightenment, the Buddha is said to have remarked: “There are many ways to the Mountaintop.” Some are harder, and some are easier; some are surer, some slipperier. But many ways are valid. You must find your own best way, but one of the first things to learn in the analyst business: You’ve got to be flexible. There is no one correct, or even best, methodology—or technique, or tool, or approach. The rub of course is that although there is no one right way, there are in fact many wrong ways, and the essence of analysis is avoiding them. So this book contains tips and rules of thumb to help you determine which approach to embrace and which to avoid. An idea is a very dangerous thing if you only have one.
The medical missionary Dr. James C. Hepburn invented the method of transliterating Japanese into Roman characters that I generally use in the book to render Japanese into English, except when usage has developed otherwise. Unfortunately, this method has some ambiguities and difficulties, one of which is the need to show a macron to distinguish the pronunciation of long vowels. Those unfamiliar with spoken Japanese find the macrons (ō, ū) distracting, but they are essential to correct pronunciation. As a compromise, I generally show the macrons on the first or defining occurrence of a word but less exacting on subsequent occurrences. I do this out of my great concern for the reader, and because it’s easier to leave them off and I’m lazy. In this book, the first or defining occurrence of a Japanese word will be italicized and show the macrons; thereafter it will be treated as an English word, without macrons, except following the Japanese, which does not have grammatical plurals, the plural form is the same as the singular.
[ [ [
I considered formal references but since my readers all buy their books on-line, if you need one you can look it up on Amazon.com yourself, or use the links throughout the text. There is a Bibliography provided that lists the books mentioned in the text that I think you might find helpful (Hint to Jeff Bezos: to cite a book in a scholarly work, we also need the city it was published in. Could that be on the wishlist for the next release?)
Copyright ©2003, 2008 Patrick McDermott