THE ADVENTURES OF RICKY & STICK Fables in Software Acquisition by David Carney and David Biber

Fables in Software Acquisition 1 This work was prepared for the United States Air Force. The Software Engineering Institute is a federally funded research and development center sponsored by the U.S. Department of Defense.

Copyright 2006 Carnegie Mellon University.

NO WARRANTY

THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

Use of any trademarks in this report is not intended in any way to infringe on the rights of the trademark holder. Internal use. Permission to reproduce this document and to prepare derivative works from this document for internal use is granted, provided the copyright and “No Warranty” statements are included with all reproductions and derivative works. External use. Requests for permission to reproduce this document or prepare derivative works of this document for external and commercial use should be addressed to the SEI Licensing Agent. This work was created in the performance of Federal Government Contract Number F19628-00-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at 252.227-7013. For information about purchasing paper copies of SEI reports, please visit the publications portion of our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

2 The Adventures of RICKY & STICK To the members of the acquisition community: On a short plane ride recently, I had the enjoyable experience of reading this little “comic book.” It’s a brief excursion into the complexities of software acquisition processes, using the metaphor of two well-meaning kids who, despite the best of intentions, always end up in trouble. This book isn’t an offi cial guide to best practice, and it certainly isn’t a textbook. But in a kind of off-beat way, it’s an entertaining yet insightful look at some of the things that can really happen in software acquisition; each fable is based on true examples where our acquisition system has broken down. I’d be surprised if, for most everyone in the acquisition business, there isn’t something in this book that will ring a bell. For a pleasant respite from the standard offi cial documents we all read daily, I recommend it highly.

JANET C. WOLFENBARGER, Brig. Gen., USAF Director, Acquisition Center of Excellence SAF/ACE, (703) 253-1333

Fables in Software Acquisition 1 Foreward It is always dangerous to try to repeat good I decided that these little stories should be fortune. However, I was recently asked to of- “fables,” each of which includes a “moral” by David Carney fer a few suggestions that address some high- relevant to software, to acquisition, or to level topics related to software acquisition. government programs. Possibly the most Several years ago, I had the good fortune to The request was for “something short and important point (and yet another similarity to take a brief vacation from my normal chores to the point,” that would prepare beginning the Red Book) is that these fables are based of writing technical papers about software. I program managers for the delights that await on real-world experiences: all of the situations left the realm of data, executive summaries, when they fi nd themselves stuck between in this book are inspired by programs that are issues, and fi ndings, and spent several enjoy- demanding users, angry PEOs, and frustrated known to me. Those programs encountered— able days writing a short, rather tongue-in- software engineers. and often foundered on—issues familiar to cheek essay about the dangers and challenges any observer of DoD acquisition: require- of using commercial, off-the-shelf (COTS) Perhaps against my better judgment, I chose ments, testing, integration, maintenance, com- software in government systems. The essay to use an approach similar to the Red Book mercial products, laws, mandates, funding, was written as a pastiche of Mao-Tse Tung’s in writing this little book. While I have tried schedules, and, of course, bureaucracy. From famous “Little Red Book” and my hope for to keep the present volume from looking too observations of these programs, I selected the essay was simply that it would amuse a much like a new version of the Red Book, some of the most representative as candidates few people. I was thoroughly unprepared for there are some obvious similarities. It has (I for my anecdotal descriptive method. Aside how deeply it resonated in the DoD commu- hope) a certain humorous quality. Like the from their topics, a common thread among nity. The Red Book has been reprinted numer- Red Book, it is premised on the idea that a these fables is that, for the Program Manager ous times, and I am still gratifi ed to receive brief, metaphoric approach can often convey working in the complex and chaotic reality of email from people for whom its “quotations,” more than verbose papers that are technically government acquisition, the need is to keep in the form of spurious Chinese aphorisms, worthy, but aesthetically dull. And it is also sight of a few simple, fundamental realities. are considerably more meaningful than any of patterned after well-known models, the most These realities are all too easy to dismiss as my dry technical reports about the challenges familiar of which was a comic strip fi xture mere common sense, which they are. But in of using commercial software. during the 1980s and 90s. the frantic weeks before Milestone B, when

2 The Adventures of RICKY & STICK the world seems to be coming apart at the sible to keep a discussion of any of these top- to Ricky and Stick. He took my rather bland seams, it is amazing how easy it is to let such ics from wandering into some of the others. prose descriptions and made them so real common sense fl y out the window. At that I beg the reader’s indulgence in this matter, that, by now, these likable rascals have truly point, a besieged Program Manager, no matter since I wanted, in the spirit of fables going as become alive in my mind, and their exploits the level of experience, can sometimes make far back as Aesop, to use each fable merely seem more like memories than fi ction. His decisions that appear reasonable in the pres- as an entry point for discussion and refl ec- contribution to this work is inestimable. sure cooker of the SPO, but in retrospect seem tion. Thus, many of these fables will have harebrained. It is precisely at that point that multiple interpretations. This is not, I think, Finally, I have tried to keep this work short. the Program Manager needs a lifeline to basic a fatal fl aw: if the adventures of my hapless This was partly a pragmatic concern. A reader principles and calm rationality. heroes provide a number of useful metaphors of the Red Book once complimented me that for the woes faced by Program Managers, so I had written it “so that it could be read on the There are many topics that his book could much the better. In the same vein, there is a fl ight from Washington up to Boston.” Since address: common sense is in need on many certain redundancy in many of these tales that that reader has recently been transferred back fronts. From the large number of possibilities, is not accidental. Familiar problems, even if to the Pentagon, I hope that this little book I chose the following: seen many times before, can appear novel and will at least keep his attention on the return Testing and Modeling strange when they pop up in unfamiliar con- fl ight from Logan down to Reagan. texts, and so telling the same story in different Estimation and Metrics ways may have some value. Software Engineering Institute Requirements Carnegie Mellon University Integration and Interoperability I began these ramblings talking about good October, 2005 fortune, and I have gone on too long. But it Deployment must be said that an additional pleasure for Business processes me was the enormous good fortune to collab- These are nothing more than starting points, orate with David Biber, whose brilliance and of course, since they all blur, and it is impos- invention gave life, personality, and character

Fables in Software Acquisition 3 THE Ricky and Stick ADVENTURES were best friends. OF They lived on the same street, and played together a lot. Ricky was RICK a month older Y than Stick, and he always told Stick that this made him & a lot smarter. Their parents could not quite understand S K why Ricky and Stick got into trouble so often. TIC It seemed that they always Fables in Software Acquisition started out with great by ideas, but David Carney and David Biber somehow, with Book Design and Production one thing led by Bob Fantazier to another, and they ended up behind the eight-ball most of the time.

4 The Adventures of RICKY & STICK Other children lived in the same neighbor- Ricky and Stick had another hood as Ricky and Stick. There was one boy friend, a boy named Bob. Bob that they called Mean was usually nice to Ricky and Wally. Wally was really Stick, and he often tried to help a pretty nice kid. But them on their projects. But they he was always criticiz- seldom took his advice. Bob Table of Contents Page ing them, which they was older than Ricky and Stick, thought was a mean and his hair was white all over. Testing and Modeling 7 thing to do. They called him Coconut Bob because of his white hair. Estimates and Metrics 15 Requirements 23

