You better not.

Shark Tank: Betcha they got penalized for being late, too

Software development company wins bid to write a new system for a federal agency.

Requirements document is drawn up and approved, and a six-month development schedule is agreed on by all parties.

"At the three-month point, the customer advises that they need the system in one month," says a pilot fish on the development team.

That wasn't the agreement, but fish's team looks for ways to meet the new deadline. "We re-evaluate the shortcomings and advise that certain functionality will not be available due to limited development time," he says.

Agency agrees.

Fish and team shred the original schedule, work day and night, and manage to test and deliver the software two months earlier than originally planned.

The agency performs its evaluation on the system and reports back that the software is unacceptable. The reason: It's missing functionality.

Which functionality? The items that the agency agreed to give up to meet the compressed schedule.

"We continue development and finish the system two weeks late," reports the fish. Which is exactly the time the team lost scrambling to get the software done early.

Copyright 2001 Computerworld Inc.

-- Anonymous, July 06, 2001

Answers

Never step on somebody elses Dilbert. We all got 'em.

-- Anonymous, July 07, 2001

Projects involving software builds involve Humans who work as "craftsmen" vs. production line clones.

Most of the money in consulting is made around the mysteries of "programming" which allows for tons of "fudging" on time and deliverables. Since few can dictate how the "craftsmen" working in the electronic pre-industrial age Cottages will work with any sort of granularity, all kinds of FAT can be built into "The Project".
Funny but the above makes the point for Bruce Eckels. From his "Thinking in Java" (2nd Ed.) Preface.

Programming is about managing complexity: the complexity of the problem you want to solve, laid upon the complexity of the machine in which it is solved. Because of this complexity, most of our programming projects fail. And yet, of all the programming languages of which I am aware, none of them have gone all-out and decided that their main design goal would be to conquer the complexity of developing and maintaining programs[1]. Of course, many language design decisions were made with complexity in mind, but at some point there were always some other issues that were considered essential to be added into the mix. Inevitably, those other issues are what cause programmers to eventually “hit the wall” with that language. For example, C++ had to be backwards-compatible with C (to allow easy migration for C programmers), as well as efficient. Those are both very useful goals and account for much of the success of C++, but they also expose extra complexity that prevents some projects from being finished (certainly, you can blame programmers and management, but if a language can help by catching your mistakes, why shouldn’t it?). As another example, Visual Basic (VB) was tied to BASIC, which wasn’t really designed to be an extensible language, so all the extensions piled upon VB have produced some truly horrible and unmaintainable syntax. Perl is backwards-compatible with Awk, Sed, Grep, and other Unix tools it was meant to replace, and as a result is often accused of producing “write-only code” (that is, after a few months you can’t read it). On the other hand, C++, VB, Perl, and other languages like Smalltalk had some of their design efforts focused on the issue of complexity and as a result are remarkably successful in solving certain types of problems. [ Add Comment ]

-- Anonymous, July 07, 2001

It must be me.

-- Anonymous, July 07, 2001

Trish,

Been there and done that, believe me. :)

(The problem I had was that they kept changing the spec and couldn't decide on standards ... then got mad when the thing took ten times as long.[g])

-- Anonymous, July 08, 2001

Maybe I should have added that I'm going through something very similar at work right now, which of COURSE made it even funnier to me. Our "spec" changes, well, almost hourly. So you've worked on Section 2 for a week, but Someone In Management forgot to tell you that it changed six days ago.

Oops.

I guess the basis isn't really funny, but you have to laugh else you'd be completely postal.

Like you said, been there, done that; DESIGNED the T-shirt.

-- Anonymous, July 08, 2001

Trish,

But by far, the worst are the Type A, kill-'em-all marketing types who don't understand how long it takes to write good software.

I actually had one of these people tell me that he expected me and three other programmers to produce an entire anti-virus scanner package -- from scratch -- in three months.

(Truly from scratch. We were migrating from Borland's OWL to Microsoft's MFC, too.)

Oh, and he also insisted that we include a resident virus "shield" along with the scanner. Including macro viruses. Including the ability to patch into the WinSock and watch for malware coming down the line. Even if it was zipped or encrypted.

Plus, it had to be faster AND more accurate that anyone else's.

I told him it might take a *WEE* bit longer than that. :)

-- Anonymous, July 09, 2001

...or even worse, have TPTB decide that the "line" programmers who've been there for years and know the legacy systems inside and out suddenly do not move "fast enough" for the customers that want their latest "Hey wouldn't it be neat if we could..." project in 6 month. vs. 12-18 months.

Don't wanna give your programmers raises? No problem - just wave a wand and make 'em all maintenance programmers (lowest rung on the IT ladder). Then, to add insult to injury, announce that you will no longer build systems from the ground up. NOW we're gonna buy vanilla, off-the-shelf packages...oh yeah, and hire consultants at 3x the programmer's salary to "customize" it to our specs.

-- Anonymous, July 17, 2001