Software Development

California's COBOL crisis demonstrates the danger of duct-tape IT

California's Controller said it would take six months or more to reprogram their COBOL-based payroll system to issue minimum-wage checks to state workers, as planned by Governor Arnold Schwarzenegger. Replacing a massive system like California's is expensive, but keeping a dying system on life support can be catastrophic.

California's Controller said it would take six months or more to reprogram their COBOL-based payroll system to issue minimum-wage checks to state workers, as planned by Governor Arnold Schwarzenegger. Replacing a massive system like California's is expensive, but keeping a dying system on life support can be catastrophic.

-------------------------------------------------------------------------------------------------------------------

Forget Sarah Connor or the T-1000, the Terminator is facing a far more tenacious adversary these days--COBOL. California's Republican Governor Arnold Schwarzenegger wants to issue minimum-wage checks to 200,000 state workers by the end of August. But according to The Sacramento Bee, Democratic state Controller John Chiang said the state would need at least six months to reprogram California's COBOL-based payroll system to issue the minimum-wage checks.

Pushing IT beyond its limit

Chiang's reluctance to implement Schwarzenegger's plan may be more political than technical. But, there's no denying that California's reliance on a decades-old payroll system has turned a bureaucratic problem into a technical crisis. California's not alone in this quandary. A great many businesses and large government agencies rely on archaic systems for daily operation. Why? Money and institutional inertia.

In describing the situation to The Sacramento Bee, Michael Cohen, director of state administration with the Legislative Analyst's Office, said:

It's an example of a number of computer systems in which the state made a large investment decades ago and has been keeping it going the last few years with duct tape.

When organizations make large capital investments, they want the assets to last as long as possible--whether it's a new building or a network infrastructure. But, pushing systems too far past their intended lifespan has several negative consequences: increased risk of catastrophic failure, increased maintenance costs, increased incompatibility with newer systems, and significant inefficiency. Just read what writers for The Union-Tribune uncovered about San Diego's antiquated IT system.

Change can be costly but is necessary

Some argue that sticking with existing systems, even when they're held together with duct-tape, can have advantages over a new deployment. In his InfoWorld.com blog post on the California COBOL situation, Neil McAllister posits that the complexities and costs of replacing California's payroll system may outweigh the costs of keeping the current system. McAllister sites an IDC study that examined the cost of developing and deploying in-house software. Interpreting the report, McAllister wrote:

It turns out that it isn't the applications that are growing more complex, but the technologies themselves. Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs, says IDC. In other words, new code is more expensive than old code. The more you take advantage of today's hot new technologies, the more likely you are to experience development delays and software defects.

I have first-hand experience with large, expensive software development and deployment project--from both an IT and end-user perspective. I've seen ill-conceived and poorly managed projects run months past their completion date and thousands over budget. But, I've also seen the opposite. Just because developing and deploying a new system might be difficult, complex, and even more expensive than maintaining the status quo, sometimes it's necessary. Consider the technological advances in automobiles over the past 50 years. Are modern cars more complex and more expensive to purchase and maintain than Ford's Model T? Yes. But, today's autos are safer, more comfortable, and more functional.

The bottom line for IT leaders

IT executives cannot ignore the substantial risks associated with pushing IT systems too far beyond their intended lifecycle. Nor should IT hold onto out-dated and dysfunctional systems because deploying a new system would be difficult or expensive. As California's COBOL quandary demonstrates, duct-tape IT can turn a simple request into a technical crisis.

About

Bill Detwiler is Managing Editor of TechRepublic and Tech Pro Research and the host of Cracking Open, CNET and TechRepublic's popular online show. Prior to joining TechRepublic in 2000, Bill was an IT manager, database administrator, and desktop supp...

54 comments
stso9daa
stso9daa

it wouldn't matter what it was coded in if this kind of change was mandated!!!!!!!!!!!!!!!!!!!!!!!!! it is just a stupid mandate from the terminiator. Bill - you really missed this one... If it was written in .net, it would still be stupid! the investment in COBOL has provided returns for 30+ years... i think that says volumes about a good product that served well. it shouldn't be slammed for it... COBOL remains because it cost too much to rewrite some of these systems at todays salaries and mountains of requirements piled on because of the latest architechures - .net, oracle, etc. (NO SAP - NO WAY!!!!!!!;) COBOL will still be around after you and I are long gone... ;)

