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

Comments

Anyone can do this job

[totallygeek]

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

[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 a whole other discussion ;) but really, there's no point running a legacy system if newer systems can handle what you're already doing, and them some++ - in which case, take a course, invest some time and money, and retrain.

Business and management really need to make the hard decisions, invest little cash in getting their systems documented, ensure those docs are updated as a matter of company policy and chastise technical staff who don't adhere to those policies and frameworks. Business is business, not sysadmin la-la land.

Re:Anyone can do this job

[bladesjester]

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

Re:Anyone can do this job

[Laz7]

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.

Re:Anyone can do this job

[Kadin2048]

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.

Re:Anyone can do this job

[bladesjester]

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

[Kadin2048]

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 make the set-up processes (getting an automated machine ready to run the CNC program that will make a part) or the programs themselves more efficient, either didn't share their knowledge or didn't apply it fully. Certainly it wasn't passed up the chain of command to be implemented widely -- why would somebody want to do that, when their little 'tricks' might be the only think keeping them employed?

I expect that this is probably still a problem, and I don't have any easy solutions. In the programming world, where the coding itself is -- at least to managers -- at least as much of a black art as machine operation, and there is perhaps even more danger of having your job outsourced to India (in the machine tools industry it's China), there's a strong incentive to create miles of uncommented, byzantine code.

It's not until managers understand the reasons behind this behavior and start rewarding documentation with advancement and most importantly job security, and build a relationship of trust between employees and themselves, that they'll get the best products their employees can produce.

Re:Anyone can do this job

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

Training

[kevin_conaway]

The younger, less experienced folks CAN perform the same tasks. Its called training.

Keep good documentation and any competent person should be able to get up to speed in a decent amount of time. Otherwise send the person to IBM/$PLATFORM training.

Re:Training

[Pichu0102]

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.

Re:Training

[Fitzghon]

I think you misunderstood the article (did you read it?)
Companies that hire young tech people need to train them to use the mainframe apps. The article points out that this is a losing situation, because the company went from having an experienced and trained worker to an inexperience worker that they have to train.
Consider it this way: a company's tech guy gets hit by a truck, they have two candidates to hire from:
Candidate A: Has no knowledge of the platforms being used in the company, has no experience with similar systems.
Candidate B: Is familiar with the platforms and has extensive experience with similar systems.
Who will the company hire? Candidate B of course!
The problem is that companies are now firing Candidate B because he is old and hiring Candidate A because he is young. Is it a worthwhile decision?

Fitzghon

Re:Training

[Anonymous Coward]

This is a patently naive perspective. Not that there aren't older workers with minimal competence who have managed to hold on one way or another to jobs over the years, but in general an experienced professional is going to have a lot more work-related wisdom than a new hire. That's why they've been kept with the company over the years. IBM generally only hires entry-level people, not experienced professionals, and isn't proficient at assessing whether the new hires are competent or not. There is a widespread misconception there that anyone can be trained to do a technical job. If you had any experience whatsoever with the general workforce, you'd know only a fraction of the people applying and/or hired for technical positions are actually extremely competent.

The bigger truth, particularly at IBM, is that an older worker (read that closer to retirement) is a much bigger liability because of the cost of retirement to IBM.

It's also the case that most IBM managers have short term, personal goals at stake, rather than the welfare of the company. And their widespread inability to accurately assess the productivity of their employess makes it impossible to justify someone that has a 2x salary versus a junior programmer. It's like their corporate-wide Cost Cutting programs back in the 80's & 90's that did away with lesser-paid secretaries, support personnel and office supplies at a tremendous savings to the company. That meant their programmers and managers (only the executives were left with secretarial support) spent their time searching for non-existent supplies, or running to Office Depot, and managing more logistical tasks. They had no way to measure this impact to the much higher-paid employees, and so considered this major impact to productivity a cost savings.

Why don't you read The Mythical Man-Month (which ironically of course, was written by an IBM-er)?