Gloria lived in the next block and was in Integration and Interoperability 31 the same class as Ricky and Stick. Ricky was annoyed Deployment 39 that she was such a better student that he was, since Business Processes 47 their teacher, Mrs. Perillo, was always praising Gloria.

Fables in Software Acquisition 5 6 The Adventures of RICKY & STICK NO NEED TO TRY IT OUT— IT’LL WORK JUST FINE

Testing and Modeling

Fables in Software Acquisition 7 LOOK STICK, I’LL JUST I WONDER WE BETTER STRAIGHTEN IF THE HURRY! THEM OUT! BRAKES SURE WE DO! WORK...? MY DAD’S THERE!! OLD RACER. WILL BE FINE. BUT THE WHEELS ARE ALL BENT, RICKY.

BUT RICKY -- WE DON’T HAVE A SOAPBOX RACER.

NO TIME, STICK. WE HAVE TO GET GOING. BOY, ARE YOU TWO DUMB. ANYWAY, THEY WHAT ABOUT WALLY, WHY DIDN’T YOU TEST LOOK FINE TO THE BRAKES? LOOK OUT! THE BRAKES? ME. SHOULDN’T WE WE CAN’T TRY THEM OUT? STOP!!!

DON’T BE A PAIN, WALLY -- WE DIDN’T HAVE TIME!

8 The Adventures of RICKY & STICK The stories about the pain and failure caused legends. You may really think that there’s least some. And it must be real testing by inadequate testing are probably the best a compelling reason for skipping a crucial of the parts that really need to be tested. known tales in the software community; some testing cycle. (Maybe, if you don’t hurry up, of them have taken on a near-legendary status. you’ll miss the race…). But chances are that Bottom line: No matter what schedule pressure Nor are they all legends, since testing really by taking that route, by doing the real-world you may be under, the outcome of a battle may is a messy isssue. It’s costly, it’s time- equivalent of operating a downhill racer someday depend on the system you’re build- consuming, and (so the theorists insist) nearly without testing the brakes, the eventual crash ing. So if testing is getting squeezed, you may impossible to do perfectly. Even worse, is almost guaranteed. In retrospect, so were want to ask the contractor: “What are we risk- testing tends, whether rightly or wrongly, to most of the DoD testing failures that have ing by skipping this set of tests?” When lives come late in the day, and for managers already occurred over the years. are at stake, the “but we’re way behind sched- behind schedule, it’s often tempting to cut the ule” argument just isn’t good enough. testing resources to the bone. To be sure, there’s no easy answer to the ques- tion: How much testing is enough? But there’s But in yielding to that temptation, you’re a very easy answer when we get into a situa- potentially adding to the painful tales and tion like Ricky and Stick: You’ve got to do at

Fables in Software Acquisition 9 I’LL USE THIS POLE TO TILT C’MON, LET’S GO FILL THE HIVE AND YOU CATCH AN OLD JUG WITH WATER THE HONEY IN THIS PAIL AND PRACTICE. WHEN IT SPILLS OUT.

THIS IS HOW STICK, I KNOW WE’LL DO IT. A WAY TO GET US SOME HONEY.

HOW, RICKY?

CAREFUL RICKY, DON’T LET IT SPILL OUT TOO FAST.

MUCH LATER . . .

STICK, LOOK OOWWWWW! GET READY OUT! STICK, HERE IT COMES! GREAT RICKY, IT’S POURING PRACTICE MAKES RICKY, RIGHT IN. PERFECT, STICK. IT’S FALLING! NOW LET’S GO GET SOME HONEY!

10 The Adventures of RICKY & STICK Models are great, but they’re not the real But happiness isn’t what you want, truthful- thing. And they can be very deceptive when ness is. If the model doesn’t truly mimic the misused. It’s all too easy to use a model that conditions the system will face in the fi eld, is grossly oversimplifi ed; even worse is to use then none of the simulations you run will tell a model that takes no account of the real risk you much about how the system will actually conditions that will be present (like the risk perform. of getting stung by a fl ock of angry bees!). So we’re constantly in danger of letting the most Bottom line: It’s great if your testing plan optimal scenario be the basis of our models, includes using models and simulation. convincing ourselves that we’re modeling the But don’t model what you hope to fi nd; true context that the system will encounter. model what will really be out there. Two good questions for the contractor might be: “What This pitfall is sooo prevalent in software does that model leave out? And what’s the development; it’s almost too easy to construct delta between the model and reality?” happy models that will give you happy results.

Fables in Software Acquisition 11 SURE. NO ONE’S I HOPE IT’LL HEY GUYS, I SEE USING THIS OLD TV. BE OK. THERE’S YOU’RE PLAYING IF WE HOOK A BUNCH SOME PRETTY WITH ELECTRICITY. NO NEED, BOB, WE’RE OF EXTENSION CORDS RATTY-LOOKING WANT ME TO TAKE TOGETHER, THEY’LL PLACES ON JUST FOOLING A LOOK TO SEE IF AROUND. WE DO? REACH FROM MY THOSE CORDS. EVERYTHING’S OK? HEY, STICK, LIVING ROOM TO YOU KNOW THE TREE HOUSE. WHAT? WE NEED A TELEVISION UP HERE.

HEY GUYS, I WONDERED WHAT THE COMMOTION OK, STICK, I’M WAS ABOUT. GOING TO PLUG ‘ER IN. GET NEXT TIME, DON’T BE SO READY QUICK TO TURN DOWN TO WATCH A HELPING HAND! SPONGEBOB! RICKY! WHAT’S GOING ON? WHAT’S AARRGGHHH! BURNING DOWN THERE?

12 The Adventures of RICKY & STICK Given the realities of human nature and proj- And that’s precisely why the independent The moral is that the IV&V guy isn’t the ect schedules, it’s a very common situation: observer is there. Because everyone has blind enemy. On the contrary, he’s often the only we turn down an offer of outside assistance spots; it’s just a fact of life. The impartial and one who can keep your house from burning because (we tell ourselves) we want to keep independent observer can often help you see down, just because a bit of wire has frayed on schedule, and some meddling outsider will through those blind spots; that’s why the “I” and he’s the only one who has noticed. only slow things down. But that’s only part of in IV&V is so important. So while the tempta- the reason. What’s really lurking in the back tion is to keep the IV&V guy from prying too of our minds is that, if we let someone else much (lest he fi nd something that you’d really look too closely (like letting Bob check out prefer not to know about), a more productive Ricky’s wiring scheme), he might fi nd some- approach, hard as it is, is to welcome him thing seriously wrong, which would screw in and give him free rein to fi nd what faults everything up. he can.

Fables in Software Acquisition 13 14 The Adventures of RICKY & STICK THERE, THAT SHOULD BE ENOUGH.

Estimates and Metrics

Fables in Software Acquisition 15 DO YOU REALLY HEY!!! YOU DON’T WORRY, THIS IS GREAT, THINK SO RICKY? GOT PAINT ON STICK, WE’LL ARE YOU SURE STICK. THIS BRIGHT MY SHIRT!!! JUST PUT IT IN YOU KNOW HOW SURE IT WILL TO RUN IT? GREEN PAINT WILL – OOPS! MY MOM THE WASHING MAKE OUR PLANE WILL KILL ME! MACHINE. PERFECT!

THAT SHOULD DO IT.

