I have been seeing a lot of comments like the following

"Of course, you're absolutely right! I guess if common sense were a prerequisite for being a competent programmer, we wouldn't be in the mess were in right now! "

and others that seek to blame the programmers for the coming Y2K mess.

Well, I would like you to consider that one of the main causes of the problem is lying managers. Consider the following:

Manager (to programmer): "How long will it take to do thus and such?"

Programmer (to manager): "Sixteen months, if nothing changes and we don't have anything else to do."

Manager (to his manager): "You say we have to do that this year? Sure, we can do that."

Manager (to programmer): "You have eight months. Now get it done."

And, of course the project comes in late and over budget. This is repeated enough times so that programmers are generally thought to be incompetent since they *never* get a project done on time.

Consider:

Programmer (to manager): "If we don't take the time to change the database now, in x years, in 2000, this software will stop working."

Manager (to programmer): "We can't afford it. It won't reflect on the bottom line. Forget it."

Manager (to his manager): "No, there are no problems on the horizon that I know of."

Consider:

Manager (to programmer): "I don't care if you need a bigger computer and more disk space. It's not in the budget. Make do with what you have."

Manager (to his manager, after his manager discovers Y2K): "That damn programming staff painted us into a corner. I think I'll retire."

Anyway, I ask you to consider that programmers are generally as competent and concerned as any other "worker bee". They may have been forced to take the responsibility, but they were never given the authority to get the job done correctly.

Please don't blame us for what we could not control. OK?

-- george Valentine (GeorgeValentine@usa.net), June 11, 1998

Answers

George, I made the comment that generated the above statement about common sense and I still stand by it. However, I do not disagree one bit with your statements. Having been a programmer and a project manager for too many years I have heard all of the above. My complaint is with the programmers that don't use any common sense with their coding. I have gone in a straightened up spaghetti code, illogical calls, calls that did nothing, calculations that were incorrect and this was in NEW code written by some whiz kid that the company swore was a genius. (Another complaint about some programmers is that they may be able to develop beautiful screens, but can't add 2+2 and get 4).

Sorry, I think my age is beginning to show. When I program, I want it to be right (calculate right and user-friendly) and easy to maintain and upgrade. I think I am a dying breed. Management wants it to be snazzy with wonderful bells & whistles, who cares if it can calculate a premium correctly, or capture data correctly or is user-friendly.

If I started in on management, you all would try to knock me off my soap box. Yes management is too short-sighted and sometimes just plain fools. It takes just as long to do something right as it does to do it half-a**ed and have to go back and fix it, but you can't tell management that up front. You tell a manager that Project A will take 6 weeks and he will say do it in 3, so it gets done in 3 and you spend the next 3 fixing things the users are yelling about that you didn't have time to do the first time around. Darn, there is that soap box.

-- Rebecca Kutcher (kutcher@pionet.net), June 11, 1998.

My take is that trying to pin blame onto a group of people for this mess is utterly useless. It's tyrants that need scapegoats, to deflect criticism from themselves.

Certainly its more of a management issue than a programmer one, in that its management who declined to do anything about the problem until too late.

But put yourself in a manager's shoes in, say, 1992. There's a recession. A programmer comes to you and tells you that you need to start spending megabucks on fixing programs just so they'll work in 2000. If you don't, he says you'll be out of business in 2000. You know that the company is having to cut things to the bone just to stay in business in 1993!

Put this way, the problem is seen to be systematic. If the fatal flaw of communism is that no-one can assume a gods-eye view of an economy and dictate what it should do, then the fatal flaw in capitalism may be that it encourages short-termism, because if you don't cut corners now someone else will, and you'll then be out of business. It's this short-termism that's caused this problem, and it's an intrinsic part of our system. In this sense, either nobody or everybody is to blame.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), June 12, 1998.

Apart from the very early space problem, there has been no excuse over the past 20 years for not writing date routines that will work indefinitely. It is no more time consuming than writing ones that will fail at a given point. It is ludicrous to cite political theory or blame managers. If sites had common compliant date routines that could be called by any module it would have obviated the need for progammers to invent their own. It seems that many programmers had a mental block as far as dates were concerned, not any more!

-- Richard Dale (rdale@figroup.co.uk), June 16, 1998.

Surely the problem is that programming/software development/call it what you will, is still am immature discipline. Compare the amount of quality assurance checking which is applied to the manufacture of something like an automobile or peice of electronic equipment, compared with that applied to the average program. Code is human. Humans make mistakes. I know - I have made 'em.

-- Dave Eales (deales@dircon.co.uk), June 16, 1998.

I agree that part of the problem in the software engineering industry is that it is still relatively immature. But managerial/marketing pressures are also enormous. I have been a software engineer for 11 years now and it is only recently that it has been *forced* on us to do a FMEA (Failure Modes and Effects Analysis) on each new product during the design phase. This procedure should identify and correct any Y2K problems before they get designed and hard-coded into a product. Frequently we software engineers know well what we are *supposed* to do but are railroaded into taking shortcuts. Now, with international standards such as ISO-9000 we can slow down our sales and marketing people and back up our refusals to cut corners with threats of violating ISO compliance. It helps enforce some badly needed discipline on the industry.

I don't know if that's an adequate excuse for poorly designed programs. Probably not, but it's reality.

-- David Palm (djpalm@compuserve.com), June 16, 1998.