dbecker
dbecker

COBOL was originally touted to be the end all language ordinary businessmen could program to get what they wanted. Let Arnold change the programs: Saves lots of money on minimum wage contractors [and just where will anyone find COBOL contract programmers at minimum wage, do pray tell?].

dbecker
dbecker

How well duct tape worked for MacGuyver, even at SG-1.

dbecker
dbecker

In complete defiance of our policies, our network engineer made ageist remarks in a meeting in front of a manager, "The old people just don't understand". Oh, but we do. COBOL has brought stability to Budget and Finance and Payroll / Personnel. It is absolutely reliable. All the other spiffydo systems written in such things as that most modern of platforms, PowerBuilder and Sybase [the new legacy tools], not so much. This is the network engineer who brought down the network through his own incompetence five times in the last year during the middle of the day. And we've had the chance to tell him: "You are too young to understand". To understand reliability, stability and predictability. If there is an error in code [which happens extremely infrequently], we know exactly where to fix it within minutes as opposed to weeks looking for the failure in GUI based systems. And response time? Did we mention response time? Entering time card entries is a snap, unless you use the PowerBuilder version which may take as long as 30 seconds [down from six minutes] to do a SQL call. But have you looked at COBOL lately? You know, the Object Oriented COBOL with the CLASS-ID paragraph for defining a class, Factory definitions and Object definitions, all seamlessly integrated with Java. Throw in the XML COBOL standards with the dlls in Unix and you have something... quite beyond the simple minded youngsters, particularly when the code is mulithreaded. DO NOT TRY THIS AT HOME! Or go ahead. Sourceforge has done a rather spiffy job on the Open COBOL compiler. You can get it working with POSTGRESQL if you like. And if you like the pure efficiency of calling Assembly Language routines addressing 64 bit addressing, then have a look see at: http://a64z.net/ BTW, here's an amazing concept: POSTGRESQL on the IBM Mainframe. Looked at that yesterday. If someone like me makes it work, what do you suppose the vendor do with its commercial database when people find a free alternative? As for the Governor of California: After this fiasco, he might not be back.

tungstendiadem
tungstendiadem

Why not implement a new system specifically for the unaddressed capacity in the existing system? Writing a system specifically for payrolling the personnel not included in the existing system, seems like a more rational act than revamping the statewide payroll system for the exceptional case. It's not as if text output and input are going to be impossible to use.

mikifinaz1
mikifinaz1

If the American people realized all the graft, corruption, sloth and stupidity they are paying for there would be government officials hanging from telephone poles from Cap Code to San Francisco. I know I worked in government, until my friends did an intervention on me.

bernalillo
bernalillo

One way to limit the impact created by duct tape systems is to not creat them in the 1st place. The never ending call for immediate implementation of someones new pet project would help alot. Does this system really have a good ROI? Cany we do this better with stuff we have now and some training? Another point, Ok, then lets extablish a trust to be funded every year for it's planned life cycyle so that we have the money to replace it when the time comes. The longer past it's designed life span you go, the more money there is to address it's replacement. A decsision to defund the trust makes a public statement regarding the non essential nature of the system and lets IT off the proverbial hook. (This would also be very fun to watch.)

wdewey@cityofsalem.net
wdewey@cityofsalem.net

I think that PC's could be compared to autos and that massive processing systems should be compared to airplanes (auto's are cheap and easily interchangeable, airplanes are expensive and service large amounts of people). Often new technologies are put into old air frames because it is cheaper and easier than building a new airframe from scratch. I don't personally agree that a system should be replace just to take advantage of new technologies. I think a system should be replace when it can no longer handle the load it is expected to carry in a cost effective manner. Bill

Tony Hopkinson
Tony Hopkinson

Why would changing somebody's pay rate take six months? My BS filters are on turbo here. Either someone is lying their arse off, or it wouldn't matter what language the program was written in or what technology it ran on, because it was designed by a complete nipplehead.

HypnoToad
HypnoToad

Cheaper to stick with something that works, than to upgrade, go through heck in a handbasket to New Jersey and back and still have hiccups afterward... after all, that's why we still drive automobiles. The cost to dump them for something else isn't cheap either. Darned if you do and darned if you don't. I'll refrain from incorporating politics into my comment. No doubt others will be more than happy to comment on that. :D

Bill Detwiler
Bill Detwiler