SURE. I’VE WATCHED HOW MUCH WE BETTER USE A LOT! MOM DO LAUNDRY SOAP SHOULD YOUR SHIRT IS A MESS. LOTS OF TIMES. WE PUT IN?

HELLLPPPP!!!!!

16 The Adventures of RICKY & STICK When we have no specifi c knowledge about But, sadly, guesses like these often turn out to In brief, wisdom is better than guesses, and the needed quantity of some resource, wheth- be wildly inaccurate. All too often, the fl oor there’s a lot of wisdom out there that’s often er dollars, labor days, or laundry detergent, gets sopping wet and Mom has to call the ignored. The wisdom that exists may only be the only thing we can do is make an estimate. repairman. partially applicable, and there may still be a What with all of the pressure we are typically lot of guesstimation to do. Or maybe there’s under, it’s not uncommon to take an approach It’s really okay to opt for prudence, especially no such wisdom to be found at all. But in based on faith in our own ability to guess well if there’s no other guide. Ricky (and, it seems, that case, you’re no worse off than when you and fueled by optimism; this is the “seems ok a large number of teenagers) could take the started. And no one can later call you on the to me” syndrome. Sometimes we get lucky time to read the label on the detergent box. carpet and say: “Why didn’t you ask Bob?” and everything comes out fi ne: a program Program managers, faced with a diffi cult manager, looking at some unfamiliar metric, decision and nothing on which to base it, with no context and no explanation, might could seek out assistance. Perhaps there’s make an excellent decision. And on a differ- some website, some guidebook, some other ent day, Ricky might guess the right amount source of information available somewhere, of detergent to use. with advice, based on experience, to which you can turn.

Fables in Software Acquisition 17 HEY STICK, YOU KNOW WHAT? WE NEED TO MAKE A LADDER TO GET UP INTO THE WHY DO I TREE HOUSE. ALWAYS HAVE ‘CAUSE I HAVE TO THE HARD JOB? DO THE SCIENTIFIC ENGINEERING. ONCE YOU GET UP WE THERE, REACH DOWN DO? SURE WE DO. BUT WE BETTER AND GRAB MY HAND MAKE SURE THAT IT’S THE RIGHT HEIGHT. GO AHEAD AND CLIMB UP, STICK.

OKAY, STICK, CUT THE PIECES TO BE EXACTLY DOUBLE THIS DISTANCE. I’M REACHING AS FAR AS I CAN, RICKY!

I CAN ALMOST TOUCH YOUR HAND, STICK, SO OUR TWO ARMS’ LENGTH IS EXACTLY HOW LONG THE LADDER SHOULD BE. #?!#%! . . . DARN, STICK, YOU CUT THE ROPE TOO SHORT!

18 The Adventures of RICKY & STICK How many of us haven’t done something problem—we can get that new module written numbers on which to make sound decisions, like this? And always, deep down, we know and debugged in a couple of days, for sure!” if we accept rough fi gures as though they we’re being as dumb as Ricky was. Usually, And then, it’s not only foolish, it can do lots were accurate, and let guesses count as it doesn’t do all that much harm. But, every of harm. gospel, then we’ll fall even further behind, now and then, people who are otherwise ratio- because our arms-length guess was screwy, nal really do hold their arms out to measure a A way to avoid the trap is to realize that the ladder won’t reach, and we’ll have to start picture, walk across the room trying to hold metrics are not second-class citizens. Doing all over again. their arms steady, and then bang a nail into the sexy engineering tasks is important, but a wall to hang the picture on. The results are getting valid metrics on those tasks shouldn’t Bottom line: With your program’s future on usually embarrassing, and sometimes really be an afterthought. Another pitfall is haste: the line, it is prudent to ask your contrac- annoying. we’re often in a hurry and don’t want the tor some hard questions about the relevance delay that careful measurement demands. and accuracy of whatever fi gures are quoted Yet it’s not unheard of, in a big, expensive, se- For big projects (which tend to be late to you. Said differently, do you really think rious DoD program, for someone to do pretty almost by defi nition), enforcing a rigorous he can keep his arms that steady as he walks much the same thing, and use a thoroughly metrics program can slow things up to an across the room? ad hoc method for determining a metric that alarming degree. needs to be more precise. We‘ve all prob- ably witnessed a scene where someone with But that’s the way it is, and it can’t be precious little coding experience says “No changed. If we skimp on getting sound

Fables in Software Acquisition 19 C’MON, STICK, WE’VE GOT TO CLOBBER WELL, WE DON’T ALWAYS HIT EVERY ONE OF OUR WALLY WITH SNOWBALLS WHEN HE SHOWS UP. THAT’S IT, STICK. A NUCLEAR SHOTS, SO LET’S MAKE WE NEED TO HAVE ENOUGH ON HAND TO MAKE STOCKPILE OF MEGATON TEN SNOWBALLS EACH. HIM BEG FOR MERCY SNOW MISSILES. THAT’LL MAKE HIM CRY. HOW MANY IS THAT?

I THINK THAT’S WALLY COMING! THAT’S A LOT OF SNOWBALLS, RICKY. WE BETTER WORK YOU’VE HAD IT WALLY! WE’VE GOT FAST BEFORE HE SHOWS UP. TWENTY KILLER SNOWBALLS AND WE’RE GOING TO BLAST YOU! BETTER MAKE A FEW EXTRA NEXT TIME, 9-10-11-12… RICKY! . . . 18, 19, 20. TWENTY SHOTS, TWENTY MISSES. NOW, YOU’RE BOTH OUT OF AMMO! AND LEARN TO AIM BETTER!

20 The Adventures of RICKY & STICK A software project plan is little more than icant, but only the number of hits. (The reader a codifi ed set of assumptions, expectations, will already have noted that, given Ricky and and hopes. It typically contains some number Stick’s throwing skill, they probably shouldn’t of estimates based, more often than not, on have been planning to barrage Wally with optimism. Yet the sheer statistics of software snowballs in the fi rst place. But that’s a failures, especially IT failures, would suggest different fable.) that a healthy dose of caution, and probably of pessimism, would be more appropriate.1 The moral is that we need to stop counting the wrong things, and start counting the right Ricky thought he was being appropriately things. Easier said than done, perhaps. But cautious when he estimated that, because he it shouldn’t be all that diffi cult to take a long and Stick didn’t always hit every one of their hard look at whatever initial estimates you shots, they’d need ten snowballs each. But his currently have, and wonder “What are these reasoning was upside-down. He never once numbers based on? What aren’t these num- considered how many of their shots actu- ber based on?” There’s a good chance that, ally did hit the target; as it turned out, this somewhere in the answers to those questions, was certainly fewer than one in ten. In other you’ll be saving yourself from getting words, the number of snowballs wasn’t signif- walloped by a whole lot of snowballs.

1 There are many sources for such statistics. One source often referenced is Lyytinen, K. and Hirschheim, R., (1987), “Information Systems Failures: A Survey and Classifi cation of the Empirical Literature,” Oxford Surveys in Information Technology, Vol 4. However, there are many others, whose numbers vary somewhat, but whose essential conclusions do not.

Fables in Software Acquisition 21 22 The Adventures of RICKY & STICK THAT MAY BE WHAT YOU WANT, BUT IT AIN’T WHAT YOU’RE GONNA GET . . .

Requirements

