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."
Just sit there and believe that, while you watch the infrastructure go down the tubes. Most of the training for any platform is more to advertise it then to really teach how to use it. Someone experience know that not everything that is documents that should work will work. An example an Old Prime Mainframe of a particular OS level supports TCP/IP and all the documents show that the system when the Gateway is set it will be used to get out on different subnets but in reality also you can enter in the gateway address it never uses it, and stays in its subnet, when these systems were made the internet wasn't very popular and TCP/IP was use for intranet usage, no one needed to go to a different subnet until Prime went out of business, when the internet became more useful. So all the training and reading the Prime books tell you that this will work all fine and dandy but in reality it doesn't work. Experience would save you many hours tinkering with the system trying to get it to work right vs. Using the knowledge that it doesn't work right and spending the time on a good workaround. A work around could take 8 hours, vs. Trying to get it to work could take weeks until you gave up and went to a work around.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
In an ideal world, much of that would be handled by appropriate documentation. In the real world, it gets harder...
We like to call ourselves professionsals, but compare our jobs to that of, say, a mechanical engineer. An engineer who jumps on the lathe and starts welding without designing and documenting what he's doing is little more than a skilled craftsman IMO - same for most of us IT guys. There's little to evaluate and test against when something goes wrong later, and the next guy to face your work has to reverse-engineer it before actually doing his job.
The "intimate knowledge" should be written as explicitly a possible, and common workarounds can be put in a cookbook format. Some things - like the political stuff - probably has to be passed word-of-mouth though. We all know about the ongoing costs of IT, and how big an issue maintanence is, so even 1 afternoon a week to write it up is worthwhile in the long term. The problem is pretty common in IT, but IMO it's not good enough (I'm not perfect either). It's a cultural issue, I think... too much hacking and "getting it done" and not enough planning and documentation.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
The director's *do* a lot of the surgery you dumb ass, why do you think they pay them the big $$? Stand around and consult? And the grunt work?? That is handled by the RESIDENTS, because it is exactly that. The difficult surgeries, you better believe the senior staff member is in the OR.
I can attest to the fact that hiring older, experienced workers is becoming more and more difficult. Let me tell you that it's harder for us old farts to find work than it is companies to fill the aforementioned vacancies. I'm in my early forties, and I find it increasingly difficult to compete in today's job market--it seems to me that many companies are after getting workers on the cheap rather than hiring experienced individuals.
Yes, one could probably get two fresh grads for the price of my salary, but where and when does experience and wisdom rule over copper-tops?
-Scott
My other sig is a Glock
My last job was building a trade processing/messaging application under Linux. I wrote it chiefly in PERL and PL/SQL, yet, inexplicably, my boss insisted on hiring Visual Basic/Windows/SQL Server people, intending to send them to a 1-week Unix training course to "bring them up to speed". He just wouldn't understand why this was stupid and ill-advised, nor could he understand why the project was taking so long.
It takes a LOT more than a training course to get people into the 'frame of mind' that a new environment and language requires. Non-technical people tend to have the mindset that a programmer "should be able to learn anything". While this is true to some extent, most PHBs don't understand that different platforms have their own innate 'design philosophies' that govern their design, and that 'philosophy' can take a long time to really wrap one's head around. Until that's accomplished, programmers will tend to write bad/inefficient/nearly unmaintainable code under that platform while they 'get the hang of it'. (For example, I currently am re-working lots of PERL code written by C programmers who apparently never heard of a regular expression. We're lucky they were at least Unix guys, and knew their platform well, if not their language.)
I used to work in a telecom company that had it right. We had a mainframe and unix component to our application, and, rightly, staffed mainframe guys and unix guys to do the work. Everyone was required to have a basic understanding of the others' platform, but we were allowed to specialize. This produced a stable application that generally performed as expected. We were even able to comfortably maintain and enhance it with a team of only 5 people.
To finish up, I offer the obligatory analogy to Something Completely Unrelated (no, not cars this time!) Specialization is good. If you have a problem with your heart, you probably don't want to see a urinologist who 'cross-trained'.