How to Move Cheaply Out of COBOL
in [Cobol]
|
From: SkippyPB on 24 May 2010 11:24 On Mon, 24 May 2010 08:25:57 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Mon, 24 May 2010 13:34:14 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>The 'problem' (again, note the ') from the management side is that folks >>who have the skills to do this are few and far between... and We Cost >>Money. That the amount we cost, when compared to the amount the >>functioning systems earns the corporation, is minimal, is dismissed with >>another wave of the hand... guys who can fix this Cost Money, let's >>replace everything (never mind *that* cost) so when fixing's needed the >>guys who can do it are less expensive. > >A big issue with this is that much of society has moved to a short >term view. Businessmen have followed the lead of politicians here, >and the idea of educating our own workers is seen as an expense that >won't pay out. > >It won't pay out because the workers are likely to take this new skill >to competitors, and it won't pay out because the managers will have >the short term costs in their resumes as well. > >But it is possible to find people who used Java in school and at home. >They don't need business experience to put Java on their resumes. And >it's easy to avoid analyzing how long it takes them to learn the >business side of their work. > >I'd love to see companies offering delayed bonuses. The CEO gets >real nice stock options that can't be cashed for 10 years. The >company (and other entities) would be better off switching to long >term strategies. The issue I have with OO at least as it applies to the mainframe and the industry I am most famaliar with, banking, how can you have "libraries" with predetermined rules from the complier manufacturer when those rules change more often than a baby's diaper? Where is the control? It's not there. Business rules change often which is probably why in 20 years OO hasn't caught on because it is just not practical. You cannot expect the compiler manufacturer to supply these "libraries" as part of the compiler. Now you'll probably say well the IT department does that. Well we've been doing that for 50 years. They're called subroutines and they don't add to the cost of the compiler. Regards, -- //// (o o) -oOO--(_)--OOo- "It's not getting any smarter out there, people. You have to come to terms with stupidity and make it work for you." -- Frank Zappa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: Anonymous on 24 May 2010 12:00 In article <2k2lv59hvq6gip7uhd5qf5loaok0gti2nj(a)4ax.com>, Howard Brazee <howard(a)brazee.net> wrote: >On Mon, 24 May 2010 13:34:14 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>The 'problem' (again, note the ') from the management side is that folks >>who have the skills to do this are few and far between... and We Cost >>Money. That the amount we cost, when compared to the amount the >>functioning systems earns the corporation, is minimal, is dismissed with >>another wave of the hand... guys who can fix this Cost Money, let's >>replace everything (never mind *that* cost) so when fixing's needed the >>guys who can do it are less expensive. > >A big issue with this is that much of society has moved to a short >term view. Businessmen have followed the lead of politicians here, >and the idea of educating our own workers is seen as an expense that >won't pay out. > >It won't pay out because the workers are likely to take this new skill >to competitors, and it won't pay out because the managers will have >the short term costs in their resumes as well. Seems like there's a need to trot this one out every few years since it was originally posted nigh a decade-and-a-half back... relating incidents I read about in the mid-1980s, nigh two-and-a-half decades back. From <http://groups.google.com/group/comp.lang.cobol/msg/6c29c3f3dc17173c?hl=en&lr=&ie=UTF-8> --begin quoted text: Heresy! It is a Well-Known Fact that if you give someone training they will immediately jump ship to a higher-paying company because said company is foolish enough to think that a person, trained, is more valuable than a person, untrained... don't they know that Gratitude Is Enough? > [snippage] > The result is new and revised programs being written in the style and spirit of > COBOL 74, or even COBOL '68. Now, repeat after me: 'The responsibility for the allocation, co-ordination and motivation of personnel and resources towards the accomplishment of a stated Executive goal is that of Management.' Repeat again. Let's look at it another way... assume that an organisation has invested a great deal of money in the upgrading of the physical plant. If sufficient investment has been made then it is likely that serious consideration will be given to upgrading the security system (new locks, etc.) to prevent these improvement from 'walking off'. Also consider the common term of 'golden handcuffs', a recognised metaphor for increasing salary/benefits to prevent human capital from *physically* walking away. Now, consider the investment of money in humans to upgrade skills in order to make them more valuable to the company. Consider how many times you have seen a corporate policy stating that an increase in salary/benefits accompanies the successful completion of such an upgrade (courses). Years ago the Wall Street Journal did a story on one of the major NY houses... I think it was Morgan Stanley or Morgan Guaranty or the like. They hired *only* the 'unhireable'... kids with BAs in Library Science, Art History, etc... they put these kids through two years of hell, 60 - 70 hr weeks, and turned them into *crackerjack* programmers... and then saw said kids being hired away by the competition at double or triple the salary. When asked why a raise did not accompany the completion of the course the HR representative replied 'Oh, we cannot do that... all the money has been taken up by training.' (compare this with 'Oh, we cannot upgrade the door-locks... all the money went into oil-paintings to hang on the walls.') After a few years of seeing themselves serve as Wall Street's unofficial programming school the company finally 'wised up'... and cancelled the program entirely. --end quoted text > >But it is possible to find people who used Java in school and at home. >They don't need business experience to put Java on their resumes. And >it's easy to avoid analyzing how long it takes them to learn the >business side of their work. It is one thing to learn a computer programming at home, Mr Brazee... and quite another to learn the various skills and disciplines necessary to make sure that various chunks of code are not stomping all over each other and creating Bad Data. Of course 'the database' now takes care of all such matters but having the skills necessary to analyse system/transaction flow to a point where a READ WITH LOCK does what it should, rather than hang up a system to a point where it needs to be re-IPL'd, is not something usually found in a '... For Dummies' book. >I'd love to see companies offering delayed bonuses. The CEO gets >real nice stock options that can't be cashed for 10 years. The >company (and other entities) would be better off switching to long >term strategies. I believe the latest trend in such circles are 'consolation bonuses', Mr Brazee, where Corner-Office Idiots award each other large sums *not* because their companies did well... but because the companies, while doing badly, did not do *as badly* as their competitors. I've never heard of such remuneration being bestowed on a cubicle-dweller. DD
From: Howard Brazee on 24 May 2010 12:29 On Mon, 24 May 2010 11:24:26 -0400, SkippyPB <swiegand(a)Nospam.neo.rr.com> wrote: >The issue I have with OO at least as it applies to the mainframe and >the industry I am most famaliar with, banking, how can you have >"libraries" with predetermined rules from the complier manufacturer >when those rules change more often than a baby's diaper? Where is the >control? It's not there. Business rules change often which is >probably why in 20 years OO hasn't caught on because it is just not >practical. You cannot expect the compiler manufacturer to supply >these "libraries" as part of the compiler. The ideal seems to be to separate business rules out from the I/O as much as possible, often putting them in with the data in a database. When you do that, it doesn't matter much whether the person writing the portal understands the business. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: Pete Dashwood on 25 May 2010 07:33 docdwarf(a)panix.com wrote: > In article <85t3c3FkerU1(a)mid.individual.net>, > Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > [snip] > >> As for COBOL's "cost effectiveness"... It is the MOST expensive >> programming language available. It costs more to buy, it costs more >> to write and it costs MUCH more to maintain than a "soup du jour" >> language like C# or Java, for example. > > Mr Dashwood, our experiences may have been different... but I believe > in your assertoion about programming costs you many be negelecting a > few things like CBA and ROI. Nope, I considered both. Although some accountants would argue that a Cost Benefit Analysis should arrive at an overall projected ROI. The subtle difference is that CBA is projected or estimated (and therefore subject to bias), while the ROI is historical fact and difficult to argue with. In terms of CBA, COBOL has a higher up front cost (software, tools, ancillaries) than alternatives, a higher development cost (it is very labour intensive to write, compared to alternatives), and a higher ongoing maintenance cost (again because it is labour intensive, but really because there is simply more of it than there is with alternative languages. I find conservatively a 3:1 ratio between COBOL and C# (given that both are written by competent programmers) with 700 lines of C# generally being equivalent ot 2000 lines of COBOL. However, this is a subjective judgement based on a limted sample so it is probably fair to exclude it from this argument. Let's say COBOL costs the same to maintain as anything else. It still loses on purchase and development costs. >Yes, COBOL costs a whole bunch of cash > to spec out and amplement, tune the JCL. get the CA/CI split *just* > right... Agreed. > > ... but once all that's done... that's it. Except that we would just like this one small change ... :-) And it took so long to develop that the requirements have changed, so can you tell us when Release 2 will be ready, please? :-) > this is precisely the > 'difficulty' (note the ') that mamy folks are concerned about. I, > along with others, have worked with code that is old enough to > vote... and a tweak here, a pinch there, a change from an EXAMINE to > an INSPECT... and the code's back to doing what it was intended to > do, ie Make The Company More Money. Yes, that matches my experience also :-) BUT, ONLY if the 'tweak here and pinch there' is TECHNICAL and not related to FUNCTIONAL requirements. This is where the methodology used in the particular shop has a bearing also. If the general requirements are pretty much established and the company's core business is not changing then everything is fine. But many companies are in fiercely competitive markets which are dynamic and they need to be responsive to opportunities, before their competitors are. Even if dynamic markets are not an issue the methodology has a bearing on the maintenance. Large monolithic programs developed in COBOL using the traditional Waterfall, are very costly to maintain. A 'tweak here and a pinch there' can cause unforeseen consequences in unexpected places. Even in other programs than the one maintained, if downstream feeds have been affected by the pinch or tweak. "Soup du Jour" programs, being Object Oriented are far less likely to suffer from this problem. Instead of the "unit of intelligennce" in the program being a "line of code" it is typically an "object" (component). So the "granularity" of the solution is larger and it is easier to pull and replace components than it is to find and fix a given line of code. It is like fixing a modular stereo; you may replace the amplifier, rather than find the particular resistor or diode that is failing. At least you have the option... With COBOL, you don't. > > The 'problem' (again, note the ') from the management side is that > folks who have the skills to do this are few and far between... and > We Cost Money. This is a different part of the argument and I agree with what you are saying. COBOL skills are becoming scarcer as demand for them drops and, like any market place, this means they become more valuable in the short term. (When demand becomes zero, they are worth nothing...). Of course, if they are priced too high then this contributes to COBOL itself becoming non-viable and industry looks for other (cheaper) solutions. That is precisely one of the factors leading to the current decline of COBOL; it costs too much and the people who can do it cost more than people with skill in other languages, who can also do it. So, COBOL people are retained because they HAVE to be (usually to keep legacy running) until another solution is found. > That the amount we cost, when compared to the amount > the functioning systems earns the corporation, is minimal, is > dismissed with another wave of the hand... guys who can fix this Cost > Money, let's replace everything (never mind *that* cost) so when > fixing's needed the guys who can do it are less expensive. (It seems from the above you agree with my posit that COBOL is expensive to maintain.) I don't think it is quite as simple or black and white as that but wouldn't you expect that to be the case? Someone is charged with getting the best deal possible for the company. This person finds that COBOL development and maintenance is NOT a good deal (even when stacked up against the profit the company is making, and the fact that, for the most part, the COBOL applications are running well) and the IT department is costing more than other operational areas of the company. (I am thinking here of an Australian insurance company who, when faced with an annual IT bill of around 24 million, simply closed it down, sold it off then leased it back for 8 million. They never worried about it when times were good, but when floods and drought ravaged Queensland and they were forced to pay out millions, it focused their attention...). Said person will look for another solution. Modern languages and approaches, when subjected to CBA and ROI analysis come out looking much better than COBOL, so COBOL has to go. "Guys who fix this cost money". If we didn't have this we wouldn't need to fix it. Is there some other way we can administer our business without it costing us an arm and a leg? There is...? OK, let's do that. Seems to me that is a reasonable and expected response. To do anything less would be a dereliction of duty. It isn't ONLY about cost savings (although that is certainly the major factor). The fact is that COBOL is no longer the "only game in town" and hasn't been for a couple of decades. The days when the company's operations and administration all centred on the central mainframe, and that processor necessarily processed EVERYTHING, are over. Departments have people in them who are computer savvy (many have degrees in computing) and they are quite capable of doing their own thing (even doing it very well). [I worked in one UK company where there were 3 times as many people with IT related degrees OUTSIDE the IT department than there were such people INSIDE it. They were smart users and it was very hard for IT to control them and tie down the loose cannons that were running around. Eventually (after many lunches with middle managers, listening and taking on board their reasons for not wanting to adhere to IT policy) we worked out a mutually beneficial policy that suited everyone. The secret is not for IT to try and control the data resource, but to make sure that it is coherent, accessible, and contains core information requirements. Most reasonable people (within and outside the IT department can recognise the necessity for this) and work willingly towards it. There should be no problem with departments implementing their own localised "IT systems" as long as audit trails are kept and core business requirements are posted.] So, in addition to your point about managers wanting to save money, there is the fact that the overall company is more computer savvy than it was 20 years ago, new people are joining who are not only computer literate, but are fluent in the techniques of networks, objects, and layers, and they see COBOL (and other non-OO languages) as a quaint old-fashioned remnant of the history of computing, not as part of its present. It is simply not possible to get the whole company to learn COBOL, and there are political objections to having to go cap in hand to IT whenever you want a new report, especially when you can generate it yourself from a local spreadsheet or database. All of these factors are contributing to the impetus to move away from COBOL. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 25 May 2010 07:49
Howard Brazee wrote: > On Mon, 24 May 2010 13:34:14 +0000 (UTC), docdwarf(a)panix.com () wrote: > >> The 'problem' (again, note the ') from the management side is that >> folks who have the skills to do this are few and far between... and >> We Cost Money. That the amount we cost, when compared to the amount >> the functioning systems earns the corporation, is minimal, is >> dismissed with another wave of the hand... guys who can fix this >> Cost Money, let's replace everything (never mind *that* cost) so >> when fixing's needed the guys who can do it are less expensive. > > A big issue with this is that much of society has moved to a short > term view. Businessmen have followed the lead of politicians here, > and the idea of educating our own workers is seen as an expense that > won't pay out. > > It won't pay out because the workers are likely to take this new skill > to competitors, and it won't pay out because the managers will have > the short term costs in their resumes as well. > > But it is possible to find people who used Java in school and at home. > They don't need business experience to put Java on their resumes. And > it's easy to avoid analyzing how long it takes them to learn the > business side of their work. > > I'd love to see companies offering delayed bonuses. The CEO gets > real nice stock options that can't be cashed for 10 years. The > company (and other entities) would be better off switching to long > term strategies. This (as is usual from you, Howard) is just eminently sensible. One reason for the economic success of Japan is exactly such long term strategic views. Failure to train workers because they will go to the competition, results from really short-sighted management. It has been with us for years and it is shameful. Employee loyalty is earned by treating people as "valuable" and recognising you need to pay more for trained people than untrained ones. The companies that actually do this (sadly, still a minority) are better places to work, and enjoy higher morale and a better bottom line than their competitors who still treat people like cannon fodder. I've worked in both kinds of place and seen it at first hand. Places where people enjoy going to work are simply more productive than places where they don't. Corporate cultures that value ideas, thoughts, and discussion and make it safe for all employees to say what they think, even if it doesn't match the "party line", are stronger and better places to work and they attract the brightest people. The top management schools are teaching this, successful companies are living it, so it is to be hoped that the rising generation of managers will embrace it and we will see better companies with more enlightened management in the years ahead. Pete. -- "I used to write COBOL...now I can do anything." |