I have been programing computers since 1974. Old systems CDC 1604, SDS, some IBM 360. In the 80's I moved to PC's and systems control. I have been involved in at least four major programing systems development teams. Each time the Marketing Department SOLD the system to the client well before it was finished, and in at least two cases we went to the wall, TOTAL Change over on Date=DELIVER DATE.

Both times we went down in flames, the IT managers had no idea how many bugs there were still in the system. In one case it was a year before we retried to provide the NEW substitute control system. Even Microsoft has project *creep* with the rollout being stated too soon for real debuging and completion of the project.

The question: How many Software Projects have YOU been involved with that came in ON TIME and UNDER BUDGET?

Y2K well its just OK with me.......NOT

-- Helium (Heliumavid@yahoo.com), December 04, 1999

Answers

But the polly refrain is: "The past doesn't matter! This time it's different! This time it REALLY COUNTS! This time all those lazy, good-for-nothing programmers will actually wake up and work hard!"

The corollary, I assume, is that nothing we did prior to Y2K really counted, and that past experiences matter for nothing, and that for the past thirty years we've been asleep on the job.

It should be noted that this refrain usually comes from pollies who wouldn't know a computer if they fell over one...

27 days to go...

Ed

-- Ed Yourdon (ed@yourdon.com), December 05, 1999.

I've also been at it since 1974. Started with an NCR 8200 (1st model with a CRT) programmed in extended basic...project had to be postponed for 9 months because we didn't complete during the customers slow season. We NEEDED the extra 9 months and still had a bear of a time for the first quarter. Next was a DG Nova running Cobol...that system was buggy it's entire life (5 yrs). The last was a Windoze system running FoxPro. It was a yr. late and after 5 yrs. the customer is convinced that a simple system written in business basic is SURELY more stable and easier to operate (doesn't know jack about computers but could understand the system he had 10 yrs. ago)...Last yr. got out of progrmaming entirely and started driving a truck. At least my boss now appreciates my work. Am fully prepared to become subsistance farmer after New Year's Evil.

-- Ace (Ace@nospam.com), December 04, 1999.

Helium --

Been at this, one way or another, over 30 years. In that time, I have been on two projects that were brought in on-time.

I have never been on, known anyone who was on, heard of, or known anyone who had ever heard of a software project that was brought in under budget.

-- just another (another@engineer.com), December 04, 1999.

Only 2. both were small, 2 programmer one analyst jobs. BOTH are running today, 20 years later, and BOTH are Y2K COMPLIANT because of a wet behind the ears analyst right out of B-school said "It's the only right way. Let's do it this way."

Of course we were in the County and it was a Juvie Court Tracking system and it was the second and third of 4 IT phases, so......

chuck

ALL of the BIG ones were 6-18 months late and WAY over budget. BTW the JCourt project came in EXACTLY on a 5% over budget benchmark (grant money- can't give it back, make sure you spend every nickel type of stuff)

-- Chuck, a night driver (rienzoo@en.com), December 04, 1999.

Been a programmer for 20 years. Projects finished on time and under budget: Zero. Projects finished error free: Zero. It just doesn't work that way.

-- A Programmer (notmy@address.com), December 05, 1999.

I don't know much about computers (barely qualify as an intermediate user), but, as I remarked to my wife the other day, after spending yet another weekend, morning till dark, finishing up a barn for my new critters:

Just ONCE, I want to have a project take only twice as long as I think it will, and cost no more than twice what I expect.

It ain't just computers, folks.

-- mushroom (mushroom_bs_too_long@yahoo.com), December 05, 1999.

I've been a programmer for 30 years. Out of the many dozens of projects I've worked on, a handful came out on schedule and on budget. The rest were late, some very late ... except for the ones that were cancelled.

-- Steve Heller (stheller@koyote.com), December 05, 1999.

I don't know much about budgets. Even though I've been in this business for 31+ years, I've always tried to avoid management issues. I like pushing bits too much to get involved with politics. Yes, I'm sure it has cost me some money, but you can be sure that I am much happier than I would be, if I went the PHM route.

But as for late, yup, just about every project that I've ever worked on was late. It wasn't due to a lack of effort on the programmers' part. There have been times when I spent days in the office, at it for 18 hours, catch a few on the office couch or floor, then up and at it again for another 18. It's a funny feeling when you open your eyes, and see the guy from next office laying next to you, instead of your girlfriend.

It's always something. Design problems, bugs, last minute changes, you name it. It's the nature of the beast. It's the nature of Murphy.

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), December 05, 1999.

