There is no incentive for programmers to do 100% perfect repairs.greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
Programmers who do sloppy repairs are guaranteed with continued employment during 2000.
Programmers who make their computers Y2K compliant could be out of work in 2000.
99% of Programmers understand this. They are not stupid.
If you were a Programmer, would you work yourself out of a job?
This is why Y2K could be a 7 or up!
-- bbb (firstname.lastname@example.org), November 23, 1999
From my experience, it's only a small percentage of programmers who do this, and it's usually because they know that they're so obsolete that they won't be able to get a job anywhere else. Or it may be some kind of instinct to wreak revenge on an employer who has been telling them how "replaceable" they are.
Except in the extreme cases, it usually doesn't involve deliberately planting bugs, or leaving known bugs in the code. Usually, the behavior is much simpler: they simply refuse to document anything they've done, so that nobody else will be able to understand their work.
-- Ed Yourdon (email@example.com), November 23, 1999.
I still like to think that people are decent, and care about their fellow man, I myself do not hate programers the problem came before them and the ones you can hate (if u want) are dead. they are just trying to make a living like the rest of us... and we all got to make a living to pay our taxes
-- sandy (firstname.lastname@example.org), November 23, 1999.
It's generally my goal to program myself out of the job so I can go on to the next one. It's boring having to work on the same old software forever! Onward to a new challenge!
-- Sally Strackbein (email@example.com), November 23, 1999.
It pains me to say this (as a programmer), but *no* non-trivial application is *ever* 100% bug-free.
People like to rag on Microsoft for issuing series of service packs, but they forget that so does IBM, Sun (and every other Unix and Unix- like OS vendor), and every *other* company. The only time the service packs, patches, or whatever term they use for fixes *stop* is when the software is replaced by a newer version (and even then, SPs tend to be issued for older versions going back one or two releases for a while), or, the company goes belly up.
-- Ron Schwarz (firstname.lastname@example.org), November 23, 1999.
Hmmm, I am most definitely a lazy and overconfident programmer, but I've never, ever, deliberately left an error in a system, nor do I know a programmer (even the worst ones) who would do so.
What usually happens is that developers skip the "boring" bits, like design and testing, and that's where the errors creep in. I'm actually inclined to believe that Y2K fixes will be slightly BETTER in their design and testing than normal projects (85% late, 25% cancelled). But not 100%. And we need 100%.
-- Colin MacDonald (email@example.com), November 23, 1999.
-- br14 (firstname.lastname@example.org), November 23, 1999.
Every programmer I've known has done the very best job that they can.
Unfortunately, this is not good enough. That's why we have IV&V, QA, test teams, Alpha and Beta testing, help desks, discrepancy reports, fix paks, PTFs, 3.1 and 3.11 releases, etc.
The failure of Y2K projects will be due to the usual reasons that IT projects fail. Not enough time, cutting corners on staffing, changing priorities, etc.
If Y2K follows the trend of all past projects, we'll be 99% done until the very last moment (probably sometime in mid December). Then the story will change to 98% done, 97, 95, 90, 80, etc. In reality, the systems might be 50% done.
This might be enough to limp on or it might not be. I don't know, my specialty is coding, albeit in large complex systems. Ed Yourdon is probably the person who has the best understanding of large systems management, project scheduling, and life-cycle issues.
(note how distinguish what I know from what I don't know. This is very different from the Polly position.)
-- cory (kiyoinc@ibm.XOUT.net), November 23, 1999.
I have found fixing poorly structured code to be one of the most unpleasant and frustrating tasks I have ever experienced. Therefore I would consider the prospect of revisiting the code one has written, an incentive to be conscientious.
-- David L (email@example.com), November 23, 1999.
My apologies for the above "bbbbbbbullsh**". After reading Ed and Cory's post I realized that those who have not seen the "magic show" at 4 am just cannot comprehend how complex and interwoven these systems can be. It's an interesting but rare topic that many, MANY big DP shops included code for century processing (I have stacks of green bar to prove it) but it is difficult enough to mod/fix current processing logic much less worrying about time iterations.
As a programmer you do not have to create or "go look" for problems...they seek you out with a vengeance.
Once again, sorry for the sarcasm.
-- br14 (firstname.lastname@example.org), November 23, 1999.
I would never intentionally leave a bug in a system. What I want to hear from a user (and usually do) is that for years after I leave, my work needs no maintenance at all. I don't know of any programmer who would try for any less than that, but some are better than others.
What a stupid post.
-- bw (email@example.com), November 23, 1999.
I haven't met many programmers who would deliberately leave errors in their code, but I have met a few who were incompetent and sure wrote lousy programs.
As the time to finish ebbs away so will the confidence of the IT manager types. Programmers are usually going at warp speed trying to fit round pegs in square holes. After thirty plus years in the IT business I am still amazed that the management types still put up roadblocks faster than their workers can climb over them but expect a perfect (not really do-able) product done on a schedule that they (managers) usually have set well in advance without bothering to consult the programming staff.
Most programmers are doing their absolute (and unappreciated) best to finish on schedule and with the best possible product.
My hat is off to those people working to make this a BITR.
I don't think it will work that way however, as their task is just too big.
-- wally wallman (firstname.lastname@example.org), November 23, 1999.
From: Y2K, ` la Carte by Dancr (pic), near Monterey, California
This strikes me as an attempt to lay blame exactly where it doesn't belong. Not being an IT type myself, I can say this without fear of having taken the charge personally. The programmers who are working hard to undo the problem deserve all the support we can muster for them.
We should each find one to adopt and help them maximally in achieving their personal contingency preparations, so that they can focus all their energy where we need them to. Are their companies providing safe places for the programmers families to be well fed, kept healthy and safe from violence? I sincerely doubt it.
We who are almost as prepared as we are going to be, need to commit to helping to take care of the families of these valuable workers. The problem is, how do we go about doing this? They're reportedly working behind the scenes under a death march, while the window dressing everywhere says "we're all done already."
-- Dancr (email@example.com), November 23, 1999.
Why become frustrated with the chisel rather than the hand that wields it? Techs are techs (not, for the most part, malicious or lazy fellows). If finger pointing is in order, refer to many of the posts above: management creates undesirable and occasionally impossible situations to save a buck.
-- Mori-Nu (firstname.lastname@example.org), November 24, 1999.