Re:Training

[lordperditor]

What a crock.

You can't seriously think sending some youngster on a training course is going to replace the 20-30 years of experience and knowledge of an older senior staff member.

Yes they may manage to get by, if it all goes well, but when it goes pear shaped you are gonna wish you had that more experienced staff member around.

I once heard a good definition of an expert:
An expert is someone who has made all the mistakes there are to be made in a particular field of expertise.

Sending a youngster on a training course is no replacement for years of experience.

What usually happens...

[Dekortage]

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.

Ask a relevant question

[Anonymous Coward]

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

[slavemowgli]

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

[Now.Imperfect]

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.

Re:Ask a relevant question

[taloobie]

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 interested in the problems they are working on. Generally most problems will require anyone to train and learn.

Re:Ask a relevant question

[SillyNickName4me]

It's a fact of life - regardless of if someone likes it or not.

No, it is a matter of choice.

When a project development effort gets behind schedule or an important customer has serious problems, the developer who continues to work 5 days a week, 9 hours a day due to outside obligations just isn't as valuable as a similarly skilled and experienced one who puts in the extra time to address the customer problem and/or help deliver the release (with the essential functions intact and working properly) on time.

That is true, and complete lack of flexibility on either side in this is bad.

The issue is that in many companies I have seen this quickly turn into an almost mandatory 10+ hours workday, and 7 days/week being more the rule then the exception as a result of management actually counting on this already with their planning.

Companies where I saw that include Electronic Arts, Siemens, GM, Pixelworks, Intel and some other less known ones.

The problem with this is that someone who is not able to keep up a normal social life, get enough rest and distraction etc, is after a while going to bve less productive and less creative, which just increases the chance of not delivering in time or not meeting the functional requirements.

If it is the exception then it is no problem at all, especially not when a company also compensates for it when things are less stressed.

As a manager, I try to be as flexible as possible to accommodate developers' outside obligations. But, if a developer is routinely unable to respond to a customer crisis or figure out a way to adjust their personal schedule so they can work with other team members to resolve critical path problems in development, obviously at review time (and off-shoring time, and cost reduction time) this developer is remembered as one that I can't rely on as much.

In my experience, this is really rarely a problem since the best developers truly enjoy what they do and are engaged and want to do the best job they can and figure out how to juggle their personal and professional lives.

As long as you keep a proper balance between such demands and also giving people a bit of extra time for themselves when things are more quiet, don't use it as an integrated part of your planning (hello EA) and it is indeed the exception for emergency cases, then it can work very well for both sides.

One needs to think both short and long term. The only ways I know of to meet all schedules every time without extra work is to either sandbag schedules or to refuse to commit to a schedule until a substantial percentage of the project's development budget has been expended on detailed design. Neither is efficient or practical.

This is a perception problem that only persists because people accept it being there. You cannot tell for sure initially, so do not act as if you can. That solves the problem pretty well.

Some jobs of course don't require additional effort beyond 5/8 - but the one time I worked at such a place (a major aerospace firm over 25 years ago when I was still in school), I was bored stiff and left for a more interesting job in a more dynamic environment - YMMV.

Dynamic is fun I think, and I work at very odd times often. I do however make sure that my average stays at around 40 hours/week and that I do normally have a weekend. There are exceptions, but those are exactly that, exceptions.

I got out of mainframes 15 years ago

[Anonymous Coward]

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.

Same old problem, different questions....

[zappepcs]

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

Well..

[thisnamewastaken]

I'm sure this article was posted here, but remember also that IBM is sending employees back to school 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?

Wow. The thermostat in Hell just clicked on

[FlyingSpank]

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

[Saiyine]

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

--
Superb hosting 4800MB Storage, 120GB bandwidth, $7,95.
Picaday!!! Strange & sexy pictures (Some NSFW!).

Maintaining legacy Infastructure

[Batman64]

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

It's not just IT

[Anonymous Coward]

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.