Been programming since the early 80's and I too have only had a handful of projects come in on time. With one standout exception (and great manager), the fewer programmers working on the project the closer it was to the mark. It works that way for private companies, and it works that way for the Government.

NOTICE: The non-techies out there should understand that this is NOT NOT NOT the programmers fault. It is a RARE project where the programmers get to schedule deadlines and/or have the final say as to when it is/isn't "Done". Mostly R&D stuff and never mission critical.

The way it works 99.9% of the time is management decides what seems like a reasonable (to them) time-frame to complete a project and then work backwards from there to schedule deliverable dates, milestones, etc. All the while they are ramping up the marketing machine and the pressure to deliver builds and builds.

It doesn't matter how complex the project is or even if the technology to implement it exists yet (yes, I've worked on projects like that). They say be done by X date and they fully expect you will make it so. And when, despite working round the clock, not seeing your family for days on end, living on pizza, chinese food and sleeping on the floor next your desk, you miss the deadline, it's your fault for being 'late'.

SET SARCASM ON I have faith that the Government with it's armies of top-notch programmers, in conjunction with private industry, have fixed all Y2K errors to the extent that such errors will not cause severe disruptions to our daily lives or the economy. I believe this to be true in the US as well as the rest of the World. SET SARCASM OFF

You know, it's conversations like this that make me wonder if I have enough food stored....

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), December 05, 1999.

Out of eight major projects in a fifteen year career, two came in on time and on budget. Those two were ramrodded by a superman-type project manager who split the deliverables into manageable phases, negotiated reasonable requirements and deadlines with the customers, and who also had amazing mental radar that could spot emerging issues and problems long before they could threaten his projects.

This person was a civil engineer by profession, not a code jockey, and had experience managing large civil infrastructure projects before getting into the software development arena. He had no reservations about standing toe-to-toe with those customers or corporate managers who questioned his approach in getting his projects completed on time and on budget. But after he was hired away by a competing firm, it was back to business as usual.

-- ExBigSkyGuy (Not.There@NoMore.com), December 05, 1999.

It's not always as simple as coming in under budget and on time unfortunately.......

Under budget......how much of the budget goes to pay pointy-haired managers that know sweet bugger all about programming?

Not to mention all the projects that are going well and on time and then the upper management call and say something like......."Can you get it to do this and look like that and add this for me and by the way we need to be able to interface with these additional databases.............ad nauseum.

What's the point of getting ahead of the game......the moment you tell the chiefs you're ahead then they require massive changes in the scope of the project.

-- Craig (craig@ccinet.ab.ca), December 05, 1999.

none, never, not even close!

-- ron wiebe (ron_wiebe@bc.sympatico.ca), December 05, 1999.

Just a little 3am humor. We manufacture programmable parts feeder systems. Hubby designs and programs the mini computers, I build them. After 15 yrs in business we finally sent out three machines to a company ON TIME! The only time we were ever on time. Gee, were we feeling pleased. The darn company went bankrupt two weeks later. Pam.

-- Pamela (jpjgood@penn.com), December 05, 1999.

I've worked on both the years-late, 3X over budget as well as the ahead of schedule types of projects.

Ahead of schedule types have been the smaller efforts, where I know more about the requirements than anyone else and have been able to build in contingency reserves, 30% more funding, 50% more time, than any one else would allow.

But then I started programming in 1969 and have seen a wide variety of efforts, some have flamed out, some were cancelled, some ran hundreds of millions of dollars over budget.

Like Ed Y., Steve H., and the others above, I've seen enough to know that very few made "December 31, 1998 with a full year for testing."

Good luck everyone!

-- cory (kiyoinc@ibm.XOUT.net), December 05, 1999.

I am proud to say that my "Hello World!" program was delivered on time, under budget and 100% error free! It's been a long road down hill since then...

-- Chris Tisone (c_tisone@hotmail.com), December 05, 1999.

my "Hello World!" program

Would that be being born?

-- Dancr (addy.available@my.webpage), December 05, 1999.

Ed,