Fables in Software Acquisition 23 OH BOY, WHAT ARE I’M BUILDING ALMOST THERE, STICK. TWO THIS’LL BE YOU DOING, A DOGHOUSE! NOW ALL WE NEED TO STEPS??? GREAT! RICKY? C’MON, STICK, DO IS MAKE THE TWO GIVE ME A HAND. STEPS.

BECAUSE IT SAYS SO HERE IN THE DIRECTIONS. THIS DOGHOUSE HAS GOT TO FOLLOW THE PLAN EXACTLY! STILL NOT WHY DOES THERE YET, STICK. UH, RICKY... IT NEED WE’VE GOTTA DARN! THESE TWO STEPS, KEEP TRYING! STEPS DON’T ANYWAY? FIT! NOW WHAT?

24 The Adventures of RICKY & STICK Sometimes requirements that don’t make It may seem obvious, for instance, that Ricky’s any sense creep into a program. Usually, no notion of front steps for a doghouse was based one knows where they came from, nor why on a misreading of the plans. But Ricky wasn’t they’re there. They may be based on mis- being any sillier than many real-world counter- understandings, or on conditions that have parts: some software requirements specs have become obsolete. Or maybe they were just a sternly dictated versions of COTS products that nasty gift from the Bad Requirements Demon. are several releases out of date, and more than In any case, these are often the very require- a few requirements have been diametrically ments that twist a program into a pretzel. opposite to what the end user has requested.

So it’s perfectly reasonable to periodically Bottom line: A periodic review of the require- reconsider the validity of requirements, either ments asking: “Do each of these still apply? to be sure that they’re still operative, or to Has anything changed?” is a valuable exercise verify that their respective interpretations that can help discover obsolete requirements by the builder and end user is consistent: as early as possible. By doing so, you’ll avoid it’s amazing how often such a reinspection expending (and wasting) a huge amount of will turn up a surprise or two. effort in needlessly trying to meet them.

Fables in Software Acquisition 25 ARE YOU SURE HEY, STICK, I’M GETTING LET’S SEE. WHAT DO I FEEL LIKE EATING? HUNGRY AND MOM’S NOT THAT’LL ALL GO WHAT KIND HOW ABOUT SOME HAM, CHEESE, TUNA FISH, SURE, STICK, WHY AROUND. I’M GOING TO MAKE TOGETHER? OF SANDWICHES, MUSTARD, PASTRAMI, SALAMI, HORSERADISH, NOT? EVERYTHING US SOME SANDWICHES. RICKY? MAYONNAISE, TURKEY, AND KETCHUP? TASTES GREAT, SO THEY’LL ALL TASTE GREAT TOGETHER!

RICKY, THIS MAYBE MOM! HERE WE ARE, STICK. POP OPEN A COUPLE DOESN’T TASTE A LITTLE OF CANS OF SODA AND WE’LL HAVE A FEAST. SO GOOD... TOO MUCH MUSTARD. MOM!

26 The Adventures of RICKY & STICK The process of software system development ALL of our seventy-three thousand processes (And this same scenario also shows there are often involves an ongoing process of refi ning into one central, unifi ed, joint, all-purpose, lots of things that are excellent when taken requirements. And that refi nement process galactic, do-it-all, never-have-to-worry-again individually, but awful when put together is very susceptible to requirements creep, INTEGRATED SYSTEM!” willy-nilly. A different moral, perhaps, but growth, and explosion. It’s the same danger one worth noting.) that Mom is always warning Ricky about: What’s happened is that the understandable “Your eyes are too big for your stomach,” she desire to eliminate redundancy and incompat- The lesson is that, even taking into account says, which he usually ignores. ibility has transformed itself into a greedy the incredible fl exibility of software, a coher- desire for something that ignores practicality ent system needs some internal integrity and Yet the rest of us are often deaf to that same and precedent. We get giddy with possibili- boundedness to it. More important (from the warning. It all starts when a bunch of people ties, and imagine a cosmically large system viewpoint of the poor soul who has to man- start out with a good idea: “Let’s get rid whose humongous list of functional require- age its development), a system’s requirements of these overlapping, obsolete, redundant ments makes any development effort prone should ideally refl ect some comprehension of systems!” So a project begins, and the early to failure. And in those giddy moments, it’s whether those requirements can be satisfi ed. requirements are defi ned. Then everyone easy to forget that the pages of acquisition goes over to the Dark Side: “Now that we see history are littered with tales of failed what we’ve started, why don’t we reengineer programs slain by impossible requirements.

Fables in Software Acquisition 27 CLASS, TODAY FIRST, I WANT YOU TO EXCELLENT, WE’RE GOING DRAW AN AIRPLANE. NOW START TO DO AN ART AFTER YOU’RE ALL DRAWING, BUT PROJECT. FINISHED, I’LL WANT RED, DON’T START YOU TO COLOR IT IN. MRS. PERILLO. COLORING YET!

BUT DON’T START WHAT’S COLORING UNTIL YOUR I TELL YOU. I’LL LET FAVORITE WALLY CHOOSE COLOR; THE COLOR. WALLY?

WHY, THAT’S FINE, I’M DONE! MRS. PERILLO, I’VE CHANGED WALLY. KEEP DRAWING, HEY, STICK, MY MIND. BUT DON’T START I’M GOING TO DO YOU THINK YEAH, STICK, I REALLY LIKE COLORING YET! START COLORING YOU SHOULD, I’LL BE THE FIRST BLUE THE BEST. MY PLANE. RICKY? ONE FINISHED . . .

28 The Adventures of RICKY & STICK WALLY, I THINK SOME YELLOW, STUDENTS MIGHT BE MRS. PERILLO. WALLY THE PAIN I’LL COVER MISSING THEIR BLUE DOES IT AGAIN. BUT OVER THE RED CRAYONS. NO PROBLEM, STICK, AND SHE’LL MY BLUE CRAYON NEVER KNOW. GLORIA, YOU CAN #?!#%! . . . IS REAL DARK. CHOOSE. WHAT’S YOUR FAVORITE COLOR?

People have the annoying habit of changing reason to do so. The lesson is that while it’s attractive to make their minds. When these people are end users early choices and “nail down the require- of software systems, then requirements have Because if we do make some early commit- ments,” it’s not always the wisest course. the annoying habit of mutating. ment, we often don’t (or can’t) be sure what That approach can sometimes save a lot of that commitment implies. And then when time and money, true. But as you’re thinking Given this reality, some of the best advice things change, which they always do, recov- of taking that step, you might also take the about dealing with requirements for today’s ery is sometimes possible, but sometimes it’s trouble to determine from your stakeholder information systems is to maintain fl exibil- not. For Ricky, the fi rst time things changed, community whether all the assumptions that ity as long as feasible. Sometimes the ideal he got away with it, by switching from red to underpin the requirements are still applicable. strategy is lots of prototyping, to gain buy-in dark blue. But when things changed again, Because it may be that there’s a Gloria in your from end-users. Sometimes it’s possible, using and he had to convert that dark blue to pale future, unseen right now, but just waiting for a iterative cycles, to delay freezing the require- yellow, he was lost. All he had was a useless chance to say: “Yellow, Mrs. Perillo.” ments until some fairly late point. But it’s picture of a blue airplane—there was no way almost always a poor idea to make a ton of to erase the blue crayon, and no recovery was early commitments if there’s no compelling possible. Fables in Software Acquisition 29 30 The Adventures of RICKY & STICK SOME ASSEMBLY REQUIRED