California's Controller said it would take six months or more to reprogram their COBOL-based payroll system to issue minimum-wage checks to state workers, as planned by Governor Arnold Schwarzenegger. In an IT Dojo blog post, I use California's COBOL crisis to illustrate the negative consequences of keeping a dying system on life support too far past its intended lifespan. Original blog post: http://blogs.techrepublic.com.com/itdojo/?p=165 Are you currently supporting systems that should have been retired a decade ago? If so, is supporting these outdated systems taking IT resources away from other projects? If you've convinced upper management to replace an outdated system, how did you make your case?

HanksComputer
HanksComputer

Another solution would be for the Payroll people to compute the payroll as always but not print the checks or update the employee records with year to date information. This would provide a payroll transaction file for all employees being pay this pay period. Then have IT develop two programs to work from this transaction file of information. Program # 1: Develop a program that processes this information and computes a modified net amount as the Governor wanted and post the result as a deduction from the original check. Three routines would be needed 1) Compute the net amount using minimum wage as pay rate. 2) Post the modified net amount to the transaction record as a deduction for this pay period 3) Print a check with this modified net amount for each employee \ Program # 2 (These program should already exist in the current payroll system.) When the budget is approved print a second check with the full deduction/reduction showing (including the deduction for the first check), taxes and the modified net for the employee. This program would also update the employees payroll records for year-to-date tax reporting, etc. An employer I worked for years ago did this for our semi-monthly payroll. The employer divided the net by 2 and wrote a check only for the amount for the mid month pay period. The end of month check had all the taxes, deduction and reductions on it; this included the amount of the first check as a deduction.

jmgarvin
jmgarvin

Here is hello world in Cobol: IDENTIFICATION DIVISION. PROGRAM-ID. HELLO-WORLD. ENVIRONMENT DIVISION. DATA DIVISION. PROCEDURE DIVISION. MAIN. DISPLAY 'Hello, world.'. STOP RUN. Let's check it out in C: main() { printf ("Hello, world.\n"); } How about Perl: print "Hello, world.\n" How the hell is Cobol less prone to error?

Locrian_Lyric
Locrian_Lyric

The kiddies are at the point where they can't even edit a web page without an editor.

kclark
kclark

Well stated. Well put. But there must be more to this story. There must be more than just adding a lower limit to the Wage_Rate line!! Must be more that has been passed along.

TonytheTiger
TonytheTiger

They're the government... they make stuff up to further the need for their existence... to make a niche for themselves... It's the "If I create it, they'll NEED me around to fix it" mentality. Pay rates change all the time. If there really was a problem, it would have been fixed decades ago.

Tony Hopkinson
Tony Hopkinson

impossible not to use duct tape when building an IT system. The trick is to remeber where you did, and use high quality duct tape, not that cheap crap that frays under a bit of strain.

rhomp2002
rhomp2002

I agree. If it took 6 months to change a pay rate, then it would not matter what the system was written in, they would take 6 months any way you cut it. Actually all you would need to do is go to the payrate and do a global change. You could do that with a very quick and easy program. As to the other comment about a dying system, I have had experience with that one when they were going to replace the system with a new warehouse setup. We had 2 years to get his up and running before the whole linkage changed. We were to interface with an international setup that was being totally rewritten. My job was to maintain the existing COBOL system while the new guys rewrote the whole thing. The breaking point was that everything had to be processed and out by 2 AM at the latest. With the old COBOL we were out before 12 PM. After a year and with 1 year to go the new PC system was ready to process out by 6:30 AM and they didn't know how to speed it up much further. The decision was made that we would have to modify the old system to meet the new interface and we would have half the time to do it. We made it with time to spare in the dying system on life support of COBOL and we even built in places to upgrade for the future. BTW the PC guys 2 years later are still trying to speed it up. They now have it ready to go out by 5 AM. There is a lot of life in COBOL if you know what you are doing and know how to make the changes quickly and permanently. Sure there are things that the new systems can do better but there are also things that the old systems did better than the new ones. Massive amounts of data manipulation is a case in point. We were processing over a million transactions through a complete process in an hour and a half with COBOL; with the PC's it took 7 hours at least.

bernalillo
bernalillo

I'm still driving a 94 saturn. Moon roof glued shut, AC no worky, plenty dings and dents, wind shield getting hard to see through when driving into the sun, key sticks in the ignition switch, the chime dings repeatedly and incesently for no reason, I am too big both in height and weight for the low seat and entry, tires now technically qualify as slicks, repairs getting more and more expensive. It's cheap to drive but at some point, before it causes me damage, I need to replace it.

