Flashback to the 1980s, when computer-aided software engineering methodologies are all the rage for major mainframe software projects, according to a pilot fish in the know."A friend of mine was a software developer at a big Chicago bank, and they were very big into CASE for large projects." fish says. "Both the bank's management and the developers were pretty happy with the results for its mainframe work."Or they were happy with the software they produced, anyway. But big CASE tools didn't solve all the system development problems. On one particular project, my friend gave me a running update over the last few months of the project's schedule."At first, things are running pretty much running as expected. Then, like most projects, the schedule begins to slip. Fish hears more about unexpected bad news from his friend than it seems like a healthy project should have. And as it gets closer and closer to the completion date, it's looking more and more iffy as to whether everything will be coded and tested on time.No big deal, fish tells his friend -- software schedules slip all the time. But fish doesn't work at a big bank, and she promptly corrects his optimistic assumption: That completion date is set in stone."I knew the deadline was coming up, and didn't see my friend for a month," says fish. "Last word I got was that it was going to be very tough to get it done on time, but management wasn't showing any signs of letting the release date be delayed."When he sees his friend next, his first question is "Did you get it finished?" No, she tells him."So they delayed it?"No, they wouldn't let us do that either, she says."Then what--?"Turns out that, on the deadline day, they officially announced that the software was done. Everyone, from management on down, knew it wasn't. No one could actually use the system. But development was officially finished."Then the programmers immediately began work on a maintenance release," fish says. "That was supposed to be for relatively minor fixes. In this case, the most important 'minor fix' was getting the software to actually run the way it was supposed to."And few months later, that's what version 1.1 did."Sharky really needs your stories, whether they're major or minor. So send me your true tale of IT life at Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!. You'll get a stylish Shark shirt if I use it. Comment on today's tale at Sharky's Google+ community, and read thousands of great old tales in the Sharkives. Get Sharky's outtakes from the IT Theater of the Absurd delivered directly to your Inbox. Subscribe now to the Daily Shark Newsletter.
Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.
Flashback to the 1980s, when computer-aided software engineering methodologies are all the rage for major mainframe software projects, according to a pilot fish in the know."A friend of mine was a software developer at a big Chicago bank, and they were very big into CASE for large projects." fish says. "Both the bank's management and the developers were pretty happy with the results for its mainframe work."Or they were happy with the software they produced, anyway. But big CASE tools didn't solve all the system development problems. On one particular project, my friend gave me a running update over the last few months of the project's schedule."At first, things are running pretty much running as expected. Then, like most projects, the schedule begins to slip. Fish hears more about unexpected bad news from his friend than it seems like a healthy project should have. And as it gets closer and closer to the completion date, it's looking more and more iffy as to whether everything will be coded and tested on time.No big deal, fish tells his friend -- software schedules slip all the time. But fish doesn't work at a big bank, and she promptly corrects his optimistic assumption: That completion date is set in stone."I knew the deadline was coming up, and didn't see my friend for a month," says fish. "Last word I got was that it was going to be very tough to get it done on time, but management wasn't showing any signs of letting the release date be delayed."When he sees his friend next, his first question is "Did you get it finished?" No, she tells him."So they delayed it?"No, they wouldn't let us do that either, she says."Then what--?"Turns out that, on the deadline day, they officially announced that the software was done. Everyone, from management on down, knew it wasn't. No one could actually use the system. But development was officially finished."Then the programmers immediately began work on a maintenance release," fish says. "That was supposed to be for relatively minor fixes. In this case, the most important 'minor fix' was getting the software to actually run the way it was supposed to."And few months later, that's what version 1.1 did."Sharky really needs your stories, whether they're major or minor. So send me your true tale of IT life at Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!. You'll get a stylish Shark shirt if I use it. Comment on today's tale at Sharky's Google+ community, and read thousands of great old tales in the Sharkives. Get Sharky's outtakes from the IT Theater of the Absurd delivered directly to your Inbox. Subscribe now to the Daily Shark Newsletter.