Integration and Interoperability

Fables in Software Acquisition 31 THIS HEY, STICK, I’M HUH? WHAT WE’LL CAPTURE WALLY’S DOG BUDDY! THIS OLD BIRD THICK BORED. LET’S GO WILD ANIMAL? LET’S SPLIT UP THE WORK. I’LL TAKE CAGE SHOULD TWINE AND CAPTURE A CARE OF THE CAGE, AND YOU TAKE WORK FINE! SHOULD WILD ANIMAL. CARE OF THE ROPE. BE FINE!

HE’S ALMOST UNDERNEATH, STICK! LET’ER GO!”

RICKY, I’M FALLING! YOU DIDN’T TELL SNAP! ME IT WOULD WEIGH A TON! I SAID ‘ROPE’, NOT TWINE!

RICKY, THE CAGE LOOKS STICK, THE AWFULLY ROPE BROKE! HEAVY . . .

32 The Adventures of RICKY & STICK When multiple parts have to work together— the integration turns out to be far more diffi cult people will work very hard for a while, but anything from twine and birdcages to than anyone had realized, and the twine breaks, the frammis and the jimjam won’t be compat- collections of complex information systems— the birdcage falls, the whole project smashes ible, and the claptraps won’t fi t at all. And, and those parts are constructed independently, to the ground, and everyone else points fi ngers. sooner or later, everyone will fall out of the then there isn’t a prayer of succeeding with- Then, a few months later, a different group of tree yet one more time. out rigorous and careful planning about how enthusiastic, hopeful people gets together and everything is supposed to fi t together. someone says, “Hey! Let’s go build a Really Bottom line: Interoperability doesn’t happen Big Integrated System...” and so forth. just because you want it to. It takes effort and Just about everybody has a favorite story resources to make systems successfully inter- about the pitfalls of poor integration plan- And that’s the moment of truth, when some- operate in a useful way. So whenever some- ning. And yet, over and over, during decades body (perhaps you, Gentle Reader) has to pipe one asserts that “our systems will talk to each of software acquisition, project after project up and say “Hey, let’s stop for a minute! Let’s other...” or something like that, you might ask: has made the same mistake. It is still being see if the plans for the frammis and the plans “How much are we each budgeting for the repeated today. With awful regularity, we see for the jimjam are consistent with each other. interoperability aspect? Let’s see that plan for some group of people get together and some- And let’s be sure that Bob’s claptraps will fi t” how each of us will ensure we’re keeping our one says: “Hey! Let’s build a Big Integrated or some comparable bit of caution. Because if side of the agreement. Hey, now that I think System! I’ll build the frammis and you build somebody doesn’t say something to that effect, of it, let’s see the agreement!” You might just the jimjam. We’ll get Bob to build a few clap- and if that caution isn’t shared by everyone fi nd that the “agreement” is nothing more traps!” But no one worries too much about in the room throughout the whole life of the than a vague hope for a miracle. the integration part of it. And, sooner or later, project, then it’s a virtual certainty that lots of

Fables in Software Acquisition 33 CLASS, TODAY GEE, RICKY, WE’RE GOING TO WE GOT THE BUILD A MODEL EACH OF YOU WILL BLOW UP BALLOONS TO REPRESENT DIFFERENT ATOMS. SMALLEST OF A MOLECULE. BALLOONS. THEN WE’LL TAPE THEM WE’LL LOOK TO THIS WOODEN FRAME. DON’T WORRY, LIKE DORKS. STICK, I HAVE AN IDEA.

SEE? WATER ALWAYS MAKES BALLOONS MUCH BIGGER. NOW OUR ATOMS WILL BE RICKY, IS THAT A THE BIGGEST IN THE WATER BALOON? MOLECULE. STOP! IT WILL BE TOO HEAVY...

34 The Adventures of RICKY & STICK Looking at a single system gives a very the owner of one system sometimes sees no at least one unwritten assumption: she never different perspective from looking at several reason why he shouldn’t make just one little expected that anyone would add balloons that interconnected systems. What’s optimal for fi x here or there, to make his own system a were much too heavy, and thus saw no need to the single system may not be so for the group, bit better. But when this happens, the change, say “Don’t use water balloons!” and vice-versa. The success of any collection however small, might disturb something about of interoperating systems depends on just how the agreements with other systems, and can The lesson is that if you’re the manager of these different perspectives are negotiated potentially have a serious impact on the whole a system that’s an element in a system of and resolved. system of systems, perhaps even destroying it. systems, you need to be proactive in preserv- ing agreements, written and implicit. Before Ricky and Stick, for instance, saw no reason When systems are in relationships with other making any change, even a seemingly trival why they shouldn’t make their dorky little bal- systems, the success of the whole depends on one, you might consider asking everyone (and loons bigger. They looked better, and probably assumptions and agreements that each system that means everyone, those nearby and those felt better. (And who doesn’t like the feel of a adheres to; this is especially true for software light-years away) whether the change will af- good water balloon?) But neither of them con- systems. The agreements are sometimes spec- fect their systems’ operation. Otherwise, you sidered that their balloons weren’t indepen- ifi ed, but not always. In fact, many of today’s might unintentionally change something that dent, but were going to be in a collaborative interoperating systems don’t really have a breaks the whole shebang. Then the system relationship with a lot of other balloons. clear agency that is responsible for the whole; stops running, molecules fall down and every- instead they depend entirely on unwritten as- body gets soaked. It’s not that different for software managers. sumptions that everyone adheres to voluntari- Software is so easy to tweak and change, and ly. In Mrs. Perillo’s case, there was certainly

Fables in Software Acquisition 35 HEY, STICK, LET’S GET IT LOOKS A LOT THIS RACER INTO TIPTOP BETTER. BUT WHAT CONDITION, AND WE’LL ABOUT THESE OLD WE NEED NEW WIN THE NEXT SOAPBOX WE’LL REBUILD IT WHEELS, RICKY? WHEELS, STICK. DERBY HANDS DOWN. FROM THE BOTTOM THEY’RE ALL BENT I’LL GET TWO FOR THEY BETTER BE. UP. AND THIS TIME, OUT OF SHAPE. THE REAR AND YOU I CAN’T TAKE ANOTHER THE BRAKES WILL BE WORK ON THE TWO CRASH LIKE THAT ONE! FAIL-SAFE! FOR THE FRONT.

THESE BIG WHEELS WILL BE GREAT. WE’LL BE HIGHER OFF THE GROUND, SO WE’LL WITH THESE BABIES, SEE MUCH BETTER. WE’LL BE LOW TO THE GROUND AND GO #?!#%! . . . A LOT FASTER.