Whereas you are correct that a lot of "optimistic" individuals post statements (regarding software remediation) without the benefit of having many years experience - the same could be said of the other "camp". In fact, this begs the question regarding statments made within your book - how many years have you spent designing/remediating the hardware and software associated with telecom systems, System On Chip (SOC) or Power Systems. If one is going to make bold statements regarding the ability of any particular industry than those individuals should have a minimum level of experience. With that said, I can recommend several good books that have served me well during the 15 years spent as a Electrical Engineer in the aforementioned fields:

Modern Control Theory - William L. Brogan Discrete Time Control Systems - Katsuhiko Ogata

Microcomputer Systems Design - Liu & Gibson The Art of Programming Embedded Systems - Jack Ganssle Principles of VLSI Design - Weste & Eshraghian

Power Plant System Design - Li & Priddy Power Electronics - Muhammad Rashid

Voice Teletraffic System Engineering - Boucher Management of Telecommunication Systems & Services - Jane Hall (ed)

Data Transportation & Protection - Hershey & Yarlagada

Regards,

-- joe thomas (joe_thomas3@hotmail.com), December 05, 1999.

From the great Tao of Programming, section 3.4...

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: "How long will it take to design this system if I assign five programmers to it?"

"It will take one year," said the master promptly.

"But we need this system immediately or even sooner! How long will it take it I assign ten programmers to it?"

The master programmer frowned. "In that case, it will take two years."

"And what if I assign a hundred programmers to it?"

The master programmer shrugged. "Then the design will never be completed," he said.

...

And from section 5.2...

A manager asked a programmer how long it would take him to finish the program on which he was working. "I will be finished tomorrow," the programmer promptly replied.

"I think you are being unrealistic," said the manager. "Truthfully, how long will it take?"

The programmer thought for a moment. "I have some features that I wish to add. This will take at least two weeks," he finally said.

"Even that is too much to expect," insisted the manager, "I will be satisfied if you simply tell me when the program is complete."

The programmer agreed to this.

Several years slated, the manager retired. On the way to his retirement lunch, he discovered the programmer asleep at his terminal. He had been programming all night.

...

Become one with the Tao. http://www.assert.ee/~toomas/tao-of-p.txt

O d d O n e, who exists within the Tao...

-- OddOne (mocklamer_1999@yahoo.com), December 05, 1999.

I have experience as a "customer" of a software projects rather than a team member:

One recent medium size software project:

After six months I was making bets with the software project leader on what YEAR the project would be completed ! The "about one year" project actually took about 2 1/2 years and failed to deliver all planned functionality (I guess that should be assumed with all software projects). The strange thing was this software project did not seem that unusual to the people working on it!

-- Richard Greene (rgreene2@ford.com), December 05, 1999.

The projects I've been involved in that came in on time were the one's where the delivery date was set when we knew when we'd be finished. The ones that were late was when the date was set by other means. Like when someone thought it should be done.

Since 1/1/00 is a fixed date, those projects started sufficiently early have a good chance of finishing on time

-- gary (a@a.com), December 05, 1999.

I've had a few software/hardware companies. We did application software for Mac's and PC's...nothing remotely like the complexities of "big iron."

Even so...everything took far, far longer than we guessed and hoped it would. I well remember one summer when nobody in my small company took paychecks, because we "weren't done". Not fun. I almost lost my home that year...

Making software is a hard, long, often ugly process. Debugging is much worse, and takes longer. It's never done, actually. Everyday, we all use software that has (as they say now) "known issues". We used to call them "bugs," now they're "known issues."

Still, given that, it's a joy to make great code...though few people do. It's amazing that your cab driver needs a license, but no programmer in the world does...yet their efforts run the world.

I think "known issues" will soon be much more widely known.

-- joe (joe@adeveloper.net), December 05, 1999.

Zero, Never.

And the great thing was, it never mattered because there was ALWAYS more time (and we could continue using earlier versions) and ALMOST ALWAYS more money.

Non-techies reading this might thing, "either you guys are incompetent or dishonest." No. The truth is, doing good software is hard, and doing good software within the context of perfectly legitimately shifting business, customer and technical requirements is extraordinarily hard.

Maintenance projects also come in late and over-budget.

-- BigDog (BigDog@duffer.com), December 05, 1999.