klaasvanbe
klaasvanbe

It takes so long I guess, because in the past they decided to 'hard code' the salaries for some odd reason. If they decided to handle them as parameters of a form, a card or whatever medium they want(ed) to use there would be barely a problem and the later change can be accomplished in minutes, maximum hours in stead of months. The main problem with hard coding is that this tends to appear in more than one location apart from necessary knowledge of the language[s] (i.c. Cobol and eventually interfaces written in some kind of assembler...) involved.

pvtechrepublic
pvtechrepublic

The first thing Arnold needs to do is fire the controller and if that can't be done then to bypass him. I didn't read all the comments but enough to agree that changing employee salaries in mass is no big deal in any COBOL program no matter how old. Anytime one uses a paper tiger excuse to avoid direct conflict it ultimately comes back to haunt them.

mvandeneede
mvandeneede

Bill, do you think they need some help reprogramming? I am available, and I know COBOL very well. LOL!

Dr Dij
Dr Dij

The really strange thing about the governator's order, is that he missed the correct target for minimum wage: This order exempted the legislature. THEY are the ones locked in a deadlock about the budget. THEY are the only ones who should have had their wage reduced to minimum. COBOL problem? No prob! STOP PAYING THEM AT ALL till they get a budget! and if the budget includes increase in spending or taxes, cut their wages in half. Give them a small raise if they manage to cut the budget to what it was a couple years back, when we managed just fine! Then the yowling teacher's unions, et all can't complain. They managed a few years back on the same amount they could reduce the budget to. Problem solved!

allanlindsay
allanlindsay

Am I missing something here? I think 6 months may be an understatement. For a start, the plan is to pay the employees minimum wages UNTIL the budget is passed, then bring them back to full salary and give them back pay. Somewhere you have to store old salaries, and then keep track of how much you owe in back pay. Handle overtime pay. Adjust tax withholding, Are you going to sock them with a big tax bill when you pay out their back pay? What happens when their deductions for insurance, etc exceed their paycheck? Are they going to have to make a payment to keep their insurance or is the state going to carry them? What other flags and triggers might exist in the system

WV Rich
WV Rich

How long would it take the Controller to institute an across-the-board pay increase? You can bet it wouldn't be 6 months.

Sensor Guy
Sensor Guy

This reminds me of the famous DMV project. I can see it coming...Now I'll need some meds to stop the nightmares to be able get to sleep tonight! One of the problems of being an old IT veteran is that you keep seeing the same self-induced "shooting yourself in the foot" disasters coming again and again. First of all, we have no evidence as to why the alleged six months. Someone, hopefully competent, has made an estimate somewhere, hopefully on paper. So where's the project plan, the task list? Assumptions? The press, driven into a frenzy because this helps their agenda of selling vendor advertising has seized on a statement based on innuendo. The employees, hoping to stave off their salary cuts, are piling it on as well. The vendors, eager to sell their wares and pushing as well. The real reporters ought to be asking for that project plan through an FOIA. After all, it should be public. When we see the task lists and their durations, assigned resources and all that detailed PM crap, then we can intelligently start finding where the mess starts and dissecting a solution. I'll bet there's a good chance that there's maybe a hidden budgetary item that's been already denied to some ambitious IT manager hidden in this estmate trying to be pushed through under the cover of political expediency. Band-Aids? Duct Tape? Rube Goldberg is the patron saint of IT Architecture! It's everywhere, including especially in the brand new "SOA" and "Web 2.0" crud being pushed by vendors and consultants nowadays. Anyone who thinks ALL IT (even the newest IT) doesn't use band-aids and duct tape has never run production IT. In over 40 years of IT I have yet to see a system (especially payroll) that hasn't been "band-aided" after one or two quarters or even after a "bridgeback" to the AP or GL system to calm down the CFO. Oh and don't get me started on a new ERP "vanilla" system also...in 2003 I saw an unexplicable bubble sort in the supposed QA'ed vanilla code of a major ERP payroll vendor system about and found out that it was the homework project code for an undergraduate compsci student in Mumbai that had slipped through their QA. Bandaids and duct tape and self inflicted wounds even in multi-million dollar just shipped vanilla "memory leaky C++" ERP code. Blaming it on technology is what comes out of the mouths of lazy techie cry babies who are too lazy to learn business process and appreciate older technologies. It's coming from weak minded managers who buy hook line and sinker into vendor con jobs and press bred "markitechtures". True, technology will appear to always improve on something that's old, but first you need to learn everything about the old and allegedly problematic system to figure out what you can bring from the new to improve the old. Anything done otherwise is really just setting you up to show off your incompetence. BTW, lowering a person's pay is already an established and tested process in a tested and certified production payroll system. If it needs to be done, then maybe we hire a hundred or so temps to make the payroll master record changes manually for a few weeks? No new code, no code testing required, no new fangled technology needed and all within the most likely established financial processes and checks and balances. I'll have to get a chuckle in church next week with Fred Brooks about this. Everyone in IT should read his book "The Mythical Man Month". Throw in Petroski's "To Engineer is Human" and Dorner's "The Logic of Failure" and you'll begin to see where why duct tape and band-aids are an integral, valuable and necessary part of IT. IT is Band-Aids, duct tape. Our sole reason for existence is to support the business and its processes and since we're human and we will never be perfect, Band-Aids and Duct Tape are inevitable and required part of our profession. We patch and fix so the business process looks good! Vive le duct tape!