Re:And what about

[ucblockhead]

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.

Previous experience

[Spy der Mann]

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

A misunderstanding

[Veteran]

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

[ScrewMaster]

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.

When you get older....

[deanj]

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.

Re:IBM is trying the save a piece of his bizness

[QuietLagoon]

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

Maintenance Strategies

[anorlunda]

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.

Re:Maintenance Strategies

[ciggieposeur]

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 structs-with-function-pointers with some syntactic sugar on top. May as well just use C and pass function pointers around like the Linux kernel does. The "real" OOP languages are not as widely deployed as Java or C++, and the skillset is definitely not everywhere. Furthermore, OOP solutions work well when systems can be thought of that way, and not all systems should be.

The real "problem" is that spaghetti code to cover the corner cases must creep in over a product's lifetime, and the knowledge about how (and when) to refactor that code is dependent on experience with the system the code is tied to.

How indispensable?

[mcraig]

As my uncle who worked for a large engineering firm used to tell me, next time you feel like your indispensable go and fill a bowl with water, stick your finger into it, remove it and the hole thats left is how indispensable you are ;-)

Re:Agreed...

[tgd]

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 tried and true and scoff at newer "fads" are "dinosaurs". (hello? AOP? What real engineer doesn't get the heeby-jeebies from the thought of a "typical" engineer pointing THAT gun at their head?)

Give it ten or fifteen years and you'll start to see the problem that represents is a lot more serious than you even thought. There's a fundamental problem in software engineering today with people understanding what the real priorities must be when writing software. Too many people want to blame that on the "PHB", which is a deliberately degrading way of putting down people who have a different set of priorities than the engineers.

The problem the older employees have isn't a culture where the company doesnt' value their expertise, its that they, by the mere fact they're still doing technical work, stayed out of management... and their managers are probably engineers from that 90% pool that didn't "get it" when they were writing software and definitely don't get it once promoted. And those managers are responsible for communicating their needs and priorities up the chain.

This is bigger than an IT problem

[tjstork]

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.

Re:the bad part abt this argument is

[vacuum_tuber]

No, the problem isn't that new guys can't have a chance if old guys are not shitcanned like yesterday's newspapers. Both can work side by side. That should be the natural way of things... the new guys come in and learn from the old guys how things work. Gradually, over time, the old guys retire or die off and the new guys become the old guys. Technologies advance along the way in a rational manner.

The problem today is that business managers don't understand that IT is not the same as plumbing or electrical stuff. The enterprise computing system is not like the office copier. Combine that with a preoccupation on following IT fashion trends and you get insane shops where solid systems are replaced by tinkertoy houses of cards that become unmaintainable and lose key personnel before they are even completed. DP is fundamentally DP no matter what pretty front end one may try to put on it. To think that DP is well handled with new tools like OO stuff is to miss the point: the business of business is expressed entirely in ordinary characters making up fields making up records making up files. Even with the fanciest user interface on it it's still all about simple characters. Building the business processing in C or C++ has to be one of the most stupid trends ever to have developed in IT. Using databases where the main "benefit" is an open door to endlessly complicate the straightforward business of business is not too bright, either.

I blame a lot of it on the ascension of the "professional manager." You know them... they are proud of their ignorance of all things technical. They hold status meetings that consist of going through last week's list of open items, checking where each item stands, closing items, opening new ones, adjusting expected completion dates, and adjusting responsibilities. A monkey could do that. If anything remotely technical creeps into the discussion of the open items, their eyes glaze over with an audible crunching sound.

I blame another big part of it on the ascension of the bean counters. Back when business ran pretty well, the bean counters were hidden somewhere in the back, wearing green visors, keeping track of where the company had been. An old friend once likened accounting and bookkeeping to the view out the back window of a car. If you steer looking out the back window, you'll wind up in a ditch. Now that we have CFOs with a voice in running companies, a lot of companies are being steered by the view out the back window and are running into ditches.