I started in IT at a time when nearly everything was a new application; no development tools, no COTS, no DBs - it was manual procedure to computer processing. Maybe there were budgets - I never heard of any in regards to an IT function until the 1970's.

Projections of successful completion were always made based on having the "right people": 6 IBM/360 BAL programmer analysts, 1 good 360/OS systems programmer, and 2 systems analysts who could actually translate what the user wanted into detailed specs. If the above, then six months and six months salaries.

But what you got were: 2 rookie COBOL programmers who wanted to learn 360 BAL, 1 failed Honeywell Easycoder programmer who spoke in octal, all three hired because they could name the four sections of a COBOL program - not because they might have applications experience; the phone number of IBM's operating systems support engineer; and a newly minted "B school" grad who wanted to "pass through" information systems on his way to the executive suite but whose knowledge of computers, people or developing specs that someone might code from was below zero.

How could you bring in a project with those "resources", much less "on time and within budget"? Results were Eighteen months of wheel spinning and then cancel.

Now to my answer to the question.

Four and None, with an explanation .

By the time I reached a new life as a consultant I had learned that the only way to win when making software projects come in on time and on budget was to exert maximum change control once you progressed beyond the Scope and General Specifications phase. As with any business deal the devil in is the details (of the contract).

I ran "fixed price" software projects for the banking and insurance industry in New York in the 1980's. I was successful. I closely managed the client's activity or lack thereof, had well written contracts, and a bonus incentive. Every change or delay was documented and paid for in both money and time so that projects came in "on time and under budget". Thus making up for the "right people" being pulled off and sent to projects with higher rates .

HOWEVER, all the change management techniques, hardhearted accountants or ironclad contracts will not be able to "extend the deadline" for Y2k. Documentation and then testing are cast aside in the mad race to the edge of the precipice. But maybe this time it will be different?

warm regards from sunny Miami (home of e-commerce) Steve Krulin editor, Computer Law Journal

-- Steve Krulin (editor@tropic-lawyer.com), December 05, 1999.

When I've tested the ones that were "delivered" on-time, they failed. When (eventually) repaired to the client's satisfaction, most ran almost as good as originally advertised.

The only ones that worked correctly (when delivered) had no scheduled date to be missed, I had been using them myself and working on them to remove bugs for as much as two years before anybody else ordered them delivered, and so had plenty of time to work all the bugs out.

Any program, given an infinite budget and and an infinite schedule, can be delivered defect-free the first time. All others require more testing and a longer dellivery schedule.

-- Robert A. Cook, PE (Marietta, GA) (cook.r@csaatl.com), December 06, 1999.

When I've tested the ones that were "delivered" on-time, they failed. When (eventually) repaired to the client's satisfaction, most ran almost as good as originally advertised.

The only ones that worked correctly (when delivered) had no scheduled date to be missed, I had been using them myself and working on them to remove bugs for as much as two years before anybody else ordered them delivered, and so had plenty of time to work all the bugs out.

Any program, given an infinite budget and and an infinite schedule, can be delivered defect-free the first time. All others require more testing and a longer delivery schedule.

-- Robert A. Cook, PE (Marietta, GA) (cook.r@csaatl.com), December 06, 1999.

From: Y2K, ` la Carte by Dancr (pic), near Monterey, California

It's amazing that your cab driver needs a license, but no programmer in the world does...yet their efforts run the world.

Why certification is a bad idea...

-- Dancr (addy.available@my.webpage), December 06, 1999.

I've been a Systems Programmer for 31 years, mainly working for IBM (I was one of the original developers of CICS). The answer to the question is simple: NONE.

And here's a little story (which actually happened):

DAY 1 of Project - Project Manager to Programmers: "please estimate the cost of implementing this system".

(Programmers go into huddle for a while)

Sometime later - Programmers to Project Manager: "100,000 lines of code!"

Project Manager: "Good! Start coding right away!"

Weekly status meeting - Project Manager to Programmers: "How many lines of code did you write this week?"

Programmers: "Errr... N lines of code"

Project Manager: "Excellent! I'll add N to my cumulative total"

(and then one day ..)

Project Manager: "... REALLY excellent! that now adds up to 100,000! So the product is complete!"

Programmers: "Errr... well, no, it doesn't actually work yet..."

Shortly afterwards: Project cancelled.

-- Risteard Mac Thomais (uachtaran@ireland.com), December 06, 1999.