mario_silvio_hotmail.com
mario_silvio_hotmail.com

May be things are different in the US, but here in Brazil, ANYTHING related to governments take months to be done

zetacon4
zetacon4

I seem to find truth in every one of your posts. And, that's a first here on TR.!!! In the final analysis, I believe we all will conclude that this is totally a political fight against the governor. At the same time, knowing COBOL, I wouldn't want to make drastic changes to a payroll system in that language. I have build such systems from scratch in other archaic languages. I feel for these guys. Great posts all! Frank

Tony Hopkinson
Tony Hopkinson

I assumed that minimum wage was going to be a pay rise for 200,000 workers. Oh silly me. :p So how long is it going to take you to 'reprogram' the systems so the governator can give a lot of people you know (and who knows possibly yourself) a massive paycut. Ages....... ffs Duct tape IT my arse...

fidlrjiffy
fidlrjiffy

First off it is entirely possible that it could take six months; 5 minutes to change the code and the rest of the time to do the documentation. The hyperbole aside a state financial system like any large system requires an awful lot of up front analysis and back end testing to make any change to say nothing of the fact that system revs and staff time have probably been allocated well in advance into the next several months if not years. In short, you don't do anything quick with a payroll system because there's big trouble if you mess up people's checks. So the question of whether this is BS or not or has anything to do with Cobol or a legacy system is probably not. It doesn't matter what system you have whether in-house PeopleSoft or out sourced with ADP a change like this is not going to happen by the next payroll cycle. While six months was probably pulled out of the controllers butt it is mostly a bad sound bite that leads one to assume that the system is old and crappy. I believe I also read a quote that it was because Cobol programmers don't exist and that the language was old. First disclaimer: I'm not a Cobol programmer. Second, there are lots of Cobol programmers around as just about every big system out there, the aforementioned ADP, MasterCard and Visa, every big insurance company, has their systems written in and maintained by a legion of Cobol programmers. Basically, then, the controller didn't want to make the change and did want to stick it to Arnold. His remarks about Cobol were BS. To get to the bigger question I support old systems and so does everyone else. Cars are built better these days and so are software systems; it's a pain in the neck keeping a ten year old car running but, and here's the point, it's cheaper than a new car, and the old system is cheaper than building or buying a new one. Do these systems divert resources? Of course, but they would only be used to support the new system anyway so it's a wash depending on how many people you're talking about. How to convince management? That's easy if it's a vendor system. Tell them the vendor won't support the current release anymore. Even if it's not from outside SOX and audit have done more to generate business for IT than anything else. Tell management the system won't pass the next audit. You can also try to convince management that the system is just too difficult and costly to support. That will be crap, of course. It's crap because software doesn't go bad and unless it really is written in a dead language like FORTH or something you can always maintain it. You may not want to or like maintaining it, and it may be inefficient and a dopey system but that it not an argument that convinces management. You can certainly try, though.

Locrian_Lyric
Locrian_Lyric

I suspect politics is at the bottom of this one.

iansavell
iansavell

