Your name is Bob. The date is January 3, 2001, and your head still aches from the recent millennial revelry. You are sitting in a conference room with several managers and a group of your peers. You are a project team leader. Your boss is there, and he has brought along all of his team leaders. His boss called the meeting.
“We have a new project to develop,” says your boss’s boss. Call him BB. The points in his hair are so long that they scrape the ceiling. Your boss’s points are just starting to grow, but he eagerly awaits the day when he can leave Brylcream stains on the acoustic tiles. BB describes the essence of the new market they have identified and the product they want to develop to exploit this market.
“We must have this new project up and working by fourth quarter October 1,” BB demands. “Nothing is of higher priority, so we are cancelling your current project.”
The reaction in the room is stunned silence. Months of work are simply going to be thrown away. Slowly, a murmur of objection begins to circulate around the conference table.
His points give off an evil green glow as BB meets the eyes of everyone in the room. One by one, that insidious stare reduces each attendee to quivering lumps of protoplasm. It is clear that he will brook no discussion on this matter.
Once silence has been restored, BB says, “We need to begin immediately. How long will it take you to do the analysis?”
You raise your hand. Your boss tries to stop you, but his spit wad misses you and you are unaware of his efforts.
“Sir, we can’t tell you how long the analysis will take until we have some requirements.”
“The requirements document won’t be ready for 3 or 4 weeks,” BB says, his points vibrating with frustration. “So, pretend that you have the requirements in front of you now. How long will you require for analysis?”
No one breathes. Everyone looks around to see whether anyone has some idea.
“If analysis goes beyond April 1, we have a problem. Can you finish the analysis by then?”
Your boss visibly gathers his courage: “We’ll find a way, sir!” His points grow 3 mm, and your headache increases by two Tylenol.
“Good.” BB smiles. “Now, how long will it take to do the design?”
“Sir,” you say. Your boss visibly pales. He is clearly worried that his 3 mms are at risk. “Without an analysis, it will not be possible to tell you how long design will take.”
BB’s expression shifts beyond austere. “PRETEND you have the analysis already!” he says, while fixing you with his vacant, beady little eyes. “How long will it take you to do the design?”
Two Tylenol are not going to cut it. Your boss, in a desperate attempt to save his new growth, babbles: “Well, sir, with only six months left to complete the project, design had better take no longer than 3 months.”
“I’m glad you agree, Smithers!” BB says, beaming. Your boss relaxes. He knows his points are secure. After a while, he starts lightly humming the Brylcream jingle.
BB continues, “So, analysis will be complete by April 1, design will be complete by July 1, and that gives you 3 months to implement the project. This meeting is an example of how well our new consensus and empowerment policies are working. Now, get out there and start working. I’ll expect to see TQM plans and QIT assignments on my desk by next week. Oh, and don’t forget that your cross functional team meetings and reports will be needed for next month’s quality audit.”
“Forget the Tylenol,” you think to yourself as you return to your cubicle. “I need bourbon.”
Visibly excited, your boss comes over to you and says, “Gosh, what a great meeting. I think we’re really going to do some world shaking with this project.” You nod in agreement, too disgusted to do anything else.
“Oh,” your boss continues, “I almost forgot.” He hands you a 30-page document. “Remember that the SEI is coming to do an evaluation next week. This is the evaluation guide. You need to read through it, memorize it, and then shred it. It tells you how to answer any questions that the SEI auditors ask you. It also tells you what parts of the building you are allowed to take them to and what parts to avoid. We are determined to be a CMM level 3 organizations by June!”
You and your peers start working on the analysis of the new project. This is difficult because you have no requirements. But from the 10-minute introduction given by BB on that fateful morning, you have some idea of what the product is supposed to do.
Corporate process demands that you begin by creating a use case document. You and your team begin enumerating use cases and drawing oval and stick diagrams.
Philosophical debates break out among the team members. There is disagreement as to whether certain use cases should be connected with <<extends>> or <<includes>> relationships. Competing models are created, but nobody knows how to evaluate them. The debate continues, effectively paralyzing progress.
After a week, somebody finds the iceberg.com Web site, which recommends disposing entirely of <<extends>> and <<includes>> and replacing them with <<precedes>> and <<uses>>. The documents on this Web site, authored by Don Sengroiux, describes a method known as stalwart-analysis, which claims to be a step-by-step method for translating use cases into design diagrams.
More competing use case models are created using this new scheme, but again, people can’t agree on how to evaluate them. The thrashing continues.
More and more, the use case meetings are driven by emotion rather than by reason. If it weren’t for the fact that you don’t have requirements, you’d be pretty upset by the lack of progress you are making.
The requirements document arrives on February 15. And then again on February 20, 25, and every week thereafter. Each new version contradicts the previous one. Clearly, the marketing folks who are writing the requirements, empowered though they might be, are not finding consensus.
At the same time, several new competing use case templates have been proposed by the various team members. Each template presents its own particularly creative way of delaying progress. The debates rage on.
On March 1, Prudence Putrigence, the process proctor, succeeds in integrating all the competing use case forms and templates into a single, all-encompassing form. Just the blank form is 15 pages long. She has managed to include every field that appeared on all the competing templates. She also presents a 159-page document describing how to fill out the use case form. All current use cases must be rewritten according to the new standard.
You marvel to yourself that it now requires 15 pages of fill-in-the-blank and essay questions to answer the question: What should the system do when the user presses Return?
The corporate process (authored by L. E. Ott, famed author of “Holistic Analysis: A Progressive Dialectic for Software Engineers”) insists that you discover all primary use cases, 87 percent of all secondary use cases, and 36.274 percent of all tertiary use cases before you can complete analysis and enter the design phase. You have no idea what a tertiary use case is. So in an attempt to meet this requirement, you try to get your use case document reviewed by the marketing department, which you hope will know what a tertiary use case is.
Unfortunately, the marketing folks are too busy with sales support to talk to you. Indeed, since the project started, you have not been able to get a single meeting with marketing, which has provided a never-ending stream of changing and contradictory requirements documents.
While one team has been spinning endlessly on the use case document, another team has been working out the domain model. Endless variations of UML documents are pouring out of this team. Every week, the model is reworked. The team members can’t decide whether to use <<interfaces>> or <<types>> in the model. A huge disagreement has been raging on the proper syntax and application of OCL. Others on the team just got back from a 5-day class on catabolism, and have been producing incredibly detailed and arcane diagrams that nobody else can fathom.
On March 27, with one week to go before analysis is to be complete, you have produced a sea of documents and diagrams but are no closer to a cogent analysis of the problem than you were on January 3.
And then, a miracle happens.
On Saturday, April 1, you check your e-mail from home. You see a memo from your boss to BB. It states unequivocally that you are done with the analysis!
You phone your boss and complain. “How could you have told BB that we were done with the analysis?”
“Have you looked at a calendar lately?” he responds. “It’s April 1!”
The irony of that date does not escape you. “But we have so much more to think about. So much more to analyze! We haven’t even decided whether to use <<extends>> or <<precedes>>!”
“Where is your evidence that you are not done?” inquires your boss, impatiently.
“Whaaa . . . .”
But he cuts you off. “Analysis can go on forever; it has to be stopped at some point. And since this is the date it was scheduled to stop, it has been stopped. Now, on Monday, I want you to gather up all existing analysis materials and put them into a public folder. Release that folder to Prudence so that she can log it in the CM system by Monday afternoon. Then get busy and start designing.”
As you hang up the phone, you begin to consider the benefits of keeping a bottle of bourbon in your bottom desk drawer.
They threw a party to celebrate the on-time completion of the analysis phase. BB gave a colon-stirring speech on empowerment. And your boss, another 3 mm taller, congratulated his team on the incredible show of unity and teamwork. Finally, the CIO takes the stage to tell everyone that the SEI audit went very well and to thank everyone for studying and shredding the evaluation guides that were passed out. Level 3 now seems assured and will be awarded by June. (Scuttlebutt has it that managers at the level of BB and above are to receive significant bonuses once the SEI awards level 3.)
As the weeks flow by, you and your team work on the design of the system. Of course, you find that the analysis that the design is supposedly based on is flawedno, useless; no, worse than useless. But when you tell your boss that you need to go back and work some more on the analysis to shore up its weaker sections, he simply states, “The analysis phase is over. The only allowable activity is design. Now get back to it.”
So, you and your team hack the design as best you can, unsure of whether the requirements have been properly analyzed. Of course, it really doesn’t matter much, since the requirements document is still thrashing with weekly revisions, and the marketing department still refuses to meet with you.
The design is a nightmare. Your boss recently misread a book named The Finish Line in which the author, Mark DeThomaso, blithely suggested that design documents should be taken down to code-level detail.
“If we are going to be working at that level of detail,” you ask, “why don’t we simply write the code instead?”
“Because then you wouldn’t be designing, of course. And the only allowable activity in the design phase is design!”
“Besides,” he continues, “we have just purchased a companywide license for Dandelion! This tool enables ‘Round the Horn Engineering!’ You are to transfer all design diagrams into this tool. It will automatically generate our code for us! It will also keep the design diagrams in sync with the code!”
Your boss hands you a brightly colored shrink-wrapped box containing the Dandelion distribution. You accept it numbly and shuffle off to your cubicle. Twelve hours, eight crashes, one disk reformatting, and eight shots of 151 later, you finally have the tool installed on your server. You consider the week your team will lose while attending Dandelion training. Then you smile and think, “Any week I’m not here is a good week.”
Design diagram after design diagram is created by your team. Dandelion makes it very difficult to draw these diagrams. There are dozens and dozens of deeply nested dialog boxes with funny text fields and check boxes that must all be filled in correctly. And then there’s the problem of moving classes between packages.
At first, these diagram are driven from the use cases. But the requirements are changing so often that the use cases rapidly become meaningless.
Debates rage about whether VISITOR or DECORATOR design patterns should be used. One developer refuses to use VISITOR in any form, claiming that it’s not a properly object-oriented construct. Someone refuses to use multiple inheritance, since it is the spawn of the devil.
Review meetings rapidly degenerate into debates about the meaning of object orientation, the definition of analysis versus design, or when to use aggregation versus association.
Midway through the design cycle, the marketing folks announce that they have rethought the focus of the system. Their new requirements document is completely restructured. They have eliminated several major feature areas and replaced them with feature areas that they anticipate customer surveys will show to be more appropriate.
You tell your boss that these changes mean that you need to reanalyze and redesign much of the system. But he says, “The analysis phase is over. The only allowable activity is design. Now get back to it.”
You suggest that it might be better to create a simple prototype to show to the marketing folks and even some potential customers. But your boss says, “The analysis phase is over. The only allowable activity is design. Now get back to it.”
Hack, hack, hack, hack. You try to create some kind of a design document that might reflect the new requirements documents. However, the revolution of the requirements has not caused them to stop thrashing. Indeed, if anything, the wild oscillations of the requirements document have only increased in frequency and amplitude. You slog your way through them.
On June 15, the Dandelion database gets corrupted. Apparently, the corruption has been progressive. Small errors in the DB accumulated over the months into bigger and bigger errors. Eventually, the CASE tool just stopped working. Of course, the slowly encroaching corruption is present on all the backups.
Calls to the Dandelion technical support line go unanswered for several days. Finally, you receive a brief e-mail from Dandelion, informing you that this is a known problem and that the solution is to purchase the new version, which they promise will be ready some time next quarter, and then reenter all the diagrams by hand.
Then, on July 1 another miracle happens! You are done with the design!
Rather than go to your boss and complain, you stock your middle desk drawer with some vodka.
They threw a party to celebrate the on-time completion of the design phase and their graduation to CMM level 3. This time, you find BB’s speech so stirring that you have to use the restroom before it begins.
New banners and plaques are all over your workplace. They show pictures of eagles and mountain climbers, and they talk about teamwork and empowerment. They read better after a few scotches. That reminds you that you need to clear out your file cabinet to make room for the brandy.
You and your team begin to code. But you rapidly discover that the design is lacking in some significant areas. Actually, it’s lacking any significance at all. You convene a design session in one of the conference rooms to try to work through some of the nastier problems. But your boss catches you at it and disbands the meeting, saying, “The design phase is over. The only allowable activity is coding. Now get back to it.”
The code generated by Dandelion is really hideous. It turns out that you and your team were using association and aggregation the wrong way, after all. All the generated code has to be edited to correct these flaws. Editing this code is extremely difficult because it has been instrumented with ugly comment blocks that have special syntax that Dandelion needs in order to keep the diagrams in sync with the code. If you accidentally alter one of these comments, the diagrams will be regenerated incorrectly. It turns out that “Round the Horn Engineering” requires an awful lot of effort.
The more you try to keep the code compatible with Dandelion, the more errors Dandelion generates. In the end, you give up and decide to keep the diagrams up to date manually. A second later, you decide that there’s no point in keeping the diagrams up to date at all. Besides, who has time?
Your boss hires a consultant to build tools to count the number of lines of code that are being produced. He puts a big thermometer graph on the wall with the number 1,000,000 on the top. Every day, he extends the red line to show how many lines have been added.
Three days after the thermometer appears on the wall, your boss stops you in the hall. “That graph isn’t growing quickly enough. We need to have a million lines done by October 1.”
“We aren’t even sh-sh-sure that the proshect will require a m-million linezh,” you blather.
“We have to have a million lines done by October 1,” your boss reiterates. His points have grown again, and the Grecian formula he uses on them creates an aura of authority and competence. “Are you sure your comment blocks are big enough?”
Then, in a flash of managerial insight, he says, “I have it! I want you to institute a new policy among the engineers. No line of code is to be longer than 20 characters. Any such line must be split into two or morepreferably more. All existing code needs to be reworked to this standard. That’ll get our line count up!”
You decide not to tell him that this will require two unscheduled work months. You decide not to tell him anything at all. You decide that intravenous injections of pure ethanol are the only solution. You make the appropriate arrangements.
Hack, hack, hack, and hack. You and your team madly code away. By August 1, your boss, frowning at the thermometer on the wall, institutes a mandatory 50-hour workweek.
Hack, hack, hack, and hack. By September 1st, the thermometer is at 1.2 million lines and your boss asks you to write a report describing why you exceeded the coding budget by 20 percent. He institutes mandatory Saturdays and demands that the project be brought back down to a million lines. You start a campaign of remerging lines.
Hack, hack, hack, and hack. Tempers are flaring; people are quitting; QA is raining trouble reports down on you. Customers are demanding installation and user manuals; salespeople are demanding advance demonstrations for special customers; the requirements document is still thrashing, the marketing folks are complaining that the product isn’t anything like they specified, and the liquor store won’t accept your credit card anymore. Something has to give. On September 15, BB calls a meeting.
As he enters the room, his points are emitting clouds of steam. When he speaks, the bass overtones of his carefully manicured voice cause the pit of your stomach to roll over. “The QA manager has told me that this project has less than 50 percent of the required features implemented. He has also informed me that the system crashes all the time, yields wrong results, and is hideously slow. He has also complained that he cannot keep up with the continuous train of daily releases, each more buggy than the last!”
He stops for a few seconds, visibly trying to compose himself. “The QA manager estimates that, at this rate of development, we won’t be able to ship the product until December!”
Actually, you think it’s more like March, but you don’t say anything.
“December!” BB roars with such derision that people duck their heads as though he were pointing an assault rifle at them. “December is absolutely out of the question. Team leaders, I want new estimates on my desk in the morning. I am hereby mandating 65-hour work weeks until this project is complete. And it better be complete by November 1.”
As he leaves the conference room, he is heard to mutter: “Empowermentbah!”
Your boss is bald; his points are mounted on BB’s wall. The fluorescent lights reflecting off his pate momentarily dazzle you.
“Do you have anything to drink?” he asks. Having just finished your last bottle of Boone’s Farm, you pull a bottle of Thunderbird from your bookshelf and pour it into his coffee mug. “What’s it going to take to get this project done?” he asks.
“We need to freeze the requirements, analyze them, design them, and then implement them,” you say callously.
“By November 1?” your boss exclaims incredulously. “No way! Just get back to coding the damned thing.” He storms out, scratching his vacant head.
A few days later, you find that your boss has been transferred to the corporate research division. Turnover has skyrocketed. Customers, informed at the last minute that their orders cannot be fulfilled on time, have begun to cancel their orders. Marketing is reevaluating whether this product aligns with the overall goals of the company. Memos fly, heads roll, policies change, and things are, overall, pretty grim.
Finally, by March, after far too many sixty-five-hour weeks, a very shaky version of the software is ready. In the field, bug-discovery rates are high, and the technical support staff are at their wits’ end, trying to cope with the complaints and demands of the irate customers. Nobody is happy.
In April, BB decides to buy his way out of the problem by licensing a product produced by Rupert Industries and redistributing it. The customers are mollified, the marketing folks are smug, and you are laid off.
{Dotnet}.Share(knowledge) 