A Case Study in Classic Mistakes.doc

  • Upload
    namdao

  • View
    224

  • Download
    0

Embed Size (px)

Citation preview

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    1/12

    A Case Study in Classic Mistakes

    Mike was eating lunch in his office and looking out his window on abright April morning. He was a technical lead for Giga Safe, a medical

    insurance company.

    "Mike, you got the funding for the Giga-uote program!ongratulations!" #t was $ill, Mike%s boss. "&he e'ecuti(e committeelo(ed the idea of automating our medical insurance )uotes. #t alsolo(ed the idea of uploading the day%s )uotes to the head office e(erynight so that we always ha(e the latest sales leads online. #%(e got ameeting now, but we can discuss the details later. Good *ob on that

    proposal!"

    Mike had written the proposal for the Giga-uote program monthsearlier, but his proposal had been for a standalone + program withoutany ability to communicate with the head office. h well. &his wouldgi(e him a chance to lead a client-ser(er pro*ect in a modern G#en(ironment, and that%s what he wanted. &hey had almost a year to dothe pro*ect, and that should gi(e them plenty of time to add a newfeature. Mike picked up the phone and dialed his wife%s number.

    "Honey, let%s go out to dinner tonight to celebrate ..."&he ne't morning, $ill met with Mike to discuss the pro*ect. ", $ill./hat%s up0 &his doesn%t sound like )uite the same proposal # workedon."

    $ill felt uneasy. Mike hadn%t participated in the re(isions to theproposal, but there hadn%t been time to in(ol(e him. nce the e'ecuti(ecommittee heard about the Giga-uote program, they%d taken o(er.

    "&he e'ecuti(e committee lo(es the idea of building software toautomate medical insurance )uotes. $ut they want to be able to transferthe field )uotes into the mainframe computer automatically. And theywant to ha(e the system done before our new rates take effect 1anuary2. &hey mo(ed the software-complete date you proposed up from

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    2/12

    March 2 to 3o(ember 2, which shrinks your schedule to 4 months."

    Mike had estimated the *ob would take 25 months. He didn%t think they

    had much chance of finishing in 4 months, and he told $ill so. "6et meget this straight," Mike said. "#t sounds like you%re saying that thecommittee added a big communications re)uirement and chopped theschedule from 25 months to 40"

    $ill shrugged. "# know it will be a challenge, but you%re creati(e, and #think you can pull it off. &hey appro(ed the budget you wanted, andadding the communications link can%t be that hard. 7ou asked for 84staff-months, and you got it. 7ou can recruit anyone you like to work

    on the pro*ect and increase the team si9e too." $ill told him to go talkwith some other de(elopers and figure out a way to deli(er thesoftware on time.

    Mike got together with arl, another technical lead, and they lookedfor ways to shorten the schedule. "/hy don%t you use :: and ob*ect-oriented design0" arl asked. "7ou%ll be more producti(e than with ,and that should sha(e a month or two off the schedule." Mike thought

    that sounded good. arl also knew of a report-building tool that wassupposed to cut de(elopment time in half. &he pro*ect had a lot ofreports, so those two changes would get them down to about ninemonths. &hey were due for newer, faster hardware, too, and that couldsha(e off a couple of weeks. #f he could recruit really top-notchde(elopers, that might bring them down to about se(en months. &hatshould be close enough. Mike took his findings back to $ill.

    "6ook," $ill said. "Getting the schedule down to se(en months is good,

    but it%s not good enough. &he committee was (ery clear about the si'-month deadline. &hey didn%t gi(e me a choice. # can get you the newhardware you want, but you and your team are going to ha(e to findsome way to get the schedule down to si' months or work someo(ertime to make up the difference."

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    3/12

    Mike considered the fact that his initial estimate had *ust been aballpark guess and thought maybe he could pull it off in si' months.", $ill. #%ll hire a couple of sharp contractors for the pro*ect. Maybe

    we can find some people with communications e'perience to help withuploading data from the + to the mainframe."

    $y May 2, Mike had put a team together. 1ill, Sue, and &omas weresolid, in-house de(elopers, and they happened to be unassigned. Herounded out the team with eiko and hip, two contractors. eiko hade'perience both on +s and the kind of mainframe they wouldinterface with. 1ill and &omas inter(iewed hip and recommendedagainst hiring him, but Mike was impressed. He had communicationse'perience and was a(ailable immediately, so Mike hired him anyway.

    At the first team meeting, $ill told the team that the Giga-uoteprogram was strategically important to the Giga Safe corporation.Some of the top people in the company would be watching them. #fthey succeeded, there would be rewards all around. He said he was surethat they could pull it off.

    After $ill%s pep talk, Mike sat down with the team and laid out theschedule. &he e'ecuti(e committee had more or less handed them aspecification, and they would spend the ne't two weeks filling in thegaps. &hen they%d spend si' weeks on design, which would lea(e themfour months for construction and testing. His seat-of-the-pants estimatewas that the final product would consist of about 8;,;;; lines of codein ::.

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    4/12

    design. &hey came up with a design that seemed to make a good use of::%s features.

    &hey finished the design by 1une 2=, ahead of schedule, and begancoding like cra9y to meet their goal of a first-release-to-testing bySeptember 2. &he pro*ect hadn%t been entirely smooth. 3either 1ill nor&omas liked hip, and Sue had also complained that he wouldn%t letanyone near his code. Mike attributed the personality clashes to thelong hours e(eryone was working. 3e(ertheless, by early August, theyreported that they were between >= and ?;-percent done.

    #n mid-August, the actuarial department released the rates for the ne't

    year, and the team disco(ered that they had to accommodate an entirelynew rate structure. &he new rating method re)uired them to ask)uestions about e'ercise habits, drinking habits, smoking habits,recreational acti(ities, and other factors that hadn%t been included in therating formulas before. ::, they thought, was supposed to shieldthem from the effects of such changes. &hey had been counting on *ust

    plugging some new numbers into a ratings table. $ut they had tochange the input dialogs, database design, database access, and

    communications ob*ects to accommodate the new structure. As theteam scrambled to retrofit their design, Mike told Stacy that they might

    be a few days late releasing the first build to testing.

    As e'pected, the team didn%t ha(e a build ready by September 2, andMike continued to assure Stacy that the build was only a day or twoaway.

    @ays turned to weeks, and the ctober 2 deadline for handing o(er the

    feature-complete build to testing came and went. @e(elopment stillhadn%t handed o(er the first build to testing. Stacy called a meetingwith $ill to discuss the schedule. "/e ha(en%t gotten a build fromde(elopment yet," she said. "/e were supposed to get our first build onSeptember 2, and since we ha(en%t gotten one yet, they%(e got to be at

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    5/12

    least a full month behind schedule. # think they%re in trouble."

    "&hey%re in trouble, all right," $ill said. "6et me talk to the team. #%(e

    promised 4;; agents that they would ha(e this program by 3o(ember2. /e ha(e to get that program out in time for the rate change."

    $ill called a team meeting. "&his is a fantastic team, and you should bemeeting your commitments," he told them. "# don%t know what%s gonewrong here, but # e'pect e(eryone to work hard and deli(er thissoftware on time. 7ou can still earn your bonuses, but now you%regoing to ha(e to work for them. As of now, #%m putting all of you on a4-day-per-week, 2;-hour-per-day schedule until this software is done."

    After the meeting, 1ill and &omas grumbled to Mike about not needingto be treated like children, but they agreed to work the hours $illwanted.

    &he team slipped the schedule two weeks, promising a feature-complete build by 3o(ember 2=. &hat allowed for si' weeks of testing

    before the new rates went into effect in 1anuary.

    &he team released its first build to testing four weeks later on3o(ember 2 and met to discuss a few remaining problems areas.

    &omas was working on report generation and had run into a roadblock."&he )uote summary page includes a simple bar chart. #%m using areport generator that%s supposed to generate bar charts, but the onlyway it will generate them is on pages by themsel(es. /e ha(e are)uirement from the sales group to put the te't and bar charts on thesame page. #%(e figured out that # can hack up a report with a bar chart

    by passing in the report te't as a legend to the bar-chart ob*ect. #t%sdefinitely a hack, but # can always go back and reimplement it morecleanly after the first release."

    Mike responded, "# don%t see where the issue is. /e ha(e to get theproduct out, and we don%t ha(e time to make the code perfect. $ill has

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    6/12

    made it crystal clear that there can%t be any more slips. @o the hack."

    hip reported that his communications code was ?=-percent done and

    that it worked, but he still had a few more tests to run. Mike caught 1illand &omas rolling their eyes, but he decided to ignore it.

    &he team worked hard through 3o(ember 2=, including workingalmost all the way through the nights of the 2th and 2=th, but they stilldidn%t make their 3o(ember 2= release date. &he team was e'hausted,

    but on the morning of the 24th, it was $ill who felt sick. Stacy hadcalled to tell him that de(elopment hadn%t released its feature-complete

    build the day before. 6ast week he had told the e'ecuti(e committee

    that the pro*ect was on track. Another pro*ect manager, laire, hadprobed into the team%s progress, saying that she had heard that theyweren%t making their scheduled releases to testing. $ill thought lairewas uptight, and he didn%t like her. He had assured her that his teamwas definitely on track to make their scheduled releases.

    $ill told Mike to get the team together, and when he did, they lookeddefeated. A month and a half of 4;-hour weeks had taken their toll.

    Mike asked what time today they would ha(e the build ready, but theonly response he got was silence. "/hat are you telling me0" he said."/e are going to ha(e the feature-complete build today, aren%t we0"

    "6ook, Mike," &omas said. "# can hand off my code today and call it%feature complete%, but #%(e probably got three weeks of cleanup work todo once # hand it off." Mike asked what &omas meant by "cleanup." "#ha(en%t gotten the company logo to show up on e(ery page, and #ha(en%t gotten the agent%s name and phone number to print on the

    bottom of e(ery page. #t%s little stuff like that. All of the important stuffworks fine. #%m ??-percent done."

    "#%m not e'actly 2;;-percent done either," 1ill admitted. "My old grouphas been calling me for technical support a lot, and #%(e been spendinga couple hours a day working for them. +lus, # had forgotten until *ust

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    7/12

    now that we were supposed to gi(e the agents the ability to put theirnames and phone numbers on the reports. # ha(en%t implemented thedialogs to input that data yet, and # still ha(e to do some of the other

    housekeeping dialogs too. # didn%t think we needed them to make our%feature complete% milestone."

    3ow Mike started to feel sick too. "#f #%m hearing what # think #%mhearing, you all are telling me that we%re three weeks away from ha(ingfeature complete software. #s that right0"

    "&hree weeks at least," 1ill said. &he rest of the de(elopers agreed.Mike went around the table one by one and asked the de(elopers if

    they could completely finish their assignments in three weeks. ne byone, the de(elopers said that if they worked hard, they thought theycould make it.

    6ater that day, after a long, uncomfortable discussion, Mike and $illagreed to slip the schedule three weeks to @ecember = as long as theteam promised to work 25 hour days instead of 2;. $ill said he neededto show his boss that he was holding the de(elopment team%s feet to the

    fire. &he re(ised schedule meant that they would ha(e to test the codeand train the field agents concurrently, but that was the only way theycould hope to release the software by 1anuary 2. Stacy complained thatthat wouldn%t gi(e A enough time to test the software, but $illo(erruled her.

    n @ecember =, the Giga-uote team handed off the feature-completeGiga-uote program to testing before noon and left work early to takea long-awaited break. &hey had worked almost constantly since

    September 2.

    &wo days later, Stacy released the first bug list, and all hell brokeloose. #n two days, the testing group had identified more than 5;;defects in the Giga-uote program including 58 that were classified as%Se(erity 2%-%Must Bi'%-errors. "# don%t see any way the software will be

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    8/12

    ready to release to the field agents by 1anuary 2," she said. "#t willprobably take the test group that long *ust to write the regression testcases for the defects we%(e already disco(ered, and we%re finding new

    defects e(ery hour."

    Mike called a staff meeting for eight o%clock the ne't morning. &hede(elopers were touchy. &hey said that although there were a fewserious problems, a lot of the reported bugs weren%t really bugs at all

    but were misinterpretations of how the program was supposed tooperate. &omas pointed to bug C28 as an e'ample. "&he test report for

    bug C28 says that on the )uote summary page, the bar chart isre)uired to be on the right side of the page rather than the left. &hat%shardly a Se(-2 error. &his is typical of the way that testing o(erreacts to

    problems."

    Mike distributed copies of the bug reports. He tasked the de(elopers tore(iew the bugs that testing had assigned to them and to estimate howmuch time it would take to fi' each one.

    /hen the team met again that afternoon, the news wasn%t good.

    "Dealistically, # would estimate that # ha(e two weeks% worth of work*ust to fi' the bugs that ha(e already been reported," Sue said. "+lus #still ha(e to finish the referential integrity checks in the database. #%(egot four weeks of work right, total."

    &omas had assigned bug C28 back to testing, changing its priorityfrom Se(-2 to Se(-8-"osmetic hange." &esting had responded thatGiga-uote%s summary reports had to match similar reports generated

    by the mainframe policy-renewal program, which were also similar to

    pre-printed marketing materials that the company had used for manyyears. &he company%s 4;; agents were accustomed to gi(ing their sales

    pitches with the bar chart on the right, and it had to stay on the right.&he bug stayed at Se(-2, and that created a problem.

    "Demember the hack # used to get the bar chart and the report to print

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    9/12

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    10/12

    about $ill%s ultimatum and asked for a ballpark estimate of when theycould release the product, first *ust in weeks, then in months. &he teamwas silent. 3o one would ha9ard a guess about when they might finally

    release the product. Mike didn%t know what to tell $ill.

    After the meeting, hip told Mike that he had accepted a contract witha different company that started Bebruary 8. Mike began to feel that itwould be a relief if the pro*ect were canceled.

    Mike got ip, the programmer who had been responsible for themainframe side of the +-to-mainframe communications, reassigned tohelp out on the pro*ect and assigned him to fi' bugs in the +

    communications code. After struggling with hip%s code for a week,ip reali9ed that it contained some deep conceptual flaws that meant itcould ne(er work. ip was forced to redesign and reimplement the +side of the +-to-mainframe communications link.

    As $ill rambled on at an e'ecuti(e meeting in the middle of Bebruary,laire finally decided that she had heard enough and called a "stopwork" on the Giga-uote program. She met with Mike on Briday. "&his

    pro*ect is out of control," she said. "# ha(en%t gotten a reliable scheduleestimate from $ill for months. &his was a si'-month pro*ect, and it%snow more than three months late with no end in sight. #%(e looked o(erthe bug statistics, and the team isn%t closing the gap. 7ou%re all workingsuch long hours that you%re not e(en making progress anymore. # wantyou all to take the weekend offF then # want you to de(elop a detailed,step-by-step report that includes e(erything-and # do mean everything-that remains to be done on that pro*ect. # don%t want you to force fit the

    pro*ect into an artificial schedule. #f it%s going to take another ninemonths, # want to know that. # want that report by end-of-work/ednesday. #t doesn%t ha(e to be fancy, but it does ha(e to becomplete."

    &he de(elopment team was glad to ha(e the weekend off, and theyattacked the detailed report with renewed energy the ne't week. #t was

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    11/12

    on laire%s desk /ednesday. She had the report re(iewed by harles, asoftware engineering consultant who also re(iewed the pro*ect%s bugstatistics. harles recommended that the team focus its efforts on a

    handful of error-prone modules, that it immediately institute design andcode re(iews for all bug fi'es, and that the team start working regularhours so that they could get an accurate measure of how much effortwas being e'pended on the pro*ect and how much would be needed tofinish.

    &hree weeks later, in the first week in March, the open-bug count hadticked down a notch for the first time. &eam morale had ticked up anotch, and based on the steady progress being made, the consultant

    pro*ected that the software could be deli(ered-fully tested and reliable-by May 2=. Since Giga Safe%s semi-annual rate increase would go intoeffect 1uly 2, laire set the official launch date for 1une 2.

    Post Mortem

    &he Giga-uote program was released to the field agents according toplan on 1une 2. Giga Safe%s field agents greeted it with a warm if

    somewhat skeptical reception.

    &he Giga Safe corporation showed its appreciation for the de(elopmentteam%s hard work by presenting each of the de(elopers with a 5=;

    bonus. A few weeks later, &omas asked for an e'tended lea(e ofabsence, and 1ill went to work for another company.

    &he final Giga-uote product was deli(ered in 28 months rather than4, a schedule o(errun of more than 2;; percent. &he de(eloper effort

    including o(ertime consisted of ?> staff-months, which was a 2E;-percent o(errun of the planned 84 staff-months.

    &he final product was determined to consist of about ;,;;; nonblank,noncomment lines of code in ::, which was about 88 percent morethan Mike%s seat-of-the-pants guess. As a product that was distributed

  • 8/11/2019 A Case Study in Classic Mistakes.doc

    12/12

    to 4;; in-house sites, Giga-uote was a hybrid between a businessproduct and a shrink-wrap product. A product of its si9e and typeshould normally ha(e been completed in 22.= months with E2 staff-

    months of effort. &he pro*ect had o(ershot both of those nominals.

    This material is Copyright 1996 by Steven C. McConnell. All Rights

    Reserved