The fewer statements required to execute a concept, the quicker it is to write but the harder it is to debug. However, in the case shown I suspect there is only one active statement in each language. C and Perl are clearly the losers because omitting the "\n", which isn't intuitive, will generate a nice little bug. I used to joke that if a C programmer was in charge of the housing dept. all street numbers would start from 0. It really is a rubbish language to debug.

Sensor Guy
Sensor Guy

Tony, Bravo! Well said. The words of a true, experienced and "crisis tested" IT professional.

bernalillo
bernalillo

It really doesn't need to be the platform the network is built on either...

jdclyde
jdclyde

or they can't sell the new systems. People have been saying Cobol is dead for decades now, and it keeps humming along. Where are the thousands of programming languages that were all going to replace it? The bit bin. It is all about revenue of new hardware/software. Big surprise.

Tony Hopkinson
Tony Hopkinson

There are fundamental differences in the hardware. For instance it would not be a surprise if the main payroll server was connected to a few 100s of 'green screen' terminals, via hardware terminal servers. Now you could go web based (for me that would be job one for a system like this), but that's a massive infra-structure outlay, and you still have n't improved anything. That tends to make people's, brows wrinkle. I can't come up a payroll system design so bad this would take six months, no way on cobol, as it's almost certain to be basically a batch system. Could be messy, but more donkey work than rocket science.

Tony Hopkinson
Tony Hopkinson

Not a sniff of it anywhere. All those provisons should be inplace, should they not, how does dropping someones rate of pay give rise to a whole set of new scenarios? Back the sytem up do the change. Extract the relevant numbers. restore re-run, work out the difference do an adjustment. Not rocket science is it? You are trying to design a system to do this, all you need is some more duct tape, a bit of chewing gum, two rubber bands and a bit of effort and some batch files. Course you also need the people putting all this effort in not be working on their pay cut as well....

dstreifling
dstreifling

A later article in the Sacto Bee made the same pint as WV Rich. I agree 100%.

Sensor Guy
Sensor Guy

My keyboard shorted out from all the tears that rolled off my face that fell on it as I laughed and cried from your well grounded and obvious common sense leadership.....comment Thanks...I won't need my meds tonite! The nightmares I'll have of flying out once again to the Californication land to fix the DMV disaster and fire a few dozen clueless techies and their acronym babbling managers will melt away as I laugh some more!

cory.schultze
cory.schultze

As with any athoritative body, such as company director / Human Resources or the government of a country or state; if it means they'll have to pay more, it'll take longer to happen. If it means they'll make money, it'll be immediate. My company has currently put everyone on overtime ban. Conveniently, a few months before they plan to put everyone on salary. Salary is calculated from your current wage + average overtime in the past 6 months. (I'm stroking my beard right now!) Just like the British government, they blinker the staff into thinking that the company (country) is going through economic struggle and must therefore scrimp on its biggest assets, the staff (tax payers pay rise in taxes) for the promise of a change from hourly rate to salary, which would normally be an increase. (One tax is lowered or cut, but a stealth tax is introduced or another is increased.)

Dr Dij
Dr Dij

didn't want to do it. He originally refused. So he's come up with the 6 months thing to deny Arnold without appearing to be insubordinate.

Stargzer
Stargzer

Does the source code still exist? If it doesn't, the Controller's estimate could be way too low. Other than that, I can't see why it would take six months, unless they need to let a contract for a COBOL programmer. I'm sure they must have laid off the people that used to maintain it. I mean, those old duffers probably never learned C or JAVA or Object-Oriented anything, so what would they know? Just COBOL? I'm sure Adm. Grace Hopper is laughing!

TonytheTiger
TonytheTiger

Employees' wage rates change all the time (promotions, seniority increases, etc...). Why is it "just now" a problem?

jdclyde
jdclyde

How can a payroll system not be written to be changed on how much people make, and what deductions are taken out? Poor planning on someones behalf does not reflect on Cobol at all. The big push is to get a shrink wrap package, because if it is on a shelf, it MUST be good, right? Then you get to change they way you run the process to what the program does, instead of being smart enough to write a program for the way you do business. Years ago, HR decided they wanted to get off of the in-house cobol programs and go to one of the big names, ADP. We had to get TWO new servers, because their database for their time clocks is not compatible with the database for the payroll. It doubled our entry time each week. We then would spool a file, and DIAL IN to their server, and upload the file. They printed checks. We then DIALED in, downloaded the file and fed it into our server. This was efficient by who's standards? After their database CRASHED for the third time in two months, each time causing us to have to re-enter two daze worth of data AGAIN, HR came to us and begged to go back to the old system. We have a full time programmer in the department, so the system is never obsolete, it just doesnt' have the pretty front-end AND crashes the shrinkwrap options do.

Sensor Guy
Sensor Guy

Great story! Many folks don't realize that the duct tape story also happens inside the covers of most machines. When I managed a microelectronics development and design team is when I realized many microelectronics board designs, especially those in networking still use the RS232 interface for communicating WITHIN board components (we're talking now millimeters on the large side here). Although not as prevalent today, every board you buy from a vendor at the store that has patch wire or plugs between components is a "consumer level and approved" duct tape type of fix. Although FPGA's and other EPROM type technology have reduced the need for last minute wire fixes on boards, many early level and beta boards still have this "duct tape" on them. Why don't you open up the latest servers you are about to install and ask the vendor why they are still using ties and scotch tape to hold wires going across the board from the fan to the motherboard, and the list goes on... I'll bet that at least half of the "leading edge" equipment you buy today at a store (and yes, and the Nintendo Wii had some, the Stage 3 Direct TV Controller I know had it, Webslinger hardware, PC TV Cards, and even some Sony DVD recorder boards use RS232, Parallel and even UB-Net working inside those boxes.... The real scandal, if the press even wants to go there and show even more ignorance, would be that the Rube Goldberg engineering is all over IT and consumer electronics, even inside those allegedly sleek, new, "bleeding edge" boxes they keep raving about. IT could never work without tape, ties and ingenuity for the hardware. Now I won't even go to what's needed and used in software!

