Slashdot Mirror
Keeping the Lights On
An anonymous reader wrote to mention an IBM article examining the role that older workers, experienced with legacy systems, should play in system maintenance. From the article: "Many enterprises still execute critical business operations ... via older software systems that run on large, mainframe computers rather than individual PCs. To meet changing business needs, these companies continually update, extend, and integrate their systems. Paradoxically, many of these companies also have policies that threaten the single greatest source of knowledge about their older systems: their most senior personnel. Although the aging workforce represents a vast pool of talent and experience, these businesses neither actively recruit senior workers nor provide incentives to retain those on staff.1 Instead, they mistakenly assume that they can hire younger, lower-paid people to perform the same tasks."
This article comes from IBM, this is no surprise, given that they must have the most interest in maintaining the "mature" workforce in the enterprise
Example of discussion:
Manager: We need to increase the throughput of our Mainframe system
Old engineer: Let's contact IBM, our mainframe hardware manufacturer and add a couple of processing units to the system
Young engineer: Nah, just let migrate to Linux, I can get you the same service, same performance, for a fraction of the price if we get a cluster of cheap Opterons, plus this will scale easily in the future and we will be vendor independent.
(Obviously the young engineer didn't had to deal with migration issues in the past, and obviously the manager is going to be sold on the bottom line)
Interesting, my father was laid off from IBM a couple years ago after working for them for over 20 years. Now he works for a company that contracts with IBM to do.. you guessed it work on mainframes.
The fact that the schools aren't even teaching those LANGUAGES anymore? There is a dwindling supply of experienced personal, while the need for them is still expanding. I love capitalism.....
Disclaimer: I work for a company that competes with IBM. But then again, don't we all?
IBM encourages older workers to stick around and keep mainframe systems running. Of course they do. The maintenance contracts that IBM is paid on for these mainframes (and the IBM Global Services guys who sit on-site to babysit these applications) are priceless. I was part of a team of consultants that was involved in moving a major mainframe-only app to Unix/J2EE and IBM did everything possible to forestall and prevent it. When we were done, we were saving our customer almost $500k a month on the costs associated with maintaining that (admittedly simple) legacy application.
I know this is blasphemy on Slashdot, but when companies like IBM get in bed with open-source and with technologies we (okay, that I) favor (in my case Java & J2EE), you have to remember they are *not* a product company in these spaces -- they are a consulting company. Sure, they sell their hardware by pitching it's flexibility (a good thing), but they slash prices in order to place their consultants in your organization to "help out".
This is not to say they are evil or bad. But only that all of this is wonderfully self-serving and really doesn't pass for news...
Those that I've spoken with who have gone into consultancy say that once ALL of the benefits are gone, you need 2X your former pay just to break even. That's vacation, health care, dental, sick days, etc. Not to mention that consultants need to provide some sort of office space, communications, etc. Those costs were formerly paid by the employer. That's why the burden rate for you usually ends up looking like somewhere in the realm of 2X your salary.
So the 3X price might seem high, and it is, a bit. But to the company, it's only 50% higher than having the employee would have been. To the consultant, it's 2X the "discretionary" (after fixed overhead) pay rate. From the company's point of view, they only need the consultant for a fixed task or set of tasks. From the consultant's point of view, he needs some padding to weather the lean times.
So it's not as extravagant as it looks, for either party. By the same token, I don't really think it's a win-win situation, either. It just is.
(I used to know JCL, and be pretty decent at it. I'll bet I could relearn fairly readily. Actually, JCL was kind of neat, because everything stayed put until you did the SUBMIT. Then it was too late, and you'd better have done it right.)
The living have better things to do than to continue hating the dead.
I'm 19, so predictably I had little mainframe knowledge in the course of my (mostly self-taught) computer education. I too thought that mainframes were a thing of the past.
Then I got a job at my current employer, where mainframes process all our data, and got to talk to some of the datacenter operators who actually work with all the different platforms we use. What did I find? Mainframes, while not the most user-friendly beasts on the planet, are still indispensible when you have hundreds of employees and hundreds more clients needing numbers crunched without bringing your system to its knees.
Look at the computers that keep the world running - the ones that process your bank statement, the ones that process your credit card statement, and so on. I think you'll find that mainframes are the backbone of the processing infrastructures of the organizations that do this.
Personally, I think it's the "de-geekization" of computing that's to blame. Fewer people are being trained on the complex workhorses behind the scenes, and instead are being trained on the EZ-2-USE REVOLUTIONARY TECHNOLOGY OF THE WEEK/MONTH/YEAR!
In all my experience, older employees become mentors to the new recruits.
Speak for yourself. Here in Mexico people over 40 aren't hired *AT ALL*. No matter how much they might know. And there's no way to sue the companies because there's no way to PROVE they didn't hire you for your age.
But everybody knows.
but where and when does experience and wisdom rule over copper-tops?
Sad that being in your early forties qualifies you as an old fart, technologically speaking. I'm in my mid forties and I'm seeing the same pattern. A fellow we hired a while ago said, "It's really getting brutal out there" and he just turned fifty. I think it's because it's really, really hard for a manager to justify to a corporate beancounter the extra $30K he's paying that experienced engineer. And it's worse, if you do your job so well that there aren't any major problems or snafus along the way: the impression then is that the job is easy and that anyone can do it.
Where I work the owner actually prefers to hire engineers that have been around the block: it makes his life a lot easier. But I agree with you, that's not too common these days.
The higher the technology, the sharper that two-edged sword.
It's probably worth mentioning a 'seminal' essay written by Jack W. Reeves that suggests that software development is fundamentally different to other engineering disciplines, because the construction phase costs essentially nothing. (He considers coding to be part of the design.) Well worth a read (although it's no excuse for the complete absense of documentation).
Regarding the above analogy, the engineer jumping on the lathe is analagous to the software developer hitting the compile button. And so the analogy breaks down.
Code as Design: Three Essays by Jack W. Reeves.
That's because they can. While more senior people have existing knowledge, they're no more or less trainable in these areas than their younger counterparts willing to work for less. The arrogance of always assuming youth is less capable of knowing older systems is just as bad as the arrogance of assuming older technologists are the only ones who can support them. If the company is willing to take the months/years of time to get someone up to speed, then its in their best interests to cut costs where they can, assuming of course they're willing and able to train their new staff on these systems AND that the younger workforce wants to learn older systems.
While objectionable in how it's carried out, the real problem isn't that companies are trying to hire younger people to support antiquated systems to replace older, higher paid employees. That's a short-sided tactic by companies and is a symptom of a larger problem: that companies aren't working to either put in place newer systems the upcoming workforce can support or implement comprehensive training programs to ensure new hires can be trained for the systems they'll be supporting.
While it's deplorable this is happening to the older technologists--and it should be stopped--the real problem is that unless systems are upgraded or younger people trained on them, then at some point there won't be any available support resources for these systems.
In an ideal world, older talent would be cherished and younger talent nurtured to eventually replace them. Unfortunately, in a capitalist society people don't matter, just the short term bottom line. Any higher-cost resource is seen as a waste when less costly resources are available.
I had one interviewer say "well, I guess you don't know anything about Linux." when he saw I was mid-fourties. I told him I had floppies from waaaay back that said "Xenix - Microsoft Corp". He looked blank. Then I said "Yeah, I grok Unix, Xenix, Linux, Solaris. I've worked with DEC rainbows, 2b3's, Altos, RS6000's, SCO, Concurent..." he kept looking blank. I finally said, "I've been around the block. I have worked with a majority of variants of Unix, including Linux. I've got Linux experience since Kernal 0.96. through kernal 2.6"
Then he said, and I kid you not...... "What's this "kernel" stuff? I need L-I-N-U-X people."
My resume, right in the first sentence, says "7 years experience with Linux in current employment". The guy didn't read it, I guess, nor was I called again. I heard the project folded, so I guess it's all for the best.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
Yep. Two or three younger, less experienced people can usually perform the tasks in four or five times the time---after they've fucked it up six or seven times.
Keep good documentation and any competent person should be able to get up to speed in a decent amount of time.
Spoken like a soldier who's never been shot at. That "decent amount of time" is called a career.
Sometimes the documentation is written with an experienced audience in mind. Sometimes it's written on the assumption that you already know the basics---"basics" in this case being what you pick up over the first decade. And sometimes---important, career-defining times---you're dealing with things that just aren't documented. Like stuff from third-party vendors. Or for an infrastructure that's decades old. Or problems solved by folks who had already been there ten or twenty years, to whom the solution was so bleedin' obvious it down didn't even occur to them to write it down.
About fifteen years ago a bunch of very clever MBAs---who are usually more interchangeable than janitors---decided that the major RBOC they managed could save a whole lot of money if they "incentivized" their most senior employees into early retirement. So they offered them very generous severance packages and most of them left. Within months the infrastructure started going to hell---badly enough that even the MBAs could tell something was wrong. Subtle problems began to creep up---problems that employees with only fifteen years experience couldn't figure out how to fix. So the newly-retired employees got together and formed consulting firms---and their former employer paid them an amazing hourly rate. It was either pay them or face the choice of letting the current infrastructure collapse or "re-engineering" it at a cost that exceeded the market value of the company. They had already spend two billion dollars studying re-engineering, after which it was discovered that many problems already solved should stay solved the way were solved, because Ghod help you if you unsolved them.
"Why don't we get rid of all those old farts? They never seem to be doing anything." Sounds like the start of one of those wonderful Zen koans where the neophyte discovers that what the masters are doing is so subtle that he'll need half a lifetime to even see it, and the other half to get there himself.
This is not my sandwich.
The problem pointed out in TFA is a result of the new Clueless Management Suit Culture (CMSC). Management today in many businesses is too stupid to understand the value of experienced people. Large computer operations, whether mainframe or server farms, are indeed rocket science, but management views IT like they view their plumbing and electrical systems -- just call someone in when it needs attention.
I've lived through the changes that the last 40 years have brought in IT, which used to be called DP, MIS, ADP, etc. There have always been knowledgeable, hard working people on the front lines but over the years the bean counter and professional manager culture has taken over at management and executive levels, with disastrous results. There are no words adequate to express the contempt in which I hold modern business management. In the last 10-15 years I have seen more utterly stupid and wasteful decisions and policies than I would ever have imagined possible in my worst nightmares.
It seems that IT today is determined more by IT fashion trends than anything rational. Executives and managers micromanage IT while understaffing it and creating environments that result in 50-80% annual turnover of IT personnel. At one client location I was the only person to provide continuity over the course of 4-1/2 years during which every other IT position was vacated and later filled with someone who knew nothing about the site, the technology or the application. That included the IT Director, all the programmers and all the operators.
A word about documentation, since it has crept into this topic: Management is responsible for it being impossible to have documentation. Through the 1970s the custom in most shops was to document the plan with design and functional specs, then document the resulting work upon completing something. What evolved in the 1980s and 90s was that new things were pushed onto our plates faster and faster, making it impossible to document anything. With the loss of documentation, the people became more crucial to the organization, but the same suits who made it impossible to document anything also regarded people as thoroughly expendable and not worthy of paychecks sufficient to retain them for the long haul. So the suits screwed themselves coming and going. It's a wonder some of them manage to stay in business at all.
In the 1970s I had the pleasure of working for Scantlin Electronics (later renamed Quotron Systems), a company that had very low turnover. Two of us who left during that time returned and were welcomed back. In general, people there were paid just a bit more than the going rate, not by any stated policy but by the culture created by the engineer founder of the company, Jack Scantlin. Everyone gets upset from time to time and looks for a "better" job. But if one is already well-paid, such searches rarely produce anything interesting. And if the environment is very good to begin with, the result is low turnover and high continuity. It doesn't matter so much whether or not things are well documented if the people never leave. All the same, in the 1970s we documented our work.
Low turnover and a sane environment lead to something else that today's suits don't understand at all: the efficiency of small-team development. We never had more than an average of six programmers but we consistently beat competing shops that had scores of mediocre programmers. We could complete each others' sentences and get things done almost as quickly as it took to formulate designs and think them through. One time we built and installed a complete customer system from scratch -- no OS and no app boilerplate -- in three weeks. Not only did we design it and write the code in that time, the system never had a single bug reported against it in its multiyear lifetime.
I know of another place, a civil service IT department, where the same 5-6 people have been there forever. They have built a repository of 50,000 COBOL programs. A recent audit found tha
Look at the bright side: there's always seppuku.