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."
I feel the effects of this all the time, and I am not old yet. I have been asked for years, "What if you get hit by a Mack truck?" Now, I would say that in the last five years, things with Linux have standardized to the point where my Linux stuff could be outsourced. But, how do you replace intimate knowledge of network layout, homegrown code, machine function, and how to get around policies to get things done?
Click here or here.
The article states, "For a truly objective assessment, it is usually best to engage an external consultant who is not involved with system maintenance. However, senior organization members are an invaluable resource for these consultants." No, what usually happens (in my experience, 20+ years IT) is that the seniors get fired, then have to be hired back as consultants at 3x their former pay.
$nice = $webHosting + $domainNames + $sslCerts
Who would you rather operate on you: A young surgeon, or an older surgeon with years of experience? (I know, programming/administration != surgery, but I think most people will understand the point.)
It's not just training, it's also experience. Those with experience are more than likely to be able to do things slightly better than those that have just finished training, since they already know almost exactly how to do things.
They were dinosaurs then. What younger workers would deliberately learn a system that was already obsolete when they could learn leet new skills instead. This is really an issue of who should bear the burden of maintaining a skills base, the companies or the workers. The companies will naturally try to pass the cost of doing business on to anybody else they can if they can get away with it. Now that there's a shortage of mainframers because they laid off everyone they could to save on pension costs, well I say that's poetic justice.
Disaster recovery, and maintaining operations in the face of reduced knowledge base and personnel are the two sides of the same coin. The military regularly does this (no comment on efficiency here) but business as a whole do not do this. /.-ers think in terms of IT, but there are other issues too. Think about customer service departments, billing departments, all facets of a business. Disaster recovery is not a simple or trivial issue.
Data back-ups and documentation are not sufficient. To truly be prepared, a company has to have an agreement with temporary worker agencies to replace certain people, and practice to make sure that the documentation is enough....
In the case of New Orleans, they not only need people, companies there need their buildings and hardware replaced. Other, less demanding situations are losing people because of personal responsibilities to family in the aftermath of the storms. Those people have to be temporarily replaced in some cases.
A truly thorough disaster recovery plan is both large, complex, and on some levels, very scary. It has to cover situations where the entire IT department is in the same bar when a bomb goes off. Who does what then? Do they tell the IT staff not to socialize together?
When the only legal person in your SMB is now missing, who steps in to sign that paperwork?
There are tons of things to think of. The simple things stick out, but true disaster preparedness is a horrific thing to accomplish, and it costs big $$$$$$$$$$$
Google for information, it is scary....
Two cents used...
Support NYCountryLawyer RIAA vs People
Ha! Don't assume anything is obvious.
You assume that the "old" engineer has no idea about Linux. You also assume that the young engineer has the first clue about what the company really needs.
Both very very bad assumptions.
Experience is the key here. Sure, the younger guy might have a good idea, but spitting buzzwords at the boss without the first clue about what it's ultimately going to mean to the company will do only two things: 1) Peg you as a loudmouth know-it-all or 2) Get you put in charge of making that migration.... Neither of those are going end up pretty.
When YOU get to be an older engineer, sit back and listen to all the younger guys that assume YOU don't have a clue about what's going on. You're not going to like it one bit.
I'm surprised at the number of young engineers who think that the "old guys" don't know anything about the "latest" tech.
A while back I heard an intern going on and on about how the young engineers (and he considered himself one, even though he hadn't graduated yet) were the best ones to come up with the new ideas for everything. The "old guys" just didn't have what it takes.
What a fool.
This isn't a "young" or "old" thing. This is a "good idea" thing. That comes from being a good engineer, not being young or old.
Not every young guy pays attention the latest technology, just like the old guys don't just stick their head in the sand when it comes to the new stuff. As a matter of fact, the older guys were the ones that were dinking around with all that new computer tech back in the day. Most of them did a lot more than the "fresh outs" do today.
If you're one of those guys that believe that the young guys are the stars when it comes to engineering, and the old guys should just step out of the way..... well, you're going to get old too. When that happens, I seriously doubt you'll feel the same way that you do now.
The root problem in your sentences I've quoted is not the migration from the mainframe, it's the word "Windows". To expect Windows to have anywhere near the reliability and performance of an IBM mainframe is, at best, humorous.
As you go on to say, IBM mainframes are highly optimized computing systems, systems that excel at moving data from the disk to memory to processing as quickly as possible. Windows boxen don't even come close in this regard. And then there is the reliability of Windows vs. IBM mainframe OS's.
For the past 20 years I have been hearing how Windows is going to kill the mainframes, yet IBM's mainframes still seem to be doing rather well. I hear they even run Linux nowadays. Far out (to use the terminology that seems appropriate).
"Precisely when the organization is trying to gain a return on investment, software operating costs may start to climb. ... At this point, support costs can start to consume a larger and larger part of the IT budget, severely limiting new investments."
The company often feels that software maintainers are extorting money from them. That's especially true when the application is not an external package continuously upgraded with new features. Managers expect that a paid-up static application should cost zero to maintain. This was made very plain when Y2K remediation work was complete and the Y2K workers, young and old, were booted out the door with parting greetings that sounded like "good riddance."
As a senior (now retired) software type I wrestled with the software maintenance dilemma for decades. I saw that old code was designed for the CPU and memory limitations of its day. As time marched on Moore's Law rendered old code useless faster than poor documentation or obscure programming languages.
At one point I resolved to put an upper limit of 10 years on the life of any code. After that it would have to be discarded and replaced. Then I realized that if everyone followed that policy future generations would be doomed to reinventing the wheels (i.e. the logic) invented in earlier versions. Actual progress would approach zero asymptotically. Consider for example code to control a nuclear plant. The plant has a 45 year lifetime, and the laws of physics and principles of control don't change in that time. If we had to reinvent all the control software four or five times in the life of the plant, it would be a terrible waste. The most modern implementation might be more efficient and superior in quality, but there is no assurance that it does a better or as good a job at controlling the plant as the first version.
Both extremes are wrong. Maintaining old static applications indefinitely is wrong. Periodic discard and replacement is wrong. My final conclusion was that old applications need to be rewritten and re-implemented and expanded and modernized gradually. If we re-write or re-implement 10% of the code every year, then none of the parts get to be more than 10 years old. We also deliberately blur the boundaries between old and new applications and the boundaries between developers and maintainers.
In my experience developers resist this notion more than management. Developers love reinventing wheels. I bet every open source developer worth his salt would love nothing more than his/her own chance to invent Unix from scratch, and along the way every application and algorithm that went with it. In any case, they really hate the idea of re-implementing some predecessor's cleverness embodied as code. They would much rather create their own fresh version confident that they can be cleverer than anyone else. It goes with the territory when we seek creative people to program. They like to create -- duh.
One other thing, when our gradual rewrites of old code reach the point where everything is fully expressed as objects, then the burden of rewrites and maintenance should be drastically reduced forever after. Isn't that the promise of objects? Expandability? Adaptability? Any large application well founded on objects should be able to morph itself into any future application one little bit at a time.