36 The Adventures of RICKY & STICK When a system is upgraded with new parts, represent an improvement. But considered Bottom line: The evolution of any separate it generally needs to be done with an overall from the perspective of the whole, the part has to be done with an awareness of understanding of the goal of the upgrade. aggregate system may not be improved at how that evolution affects the integration of But when upgrades to different pieces are all; it might not even be operable. (Truth to the whole. So if you (or your contractor) are done independently (as often happens with tell, Ricky’s racer, even with mismatched contemplating an upgrade to a system, you systems of systems, each of which may follow wheels, could still roll. But it would probably might aim to explicitly answer such questions a separate evolutionary path), the upgrades be slower, not faster, and the driver wouldn’t as: What is the goal of this upgrade? How can sometimes be at odds with each other. see where he was going. While that wouldn’t does it match with upgrades to other systems bother Ricky all that much, it’s more serious with which our system interoperates? Because For instance, separate upgrades can follow when it describes how some actual systems if multiple evolutionary goals are at odds, the very different evolutionary goals. The up- evolve.) integrated working of the whole might well be grade to System A may aim toward greater destroyed. internal effeciency while that of System B And confl icting evolutionary goals are not may aim at a better user interface. (Or, as in confi ned to huge systems; they can pop up the case of our hapless heroes, Stick wanted in small, isolated systems just as easily, and to see better, Ricky wanted to make the racer they can occur whether you’re dealing with faster.) Each upgrade might separately COTS products or custom-written code.

Fables in Software Acquisition 37 38 The Adventures of RICKY & STICK WE’LL WORRY ABOUT THAT WHEN THE TIME COMES.

Deployment

Fables in Software Acquisition 39 HEY, YOU TWO -- WHY DON’T THANKS, STICK, LET’S GET GOING. WE’LL YOU COME OVER AND PLAY GLORIA! BLOW UP THE FLOATS WE GOT THAT WILL IN MY AT THE BEACH LAST SUMMER! ME TOO, RICKY. NEW POOL! BE GREAT! I WISH WE WERE AT THE BEACH! GOSH, STICK, I’M DYING IN THIS HEAT!

I CAN’T WAIT TO DO MY FIRST CANNONBALL

C’MON, SILLY, IT’S NOT TOO COLD. GET IN AND WE’LL PRETEND WE’RE AT THE BEACH. GEE, RICK, THIS MUCH LATER . . . HURRY, STICK, IS HARDER THAN (PANT, PANT. . . !) WE HAVEN’T I THOUGHT. (PANT, PANT. . . !) GOT ALL DAY!! ALMOST THERE,STICK. RICKY, I THINK JUST THINK OF THAT I’M GOING TO DIE FIRST COOL PLUNGE! DOING THIS...

40 The Adventures of RICKY & STICK Chronologically speaking, deployment izing that the vast Olympic pool they expected of a system comes late in the life cycle. to fi nd was nothing like the dinky wading But knowledge about where the system will pool they eventually found. actually be installed and run is needed way upfront, when the requirements are Bottom line: Find out early as many grisly being decided. deployment details as you can. Get explicit answers to such questions as: “Where is the And it’s painful to observe how often this system going to be deployed? What is the kind of experience really occurs—how often physical location? What hardware will it run everyone concentrates only on the system on? What else will share the operating envi- and forgets to think ahead about deployment. ronment?” Such knowledge is no less critical And when that happens, it’s not all that differ- than any of the other requirements, and ent from poor Ricky and Stick, who worked getting this knowledge early can only help. so hard blowing up their huge fl oats, not real-

Fables in Software Acquisition 41 SURE WE DO. HEY, STICK SEE HOW WE NEED LOOK, STICK, NEAT IT IS? A TABLE THAT OLD UP HERE. STUMP WILL I’LL GET MY BE GREAT! DAD’S LADDER AND WE’LL HAUL IT UP TO THE TREE HOUSE.

WE DO?

OKAY, STICK, LET ‘ER DROP AND WE’LL BE ALL SET!

ALMOST THERE, STICK. WHEN WE GET IT TO THE TOP STEP, WE CAN JUST LET IT DROP INTO THE TREE HOUSE!