Tony Hopkinson
Tony Hopkinson

It just sort of happened that way. One place I was at we had a large DEC network, a large PLC network, a large windows one, not even counting the connections to the HP, IBM ,and office LAN. Someone rolls in with ?250,000 of kit, says Tony interface to this. RS232, I sh1t you not...

Tony Hopkinson
Tony Hopkinson

involved, may be one or two feet of red tape. Government IT project fails in controlling scope, now that would be new wouldn't it. :(

ShadyHouse
ShadyHouse

Real problem is ..... Project startup = 2 weeks HR decide what they want = 4 weeks Analysis/design/spec, reviews = 4 weeks (IT) HR reviews = 2 weeks HR Reqt changes = 2 weeks Analysis/design/spec, reviews = 2 weeks (IT) HR reviews = 2 weeks HR Reqt changes = 2 weeks Analysis/design/spec, reviews = 2 weeks (IT) HR Reviews and reqt signoff = 3 weeks Cobol changes/unittest/systemtest = 1 week HR Test = 4 weeks HR Reqt changes = 2 weeks Analysis/design/spec, reviews = 2 days (IT) HR Reviews and reqt signoff = 2 weeks Cobol changes/unittest/syystemtest = 3 days HR Test = 4 weeks HR Signoff = ................... Whoops! Change of HR priorities. Before we put this live can we accelerate the Sacrificial Pension Schemes? :-)

Tony Hopkinson
Tony Hopkinson

hat on there. :p Government IT is just pathetic. There have been some real classics in the UK. Billions of pounds of tax payers money flushed right down the toilet. Normally I'd go for the death sentence on a treason charge, but I don't think that tech from Hartlepool on ?8.5k was really the person responsible.

TonytheTiger
TonytheTiger

[i]That tends to make people's, brows wrinkle[/i] at least not in government. The people who actually make the decisions (the politicians) are relying on the advice of people who are just out to guarantee their own future employment. The politicos, nor the people very rarely know any of the details, other than "the computer people said so". I know some people who are on some of these advisory panels, but I am ashamed to admit it.

NickNielsen
NickNielsen

Rather than hire an outside consultant to write the job, they want to train an in-house programmer. I don't remember much Cobol after 30+ years, but I can't imagine that finding a single record and updating a field from an external data file takes more than a few lines of code. Hell, in FoxBase, we could do it in two; it took more code to set up the function loop and error traps than it did to do the actual work.

Locrian_Lyric
Locrian_Lyric

the processes come AFTER innovation. only late adopters get the benefit of neat clean packages.

The 'G-Man.'
The 'G-Man.'

not as of the need to even think about PIC 999 or higher it it!

Editor's Picks