Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Programming Businesses Technology IT

Keeping the Lights On 251

Posted by Zonk from the don't-throw-out-the-old-guy-with-the-bathwater dept.
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 discussion has been archived. No new comments can be posted.

Keeping the Lights On More

Keeping the Lights On

Comments Filter:

  • Anyone can do this job (Score:5, Insightful)

    by totallygeek ( 263191 ) <sellis@totallygeek.com> on Sunday September 25, 2005 @06:30PM (#13647070) Homepage
    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?

    • Re:Anyone can do this job (Score:5, Informative)

      by BiggerIsBetter ( 682164 ) on Sunday September 25, 2005 @07:17PM (#13647283)
      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.
      • "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."
        snip snip
        "even 1 afternoon a week to write it up is worthwhile in the long term"

        That's a nice thought, but you'll find that the technical staff often isn't to blame. When you're understaffed and the world is constantly falling around your head because the beancounters see IT as a drain instead of an asset, you often don't *have* an afternoon to sit and write documentation. The time ends up being spent just trying to keep the place running and/or meeting the deadlines set by the pointy hairs.
        • I know. That's the real-world problem and possibly where the IT culture kicks in. IT (geek/9 types often can't or won't stand up to the PHBs who can't see past the promises they (or the sales department) have made...

          IT is still a relatively new thing, so hopefully PHBs will learn not just about what IT can do, but about what IT needs to work efficiently. They wouldn't tell the production staff to forget about QA 'cause the deadline is tight, so why should they tell that to IT?
        • you often don't *have* an afternoon to sit and write documentation Exactly !!! I am a huge fan of documentation ... it is one of the first things I look for when doing work on unfamiliar equipment, and I make it myself whenever I am alloted the time to do it. Sadly, that time is not always provided.
          • I am a fan of documentation if it is done well. If it is not done well (is just plain wrong or looks like it was origionally written in chinese, translated by babelfish into spanish, and then into english), I'd rather not have it there to distract me. Unfortunately, I have tried to muck my way through documentation that fit the second definition of "bad". It's not something I advise.

            I don't even mind making it, but the truth is that I'm usually not given the time I need to do it.

        • Re:Anyone can do this job (Score:2, Insightful)

          by Anonymous Coward
          But apparently there is always time to post on slashdot.

          Hey, I'm guilty of it myself... regularly spending an hour or more wandering through comments when I could have been documenting something.

      • Re:Anyone can do this job (Score:5, Insightful)

        by Kadin2048 ( 468275 ) <slashdot...kadin@@@xoxy...net> on Sunday September 25, 2005 @07:56PM (#13647450) Homepage Journal
        I agree with much of what you said, but in terms of a resource, an actual person is many times better than even the best, most well-written documentation. Sometimes, if the system is complex enough, I could see the retaining of an additional person being justified, even if their only function was to act as a 'living encyclopedia' and help other (more junior) employees troubleshoot the system.

        I can't count how many times I've had a problem with a well documented system, and even after wasting hours of my time (and in many cases, hours of other people's time who just have access to slightly different documentation) only to finally find someone who has intimate knowledge of the system in question, and get an answer in five minutes. There are limits to how good documentation can be, even when it's searchable, indexed, and cross referenced.

        No amount of documentation in even the best information storage and retrieval system can compare with the power of a person who actually understands a system intimately, and then applies that understanding to other people's problems as needed.

      • The "intimate knowledge" should be written as explicitly a possible, and common workarounds can be put in a cookbook format.

        Um, no.

        My PHB recently was added to the Tripwire distribution list. The first question out of his mouth was, "How do I know which changes were legitimate?" I replied, "You have to understand what apps were updated in the last round, the log rotation schedule, but most of it is 'gut feel.' Does it make sense that that binary in /sbin/ changed when the FozzBizz app was updated?"

        The re

        • What a terrible waste of the plotter.

          We all know that the best use for that wonderful piece of printing equipment is for making large banners containing photos of the boss in compromising positions and posting them in the entry way so that all of the saff will see it when they come in the next morning =]

          I'm disappointed. As a BOFH, you should know better :P
          • Large banners? NO!

            You want dozens of small, postage-stamp to wallet-sized prints that you can plant in subtle places as a constant reminder of who's really in charge.

            Then, when the time comes to get rid of him, use the plotter's print server to intercept the CFO's next presentation to the board and replace it with said compromising photo. If you're lucky, it'll get rolled up without a single glance and actually be unveilled at the meeting. (a former BOFH can dream, can't he?)

      • Software Development Is not Like Engineering (Score:5, Interesting)

        by iangoldby ( 552781 ) on Monday September 26, 2005 @03:16AM (#13648956) Homepage
        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 [developerdotstar.com].

      • Lathe? Welding? (Score:5, Funny)

        by sczimme ( 603413 ) on Monday September 26, 2005 @05:47AM (#13649277)

        An engineer who jumps on the lathe and starts welding

        Welding... on a lathe? Such an engineer is either very, very talented or someone to avoid at all costs - quite possibly both.

        :-)

    • Re:Anyone can do this job (Score:2, Insightful)

      by Anonymous Coward
      that's simple : documentation.

      *not* writing docs for your systems or commenting your code is useful for job stability and protecting 'your' intellectual property, but at the end of the day all it does is hinder your employer from making real inroads towards the adoption of new technologies, finding new efficiencies, and hiring better people.

      techies seem to have real problems with other people stepping on their toes. Maybe it's a sense of 'power' that they were lacking in their childhood, who knows - that's
      • I heard of exactly this same phenomenon in the machine tools industry, back when a lot of places were switching from manual tools or semi-automated ones over to more fully computer controlled CNC ones.

        Guys who had worked for years learning how to do complex machining tasks quickly (and if you've ever seen a skilled manual machinist working, it really is a black art sometimes), how to build jigs, etc. suddenly saw themselves being made obsolete. As a precaution, a lot of people who knew of ways to either mak
    • I have been asked for years, "What if you get hit by a Mack truck?"

      Try this reply for the hell of it: "I won't give a sh8t if your customers can't reach you, I'll be playing harps in paradise."
           

  • What usually happens... (Score:5, Insightful)

    by Dekortage ( 697532 ) on Sunday September 25, 2005 @06:31PM (#13647075) Homepage
    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.

    • 3X their former pay (Score:5, Interesting)

      by dpilot ( 134227 ) on Sunday September 25, 2005 @07:27PM (#13647315) Homepage Journal
      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.)
      • You know, I keep hearing this "2X your pay is your cost to the company" myth, and I just think that is a bunch of crap. Let's take this consultant for instance. When he left the company he was making at least $8,000 per month (about $100K/yr, which is what a senior mainframe guy would be expecting to make at a rather small company).

        Now how is it that the company is forking out another $8,000 per month on top of that?

        SSI+Medicare is what? 10% And they stop pulling at a certain income amount, so say $1,00

  • Ask a relevant question (Score:5, Insightful)

    by Anonymous Coward on Sunday September 25, 2005 @06:34PM (#13647089)

    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.)

    • Re:Ask a relevant question (Score:4, Insightful)

      by slavemowgli ( 585321 ) on Sunday September 25, 2005 @06:48PM (#13647161) Homepage
      Surgery may or may not be a good example, though, because in reality, it'll be more like this: who would you rather have perform surgery on you - the young doctor who was hired by the hospital two years ago and who's doing the grunt work and performing surgery every day, or the old doctor who's been the clinic's director for the last 15 years and who probably hasn't held an actual scalpel in months?

      Beware of analogies. More often than not, they'll come back to shoot you in the foot.

    • Re:Ask a relevant question (Score:4, Insightful)

      by Now.Imperfect ( 917684 ) on Sunday September 25, 2005 @06:58PM (#13647203) Homepage
      Also the young doctor(IT guy) is fresh out of training and knows the latest techniques and is probably more willing to drive forward and encourage growth. Where as the older doctor is losing his steady hand(or his memory for the IT guy) and has been using the same stuff and probably has nearly no drive to keep the technology somewhat current. I see it in my dad, who I'd say is one helluva a sys admin with his grasp of security/networking in general, but its obvious that his age does effect his way of thinking... and its not always "wiser" imho.
      • All doctors I ahve worked on keep up on the latest techniques. Thay are also in the position to relate the latest technique to previous techniques. Then evalutate them to your needs.

        "Where as the older doctor is losing his steady hand(or his memory for the IT guy) and has been using the same stuff and probably has nearly no drive to keep the technology somewhat current."

        Are talking about technology or techniques? they are not the same beasts. All the doctors I have seen and worked with have the latest medic
      • Also the young doctor(IT guy) is fresh out of training and knows the latest techniques and is probably more willing to drive forward and encourage growth.

        "fresh out of training" with no practical experience manipulating my innards is a GOOD thing?

        One just itching to try new experimental techniques?

        if the new experimental techniques are the only thing saving my life - go ahead. But day to day do you want the new guy poking around inside you or someone who has had some expierence with the unexpected?
    • I would want the best trained, most open minded, most passionate person working on me. Number of surgeries is not a qualifier in of itself. The young vs. old or sr. vs. jr argument is so tired. I've worked as a developer and product manager in several companies and on many projects and I find that age and length of career has no correlation to the quality of work coming from techies. In fact, I've found just as many ill-prepared older techies as younger ones. To me, it comes down to whether people are i
    • Actually there is relevance in your analogy.

      Doctors and surgeons are basically glorified technicians. I'd much prefer a doctor with long experience than one with no or little experience.

      And as an I.T. person with over 12 years of experience it burns me that some idiot who just got his MCSE gets hired because he's cheaper. You get what you pay for.

      So enjoy that third eyeball in the back of your head. Your young surgeon knew what he was doing.
    • I see this all the time at work as well. Unfortunately it goes the other way. Our company keeps the older crowd around and gets rid of the younger people. Instead of pouring your money into these legacy apps, UPGRADE THEM TO SOMETHING FROM THIS CENTURY!!! It's hard for me to beleive that something HAS to run on big iron. Yes it will cost money to covert it, but in the long run you save.

  • IBM is trying the save a piece of his bizness (Score:4, Interesting)

    by timeToy ( 643583 ) on Sunday September 25, 2005 @06:35PM (#13647097)
    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)
    • Well Yes and no.

      Migration is a major expense, especially with millions of lines of legacy code. Just calling up IBM and adding additional processors may be better for the bottom line. Most experienced managers I have came across are very reluctant on giving up their dependable mainframes to the new faster, smaller stuff. Also the more experienced engineer could bring up the cost of migration as an issue if he desired.
    • And obviously the young engineer has never used a mainframe. I work on a government project with Unisys mainframes (also have IBM here, but that's a different contract). Unisys knows their mainframe business is dying, and is pushing Dell servers with Windows now. They've been trying to migrate some of these mainframe systems to server groups (not exactly clusters, each box has a role) with horrible results. The servers just plain and simple do not have the I/O capacity needed to process a government payroll

      • Re:IBM is trying the save a piece of his bizness (Score:5, Insightful)

        by QuietLagoon ( 813062 ) on Sunday September 25, 2005 @09:57PM (#13647942)
        Unisys knows their mainframe business is dying, and is pushing Dell servers with Windows now. They've been trying to migrate some of these mainframe systems to server groups (not exactly clusters, each box has a role) with horrible results.

        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).

        • I agree with you that Windows is most likely the problem. Most of the systems are being migrated to an Oracle on Windows setup. For nearly 3 months, the database servers would just randomly reboot. Now, we do have another system running Oracle on Solaris (Sun blades) which gives us almost no problem, except maybe every 6 months a corrupt index will pop up. I wish we would migrate at least our Windows DB servers to Solaris, but alas, Unisys is a Microsoft Gold Parnter and the only reason for the Sun machines

    • Re:IBM is trying the save a piece of his bizness (Score:5, Interesting)

      by deanj ( 519759 ) on Sunday September 25, 2005 @08:56PM (#13647671)
      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.
      • 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.

        I read the same post you did, and yet we draw totally diametrically-opposed conclusions. I think the parent poster was making a nice point about how the senior engineer really had a lot more of a clue than the young engineer, who was gung-ho on transferring a system to a totally different platform, with all of the inherent risks in t

  • I got out of mainframes 15 years ago (Score:5, Insightful)

    by Anonymous Coward on Sunday September 25, 2005 @06:39PM (#13647115)
    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.
    • Outsourced people would learn these skills.

      My mom worked in COBOL for decades and told me, with no slight amount of bitterness, that even offshoring firms' workers can do COBOL and mainframes work more cheaply than experienced American laborers could. In fact, as a potential outsourcee, you might make more money simply by distinguishing yourselves from the Java/C++/web-app programming masses.
    • ...are the AIX, HP-UX and Solaris systems running Oracle, Informix and Sybase (and to a fairly substantial degree also Windows boxes runnning MS SQL) server-side databases with Windows fat-clients. These are getting hideously expensive to maintain nowadays, even though they were just implemented a few short years ago when firms were told that these kind of systems were the "way of the future" and the only way to implement I.T. to avoid the high costs of doing things the "legacy way" with older, experienced,

  • Same old problem, different questions.... (Score:5, Insightful)

    by zappepcs ( 820751 ) on Sunday September 25, 2005 @06:40PM (#13647120) Journal
    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...
    • Your comments on the difficulty of developing a comprehensive and realistic disaster recovery plan are right on the money. In a complex organisation, it requires literally thousands of pages of documentation and you will only know if it really works if you arrange a (very expensive) test using different staff from those who developed the recovery plan.

      The only company I have worked for that developed a plan that would actually work was IBM way back in the 1970s. The first two tests of the plan, for the

  • And what about (Score:4, Interesting)

    by Mycroft_514 ( 701676 ) on Sunday September 25, 2005 @06:40PM (#13647126) Journal
    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.....

    • Re:And what about (Score:4, Insightful)

      by ucblockhead ( 63650 ) on Sunday September 25, 2005 @07:19PM (#13647293) Homepage Journal
      Schools shouldn't be teaching languages. They should be teaching programming.

      PL/I, Cobal and Fortran are not hard to pick up. Unfortunately, too many kids graduate having learned Java instead of programming (or almost as bad, learning only Object Oriented programming and nothing else), and so are helpless when confronted with anything that doesn't conform to the narrow view of programming that they learned in school.

  • Well.. (Score:3, Insightful)

    by thisnamewastaken ( 917498 ) on Sunday September 25, 2005 @06:42PM (#13647136) Journal
    I'm sure this article was posted here, but remember also that IBM is sending employees back to school [com.com] to learn how to become teachers. This program, from what I gathered, is aimed primarily at the 'older' workers, because they could afford a salary drop. Ironic?
    • I doubt its because the older workers can afford a salary drop, its much more likely that IBM is trying to shed older (more expensive) workers without firing anybody.

      Its traditionally how companies slowly reduce their workforce w/out firing, they just allow people to retire.

      This way, IBM not only gets them to retire, but gets them to retire earlier & gets mega PR kudos for free

  • Wow. The thermostat in Hell just clicked on (Score:3, Insightful)

    by FlyingSpank ( 589824 ) <robcamp&hotmail,com> on Sunday September 25, 2005 @06:47PM (#13647155)
    An article, published on IBM's site, shows the value in older workers.

    Mind you, of course, this is a non-IBMer writing the article, quoting ANOTHER work that states the opinion.

    However.

    IBM, which has been sued not once, but MULTIPLE times for age discrimination. A quick google will net you lots of links ...

    After having seen what IBM and other firms have done to older workers, and young ones just to keep the "deadpool" on paper appear balanced, I scoff.

    The only good discussion with an IBM manager starts with their head under my boot and a sawed off shotgun causing them to gag.

    A bit harsh ? Yes, probably.

    But given the people I've seen burn their savings, retirement, etc keeping the kids fed, cars paid, etc and compare their "relative value" to some fucking middle management hosebag ...

    Yeah. A touch grumpy.

  • Big iron (Score:3, Insightful)

    by Saiyine ( 689367 ) on Sunday September 25, 2005 @06:49PM (#13647166) Homepage

    That's the problem with big iron using ancient languages like Cobol [wikipedia.org], no young programmers do learn it nor use it at personal projects.

    --
    Superb hosting [dreamhost.com] 4800MB Storage, 120GB bandwidth, $7,95.
    Picaday!!! [picaday.host.sk] Strange & sexy pictures (Some NSFW!).
    • What you're describing isn't always a disadvantage. Working with an old COBOL system, it's relatively easy to hire, because you know that anybody who knows COBOL thoroughly, isn't an immature, young programmer.

  • Maintaining legacy Infastructure (Score:3, Insightful)

    by Batman64 ( 917205 ) on Sunday September 25, 2005 @06:55PM (#13647191) Journal

    It's also interesting to note that this idea also applies to the infastructure that keeps all of these mainframes/servers running. I am working in a state collge system in NY as a student worker. Since state colleges don't have as much financial backing as some of the private colleges, the infastructure isn't kept up-to-date as much. At times it can def. be a challenge to keep both the old and the new network technology playing nice together.

    I appreciate working in this system though because I have gotten to work with a great bunch of people that have been around even before the Internet. I have worked with many different types of network hardware that I otherwise wouldn't have had the chance to. As technology has been progressing I have watched my older co-workers go though many many training sessions on new technologies... many that I already know... but I guess it's also a type of training session for my learing how to keep thinnet kicking ;)

  • The 60 year old master jeweler, or his 30 year old assistant?

    It's not that the assistant couldn't make something, but chances are it's not going to be as good as the one made by the master jeweler.

    (... and, yes, there are exceptions).

  • . . . hire Sid [userfriendly.org].

  • It's not just IT (Score:4, Insightful)

    by Anonymous Coward on Sunday September 25, 2005 @07:07PM (#13647245)
    The comming retirement of the baby boomers will cause a loss of institutional memory in many companies. THe next 5 years are the start of the boomer retirement. What is going to suprise many is the smallness of generations X and Y. There just aren't enough people to fill the retirees slots.

  • Pretty good advertising by IBM... (Score:5, Interesting)

    by NeoBeans ( 591740 ) * on Sunday September 25, 2005 @07:14PM (#13647275) Homepage Journal
    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...

  • Agreed... (Score:4, Interesting)

    by Jeian ( 409916 ) on Sunday September 25, 2005 @08:05PM (#13647485)
    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!

    • Re:Agreed... (Score:3, Insightful)

      by tgd ( 2822 )
      Actually I think the real issue for who computing is "de-geeking" is not because people are being trained on the EZ-2-USE REVOLUTIONARY TECHNOLOGY OF THE WEEK, its because the hard number of truely qualified engineers hasn't really changed in the last 30 years. The number of people in IT may be ten times higher, but 90% of people who claim to be engineeers have fundamental (and fatal, from a professional standpoint) gaps in their experience, and make an assumption that those in the 10% who stick with the tr
  • As a self-described "outdated geek," I can ask with authority: Who among those here assembled know how to bootstrap a DG Nova or Eclipse minicomputer (the latter of which has dynamic microcode loaded from floppy at boot time), can ascertain file attributes on a DEC PDP11 with STAT, know the FAT protocols under RDOS, or how to load/run diagnostics from paper tape? Hell, for that matter, how to thread and mount a R-R mag tape transport?

    Yeah, I am a dinosaur, but a few of the sauropods on which I feed are stil
    • Who among those here assembled know how to bootstrap a DG Nova or Eclipse minicomputer (the latter of which has dynamic microcode loaded from floppy at boot time), can ascertain file attributes on a DEC PDP11 with STAT, know the FAT protocols under RDOS, or how to load/run diagnostics from paper tape? Hell, for that matter, how to thread and mount a R-R mag tape transport
      Do you work for NASA? Or maybe the IRS...

  • Previous experience (Score:3, Insightful)

    by Spy der Mann ( 805235 ) <spydermann.slash ... com minus distro> on Sunday September 25, 2005 @08:24PM (#13647556) Homepage Journal
    Someone i know had to give maintenance to a program written in xbase. Problem is, the author encrypted it and protected it against decompiling. Actually the problem is that the author can't be contacted anymore. So the best strategy was to reverse engineer the program (i.e. look at what it does) and do a complete redesign.

    I just wonder how much this will cost for large scale programs...

  • Wouldn't it be darkly funny (Score:3, Funny)

    by gelfling ( 6534 ) on Sunday September 25, 2005 @08:49PM (#13647639) Homepage Journal
    If Y2K finally came to us in the form of management indifference and negligence on the altar of efficiency?
  • Just re-read the article with the following change:
    "Many enterprises" -> "a few enterprises"
    and you'll get the idea why everyone is more interested in getting younger people with new skill on new projects that running existing things for which there is new and better competition everywhere.

  • A misunderstanding (Score:3, Insightful)

    by Veteran ( 203989 ) on Sunday September 25, 2005 @08:52PM (#13647655)
    Because managers are largely replaceable the assumption that they make is that technical people are also interchangeable and easily replaceable.

    This is simply not true, and it has to do with the Yin and Yang nature of reality. Engineering and Art are a Yin and Yang pair; at the heart of any art form there is a core of technical knowledge that the artist has to learn before they can make art. For example a painter needs to know how to mix paints and how brush strokes change the way art looks in light. Engineering is mostly technical information which the engineer needs to learn before he can do his job - however, in solving a technical problem there are literally millions of possible solutions to the problem. Some work better than others, and it is a matter of artistic choice which one the engineer picks. That is why leading edge solutions are called "State of the Art"

    Technical things can be taught, Art can't be. An engineer who is good at creating state of the art solutions to problems people don't know how to solve, is as rare and valuable as an artist is; neither can be easily replaced.

    • Re:A misunderstanding (Score:5, Insightful)

      by ScrewMaster ( 602015 ) on Sunday September 25, 2005 @09:31PM (#13647803)
      True ... but a good engineering manager who is capable of leading his team and establishing a work environment where such SOTA solutions are commonnplace is just as rare, and just as hard to replace. Good engineering and good management are not by definition adversarial, in fact they are complementary. And the bigger your development team, the more essential it is to have good management.

      It's not enough to just put a bunch of talented engineers in a room and expect results. No matter how smart they may be, engineers are people too, with their own distinct personalities, strengths and weaknesses. They can benefit from good leadership just as much as a platoon of soldiers. In fact, several times I've been surprised to find a fellow engineer whom I considered to be second-rate turn out remarkable work when given proper leadership and encouragement. Conversely, a bad manager can turn a roomful of Wozniaks and Hertzfelds into so many paperpushers. Speaking as an engineer who has been in both situations, I'm not inclined to dismiss management as irrelevant: but I will agree that the bulk of it is mediocre at best, and that pretty much guarantees mediocre engineering.

  • Looking at it from a different angle (Score:3, Informative)

    by Zzyzygy ( 189883 ) * on Sunday September 25, 2005 @09:21PM (#13647762)
    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
    • 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 we
    • I'm in my early forties, and I find it increasingly difficult to compete in today's job market

      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 worke


  • "via older software systems that run on large, mainframe computers rather than individual PCs"

    There are newer large mainframe computers.

  • When you get older.... (Score:5, Insightful)

    by deanj ( 519759 ) on Sunday September 25, 2005 @09:44PM (#13647847)
    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.

  • Maintenance Strategies (Score:5, Insightful)

    by anorlunda ( 311253 ) on Sunday September 25, 2005 @10:10PM (#13648021) Homepage
    There's more to it than senior versus junior IT workers. The following clips from the article help illustrate.

    "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.

    • 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.

      The answer is "No, for all practical purposes". The most widely-used OOP languages are not much more than str
  • ...to see the first of these type articles coming from Bangalore, India.
  • Misery is a legacy system written in Perl. COBOL is reasonably readable.

  • Training != experience (Score:3, Informative)

    by CrazedWalrus ( 901897 ) on Monday September 26, 2005 @05:40AM (#13649261) Journal
    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'.

  • because they can, even if they shouldn't (Score:3, Interesting)

    by paulsomm ( 92946 ) <paulsomm@panix.com> on Monday September 26, 2005 @07:25AM (#13649627)
    Instead, they mistakenly assume that they can hire younger, lower-paid people to perform the same tasks.


    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.

  • This is bigger than an IT problem (Score:3, Insightful)

    by tjstork ( 137384 ) <todd.bandrowskyNO@SPAMgmail.com> on Monday September 26, 2005 @07:50AM (#13649778) Homepage Journal
    I have a client that does a lot of work with power plants, and, all that organizational knowledge is going away because of attrition and retirements, some, admittedly forced. Now they realize that they have a huge problem with green employees.

    Sure, you can document everything, but, if a guy leaves with a 10,000 page document, as can happen in the power industry, what happens, if you have a question. A lot of things written down are written with a particular context in mind, and, if you don't have that context, then, you really won't understand what the document really means even if you do understand just that document's sentences.

  • The Clueless Suit Culture (Score:4, Interesting)

    by vacuum_tuber ( 707626 ) on Monday September 26, 2005 @12:52PM (#13652082) Journal

    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

Slashdot Top Deals

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Close