42 The Adventures of RICKY & STICK It’s all too easy to focus only on the benefi ts weight of a very heavy stump). If it can’t, cost? Where are those dollars in the budget? you’ll get from a new system: its hoped-for then you may fi nd yourself expending a huge Will it deploy in stages? and so forth. functionality, the ROI it will bring, or what- effort getting the system into place, as did ever other great things were the selling our heroes, only to come to grief. The moral is that you and your contrator need points that got the program approved in the to know explicit details about the deployment fi rst place. Nor is this necessarily a hardware issue; the environment—load factors for instance—and moral is no less applicable (in fact is very then be sure that the system will operate And this can mean that you ignore thinking applicable!) to a large, complex software properly in that environment. And you need to about context, and about whether the deploy- system. Lots of questions are apt: What addi- know it way upfront: though the deployment ment environment is capable of supporting tional software resources are needed for sys- process may be far in the future, deployment the new system (in much the same way as tem deployment? Who has the responsibility planning should be done at the earlist part of whether a fl imsy tree house can support the to supply them? How much will deployment the project.

Fables in Software Acquisition 43 HEY STICK, I HAVE A GREAT OK, STICK, LET’S GET BACK TO THE RICKY, WHY DID WE IDEA. LET’S OPEN A LEMONADE KITCHEN AND BRING EVERYTHING OUT. BUILD THE STAND STAND AND MAKE SOME BUCKS! WE’LL BE RICH IN A COUPLE OF HOURS! SO FAR AWAY FROM THE KITCHEN? SOUNDS LIKE A WINNER, RICKY!

FORGET IT STICK, WE’RE READY TO GO.

GLASS? OK, BOB, HI, GUYS, HERE IT…. (PANT, PANT) OK, STICK, WE’RE FINALLY I’LL TAKE RICKY! RICKY, WE SET TO MAKE THE BIG BUCKS. A GLASS! FORGOT DARN, STICK. WHERE ARE THE ICE! OK, LET’S GO THE GLASSES?” GET IT.

JUST IN TIME– HERE COMES OUR FIRST CUSTOMER.

44 The Adventures of RICKY & STICK There are dozens of stories about glitches in ice. And for Ricky and Stick, their task was enough, and someone needs to think about deploying software systems: everything from made signifi cantly more diffi cult because whether the chairs are too small. insuffi cient memory or too-slow hardware to of how far they had to run back to get those incompatible disk drives and the glare from glasses and ice, while the lemonade sat in the Bottom line: No matter how spiffy the fl uorescent light bulbs. And there really have sun and poor Bob stayed thirsty. software is, if the people in the fi eld aren’t been such errors. able to use it, it does them no good. What As with almost any story about deployment, else is necessary? Have the users been given Some of these glitches are truly diffi cult to the culprit is focus, since we all tend to focus all the additional tools they need? Have they see in advance, at least until you’ve been on the system being built, and on its require- been trained properly? and other similar ques- burned once or twice. There are, for instance, ments, its features, its design. In so doing, it’s tions. As with poor Bob, there may be some some thorny logistical issues, things like the all too easy to neglect many things that are great-looking lemonade right in front of them, length of supply chains, or the time needed inherently boring to most software engineers but they’ll be thirsty until the glasses arrive. to replenish needed items. You may think, for —a lot of things that software depends on are instance, that selling lemonade is your real not really software things. But someone has job; but you can’t sell it without glasses and to worry whether the extension cord is long

Fables in Software Acquisition 45 46 The Adventures of RICKY & STICK YOU DO IT YOUR WAY, AND I’LL DO IT MINE . . .

Business Processes

Fables in Software Acquisition 47 HEY STICK, I’VE GOT A WHY, IT’LL BE A LOT NEATER THAN USING THOSE DORKY GREAT IDEA! LET’S USE RICKY? OLD BLACK AND WHITE CHECKERS. I’LL TAKE THE O.K., I’LL TAKE THE ROOT I HOPE I CAN BOTTLECAPS TO PLAY ROOT BEERS AND YOU TAKE THE GRAPES. BEER, ORANGE, AND REMEMBER CHECKERS WITH. CREAM, AND YOU TAKE ALL THESE. THE GRAPE, GINGER RICK, THERE ALE, AND BLACK CHERRY. AREN’T ENOUGH ROOT BEERS AND GRAPES . NOW WHAT?

NO IT ISN’T! THIS ISN’T BLACK HEY STICK, YOU SAID I CHERRY — IT’S COLA. THAT’S MY HAVE BLACK THIS ONE SHOULD MAN! CHERRY! BE MY MAN.

I HATE THIS GAME! YOU NEVER SAID ANYTHING ABOUT COLA! WHY SHOULDN’T HE BE MY MAN?

48 The Adventures of RICKY & STICK It’s usual that the introduction of a new implied. He and Stick had played checkers operations, or something of that kind. But software system means that the users will be a million times, and were still playing the whatever the reason, it has to be enough to doing something different from their familiar same game this time around; same rules, offset the inevitable unhappiness of the end tasks. As often as not, the business processes same strategy, same everything. But now they users. More to the point, any conceptual have been reengineered and improved, and the were fi ghting their own tools; they couldn’t separation between a process and the software end result is that things will change for the even tell which were their own men, and they that implements it is suspect. better (or, at least, so everyone hopes). But ended up fi ghting with each other. The same every now and then, someone decides to in- thing can happen with software: a simple task So the moral is: If new software comes into troduce a software system that doesn’t really executed with pencil and paper can become play, it’s probably bogus to think that all it’s change any business processes. All it does is agony when it needs three screens, forty-three doing is supporting the same old process. force the users to learn some very annoying keystrokes, and a trip to the printer. software steps that don’t improve anything: Said in reverse, if you truly must introduce the users are doing exactly what they used to There are, on occasion, good reasons to some new piece of software, ask yourself: do…but now it’s harder. introduce new software while keeping some Have I considered what process reengineer- process unchanged. It might be a huge ing is needed? Have I brought it about? If you When Ricky decided to improvise a new set increase in transaction turnaround time, or haven’t, it’s worth taking a hard look to fi nd of checkers, he paid no heed to what that a vital need for consistency with other out why.

Fables in Software Acquisition 49 OK, WALLY, PREPARE TO MEET THY OK, RICKY, STICK, I’VE DEVELOPED A SURE-FIRE I’LL BE THE GUNNER, DOOM! THIS IS NEXT GENERATION I HOPE IT IMPROVEMENT IN SNOWBALL WARFARE! AND YOU’LL BE THE SNOWBALL TECHNOLOGY! WORKS! WALLY WILL BE DEAD MEAT! LOADER. YOU TOSS ME A SNOWBALL, AND AS I’M FIRING, YOU’RE GETTING THE NEXT ONE READY TO TOSS TO ME.

GO AHEAD, DUMBBELL. I CAN HARDLY WAIT!

STICK, FASTER, HERE TOSS ‘EM STICK! RICKY! HIGHER!

BOY, ARE YOU TWO DUMB!

HELP, RICKY, I SLIPPED!

50 The Adventures of RICKY & STICK When a new software system is introduced, system’s users. Those users likely needed IOC, the task of bringing its users to IOC is often with a loud public fl ourish, it sometimes signifi cant practice with the changed and of equal importance. happens that it falls fl at on its face. Usually reengineered business processes the new it’s just embarrassing, but sometimes it’s quite system demands, and with that training, Moral: it’s worth looking carefully at how dangerous, with the potential for grave effect. the system might otherwise have been a training appears in the project plans. If the This has led to a widespread belief that a triumphant success. training appears to be an afterthought, it’s large percentage of all software is seriously probably not enough. If the training is being fl awed, and that the craft of creating computer Now, Ricky may have been on to something squeezed by the schedule, the schedule needs programs is unacceptably primitive. with his new mode of snowball warfare. But to be changed. And if the training isn’t even he and Stick didn’t bother to practice it, so on the radar screen, then you’d be wise to buy Some of the belief is justifi ed; there’s a lot of they were total doofuses to try out such a a bus ticket and get out of town. Wally’s got bad software out there. But an equally guilty radically different system when they were in some nasty-looking snowballs, and he’s right partner, one that usually hides far from public mortal combat with Wally. (Who knows - the behind you. scrutiny, may be that the folks responsible whole future of the Ricky-Wally War might for introducing the new system didn’t pay have been different.) For any manager whose any real attention to the training of the new responsibility involves bringing a system to

Fables in Software Acquisition 51 HEY GUYS, WANT TO DO YOU THINK OK, GUYS, EACH OF YOU YOU CAN HANDLE GO FISHING WITH ME? NOT TO PICK OUT A ROD, AND HEAD THAT ONE, RICKY? WORRY STICK. OVER TO THE POND. I’LL BE IT’S PRETTY BIG. SURE, BOB! I’M A PRO! THERE IN A FEW MINUTES.

C’MON STICK, LET’S GET STARTED. WATCH THIS! LISTEN, RICKY: DON’T PICK OUT A ROD JUST SHOULDN’T WE BECAUSE IT’S WAIT FOR BOB? STICK, THE BIGGEST I SLIPPED!! ONE. YOU WANT A ROD THAT SUITS YOU!

RICKY, WE’RE FALLING INTO THE WATER!!!

52 The Adventures of RICKY & STICK Tools, whether fi shing rods or software sys- that will continue for the foreseeable future. or some equally vacuous accusation. Keep the tems, should be appropriate to both their in- But resources are fi nite, and they have been faith, friend. In response, you can point to a tended use and their intended users. But often, squandered too often, usually because realism depressingly large number of failed software there’s a mismatch somewhere along the line. somehow gets misplaced, just as happened programs over the past two decades. Surely, Sometimes, what the users want isn’t what to Ricky. So questions like the following are totaling the cost of those wasted programs they really need. And sometimes, regardless apt, and should be asked as early as possible: should be answer enough. of what they want, what they need is far from Are these the capabilities that we really need? what they get. Or is our true need somewhere else? What precisely will happen if we don’t get this Ricky’s tumble into the drink came from this new system? If the acquisition is complex, or kind of mismatch. He was dazzled by big- expensive, or controversial, does the system’s ger!, and paid no attention to the fact that the potential benefi t outweigh the risks should the huge rod was far beyond his size and strength. acquisition fail? Is it imperative to take a large Sometimes, organizations are equally dazzled leap forward, or can there be several small by other things—newer! fancier! better! steps? And are we trying to use a fi shing rod cheaper! faster!—all of which are equally that we have no business using? seductive and equally dangerous. When posing these questions, you will run No one can doubt the DoD’s need for the the danger of “acting negative,” or “being ob- fi nest software systems possible, a need structionist,” or “not thinking out of the box,”

Fables in Software Acquisition 53 ONE FINAL THOUGHT . . .

ONE DAY, AS SUMMER WAS COMING TO AN END, SUDDENLY, HE GOT A HORRIBLE VISION OF RICKY TOLD HIS MOM HOW MUCH HE WAS DREAD- THE REST OF HIS LIFE FILLED WITH NEW SCHOOL ING THE START OF SCHOOL. “I HATE THOSE DUMB YEARS, HATEFUL ASSIGNMENTS AND TESTS, AND TESTS, AND THOSE DUMB ASSIGNMENTS. WHEN TEACHERS NAGGING HIM TO LEARN EVER-HARD- THE SUMMER STARTED, I THOUGHT I WAS FINALLY ER SUBJECTS. HE WAS BEGINNING TO UNDER- FREE, AND NOW IT’S ALL STARTING AGAIN!” HE WAS STAND THAT A NEW TERM WOULD NEVER BE NEAR TEARS. A ONCE-ONLY EVENT TO BE GOTTEN THROUGH, BUT PART OF A LARGER, ONGOING PROCESS. HIS MOM WAS UNDERSTANDING, BUT REMINDED THE PROSPECT FILLED HIM WITH A GREAT DREAD. RICKY, “SURE, HONEY. SUMMER WAS A FUN TIME. BUT DON’T FORGET, SUMMERS ARE ALWAYS TOO AFTER RICKY HAD GONE TO BED (UNUSUALLY, SHORT, AND AUTUMN ALWAYS COMES, AND THEN BEFORE BEING TOLD TO), HIS DAD ASKED HIS YOU ALWAYS GO BACK TO SCHOOL. AND SCHOOL MOM, “WHAT’S WRONG WITH HIM?” SHE SMILED. ALWAYS MEANS YOU’LL HAVE NEW TEACHERS, WITH “DON’T WORRY,” HIS MOM SAID, “HE’S JUST NEW THINGS TO LEARN, AND TESTS AND ASSIGN- BEGUN TO PUT IT ALL TOGETHER — REALIZING MENTS FOR YOU TO DO.” THAT HE’LL ALWAYS BE MOVING INTO ANOTHER GRADE, WITH UNFAMILIAR TEACHERS, AND NEW THIS WAS THE FIRST TIME THAT RICKY HAD EVER SUBJECTS. HE DOESN’T WANT IT TO BE TRUE, CONSCIOUSLY PAID ATTENTION TO THE IDEA OF PER- POOR KID; HE WANTS TIME TO STOP AND FOR PETUALLY GOING INTO NEW GRADES. HE KNEW, OF THINGS TO STAY JUST THE WAY THEY ARE NOW. COURSE, THAT THERE WERE OLDER KIDS IN HIGHER BUT HE’S STARTING TO UNDERSTAND THAT GRADES. BUT HE HAD NEVER QUITE THOUGHT HE DOESN’T HAVE MUCH CHOICE IN THE ABOUT SCHOOL IN THIS NEVER-ENDING WAY. MATTER…”

54 The Adventures of RICKY & STICK Owners of modern software systems, The real solution, diffi cult as it may be, is particularly information systems, are to embrace the march of technology and to increasingly aware that the stability of their make it work for you; to accept that change systems is constantly being undermined. really will be never-ending. This means devel- Familiar tools disappear, new ones appear, oping a strategy that somehow encompasses Web services evolve, commercial products and expects the inevitable earthquakes to your are updated, users demand new capabilities, system, and makes them opportunities for and so forth. And the pace of this instabil- improvement and growth. ity is only increasing. It’s normal to fi nd this unsettling, and to try to nail down islands of stability that last while the rest of the world changes around you. But that strategy will only work for a little while—about as long as the endless summer that Ricky thought he had fi nally found.

Fables in Software Acquisition 55 Epilogue

And so we come to the end of the adventures That the morals are largely self-evident is Interoperation fails if someone ignores the of Ricky and Stick. We began by calling these obvious. That they often require restating is assumptions held by everyone else. (p.35) stories “fables,” and the term is apt, since painfully true. If separate systems evolve, somebody needs each story is intended to demonstrate some to keep an eye on preserving their inter- moral or useful principle. Thus, in each epi- So to recap, the Morals Of Our Stories are: sode, we’ve suggested a few ways that It’s really good to test before fi elding. (p.9) operation. (p.37) the story might be applicable to problems in It’s usually wiser to let a model model Knowing where a system will be deployed the real (and, sadly, no less hazardous!) world something real (p.11) is as important as knowing what the system of software acquisition. We truly hope that, in does. (p.41) addition to provoking a smile or two, IV&V is, by and large, a good thing. (p.13) Planning for deployment generally needs to some of these tales will resonate with readers Using the “seems OK to me” rule is often come as early in the life cycle as other system who are really grappling with the situations a recipe for disaster. (p.17) that are only fi ctional here. requirements. (p.43) Metrics aren’t second-class citizens. (p.19) Deploying the software usually means deploy- In the great fables of antiquity, their morals Counting the right things is better than ing a lot more than the software. (p.45) were generally stated as clear, easily-remem- counting the wrong things. (p.21) Big software change almost always means bered mottoes, such as “One man’s pain is It can’t hurt to rethink the requirements big change to the business process. (p.49) another man’s pleasure,” or “Necessity is the every now and then. (p.25) mother of invention.” Unfortunately—from Any new business process means some—and this author’s viewpoint at least—these well- A grab bag of “want-to-have’s” doesn’t make often a lot—of new training. (p.51) turned phrases are remarkably diffi cult to a requirements set. (p.27) The biggest (or most expensive, or most come up with. (I suspect that old Aesop may “Nailing down the requirements early” isn’t feature-laden) system is not necessarily have had a couple of Madison Ave. types necessarily a good idea. (p.29) what is needed. (p.53) helping him out.) But since I wish to place the overall set of “morals” in some sort of relief, Interoperation doesn’t happen just because Continunual change is inevitable. This is I herewith append a thumbnail list of them. everyone wants it to. (p.33) true whether we wish it or not. (p.55)

56 The Adventures of RICKY & STICK Afterword Acknowledgements

Writing this little book has been a genuinely A great many friends made signifi cant contri- pleasurable experience. David and I found butions to this endeavor. Lisa Masciantonio the collaboration enlightening on several and Al Evans found ways to bridge the gap levels, not least of which was how well the between having a lot of fun and working on a little comic stories we devised had genuine real project. Tricia O., Fast Eddie, Denny D., bearing on topics that are really quite serious and Big Bad John were particularly helpful and important. And we feel that there’s a lot and gave welcome encouragement. Claire D. more that could be said. We’re therefore very corrected sloppy grammar and removed illogi- interested in hearing from any readers who cal and inconsistent wording. Slim Hissam can suggest comparable situations, topics, kept me on the straight and narrow all through stories, scenarios, whatever. If you can help the early days, when I nearly fell into several us concoct a few more of these little fables, traps; it’s really due to him that Ricky and we’ll defi nitely fi nd a way to make them see Stick came alive. And more than any words the light of day. ([email protected]) of thanks can convey, Bob Fantazier came up with unbelievable solutions to convert a large number of text fi les, drawings, designs, random ideas, and last-minute demands into a hugely attractive book. To all of these friends, David and I would like to say “Hey Stick, you know what? We should write a book…”

Fables in Software Acquisition 57 For More Information, contact—

David J. Carney

Phone 412.268.6525

Email [email protected]

58 The Adventures of RICKY & STICK