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

[B3ryllium]

"What if you get hit by a Mack truck?"

Answer: I don't use Macs ...

Re:Anyone can do this job

[BiggerIsBetter]

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.

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

[Anonymous Coward]

What an appropriate title - Keeping the lights on! I work for a company who was associated with the blackout two years ago. The "old mainframes" performed flawlessly, while a newer server type system got much of the blame. I'd like to think that the older systems kept running because of the older workers that had the experience to keep things in tip top shape. Given all of the downsizing, rightsizing, and dumbsizing, it is a wonder how any company is running as well as it could. Many corporations bitch and moan all the time about who much health care costs for its employees, yet will spend unlimited amounts for stock options for a few clueless people at the top to keep "qualified individuals". Most people don't realize how fragile the current electric system is in this country and I see that the politicians don't either. Keep a generator handy folks, and if your lights go out, blame downsizing by the utilities for trying to squeeze the numbers to make Wall St happy. You heard it here first.

Re:Anyone can do this job

[BiggerIsBetter]

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?

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

[Tablizer]

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

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

[Safety Cap]

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 response: the PHB-patented blank stare.

I can't wait for the documentation request - it is going to be the flowchart from hell. I will use the 36" (91.4 cm)-wide plotter and about 10 feet (3 m) of paper, all printed with 10 pt text. Bwah hahahah!

Re:Anyone can do this job

[bladesjester]

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

Re:Anyone can do this job

[CheapEngineer]

I'd *really* like to work in the world you work in.

You know, the one where there's *time* to write *anything* down, before the next forest fire erupts.

How *are* things at the University?

CheapEngineer

Re:Anyone can do this job

[darrenadelaide]

It still amazes me the amount of times clients have asked me the same question.. getting hit by a bus.. no, we'll go with a big company instead.. only to find two years down the track they have a system which doesn't work and the big company been taken over or closed or the people employed there have no idea or intent of fixing the problems. As a long suffering veteran of the industry (20+yrs programming) I see this time and time again, these days coding has become gui but has lost its first requirement of making something which will do the job, easily and understandable for any programmer to pick up and actually understand what is being achieved. How many times have we all been called in to fix a problem in some code (usually c / derivatives ) to find it takes us many hours to understand the intent whereas it has nothing to do with the desired result. They might teach coding, but not common sense or learning what the needs are first. W Edwards Demming must be turning in his grave. Just my 2c worth

Re:Anyone can do this job

[Anonymous Coward]

err - excuse me??? They wouldn't tell the production staff to forget about QA?
Sounds like someone needs to get a little practical experience working in a development environment.

Re:Anyone can do this job

[Hercynium]

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

Re:Anyone can do this job

[eric_harris_76]

Oh, yes. Absolutely.

When The Powers That Be lay off a bunch of people to make a short-term profitability goal, do you think the undocumented or partly-documented processes and code and such are on their minds? Are they even aware that there is anything to document? Possibly not.

So when the now-understaffed (or more understaffed) folks have to fix or enhance something they haven't touched before, something that lacks documentation, it takes them longer and they don't do as good a job. It works inefficiently or unreliably or both. Code becomes a nightmare to maintain because the ones who knew it best wouldn't have made decisions the ones who actually did make the change did. Good code gets mediocre, mediocre code gets bad, bad code gets nightmarish. (I could tell you stories, and I haven't even seen that code. Word gets around. I'm told one part is 17K lines of unstructured COBOL, with multi-line deeply nested IF statements -- lots of them, with complex conditionals.)

But to look on the bright side -- if The Powers That Be don't know that the application's documentation is important, and becomes more important after the departure of those who know the system from personal experience, it doesn't hurt to be professional and document what you have done. You won't be any more a layoff target than those who think they have made themselves indispensible by keeping their knowledge a secret. Wally and Dilbert are equally likely to get the boot. (Not that Wally actually knows anything worth documenting, anyway...)

So I'm not going to tell TPTB. No sense adding to the work environment a strong disincentive to document your work. I like doing The Right Thing. -Eric

P.S. A year or two after a round of layoffs at one employer, there seemed to be a flurry of articles in the business press about the importance of "human capital", the vital business knowledge carried in the heads of employees which is never documented and may not even be recognized as such. What to do in such-and-such a situation. Why it's a terrible idea to do what seems obviously the right thing to do about the monthly whatever process. And so on. The unstructured knowledge that comes from experience.

You know, the stuff known only by the staff -- or in some cases, ex-staff. -ESH

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.

Re:Anyone can do this job

[Bill Dog]

But if you have nothing else to go by, even bad documentation can often be of some help. As somebody once said: "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing."

Re:Anyone can do this job

[speculatrix]

I have been asked for years, "What if you get hit by a Mack truck?"

I recall one company asking their sole programmer on their key product this and what would happen to their software maintenance. He replied "I don't care, I'll be dead"!

Re:Anyone can do this job

[avasol]

Apparently you haven't been following recent scientific trends but the answer is obvious to anyone who's a big fan of Arnold. Clone yourself. Then go on a rampage fighting your clone. And destroy millions of dollars worth of property not to mention personal liability. But that's why there's insurance. See? You're just not getting the entire picture.

Re:Anyone can do this job

[cerberusss]

you often don't *have* an afternoon to sit and write documentation

This way, you make documenting or not your decision, when actually it should be your manager who prioritizes such issues. Your ass will be on the line.

Example from my workplace: I work as a developer in a team of nine, working on two projects. When the guy who does the deployment is on a holiday, someone asks: "who can do a release?" No one, because he's gone. The deployment is still done, but it's a major mess.

When he comes back, I bring up this point in the weekly meeting: deploying the application should be documented. The teamleader says: "I'll get back on this". Then it takes three goddamn times that I bring up the point before it's done -- and the teamleader is pissed off at me. But time is allocated after all!

When management doesn't listen and the shit hits the fan, you can say "I told you so" (but you don't need to).

(And yes, deployment should be one button. But it isn't right now.)

Re:Anyone can do this job

[Scarblac]

We like to call ourselves professionsals, but compare our jobs to that of, say, a mechanical engineer.

The work is similar to that of an architect/builder, and we're managed by people who think it's similar to that of a brick layer.

"What do you mean, you don't know exactly how you're going to do it yet? Didn't they teach you that?" (right after telling me about some vaguely specified new project that preferaby has to go live this afternoon, that the marketing people have already sent letters about to customers but failed to inform us before now)

Re:Anyone can do this job

[flyguy79]

An engineer who jumps on the lathe and starts welding

If you're an engineer who 1) jumps on a lathe, or 2) welds on a lathe, you have bigger problems than documentation...

Re:Anyone can do this job

[SillyNickName4me]

Interestingly enough, my currently biggest customer insists on documentation (and I fully agree with them opf course).

They have a well working process for creating, reviewing and maintaining it, assigned backup owners of all documents, and are generally prepared to pay for it. For my latest project there, they reserved almost 30% of the budget for it even.

But well.. they are exceptional in this, for most of my customers documentation is an afterthought at best, scary when realizing that they are leaving implementation to contractors like me who will be gone once the project is done and things run (tho it is in a way good for me, they often have to get back to me when wanting to change things, and that means extra hours to bill for me :)

Re:Anyone can do this job

[bladesjester]

Unfortunately, at one point I spent more time finding out that the documentation was wrong and then trying to figure out which parts I could trust than it would taken me to just figure it out on my own.

That was not a fun day.

Re:Anyone can do this job

[smcdow]

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

Good idea, except that in most organizations the documentation would be out-of-date as soon as it was completed. We'd spend more and more time making sure that the documentation was up-to-date and less and less time getting work done.

No one will argue against the idea of keeping good documentation, but the reality of the situation is that, often, it's a Sisyphean task.

Re:Anyone can do this job

[inKubus]

Sadly, that time is not always provided.

Do it anyway: if you're running around with your head chopped off, the department will be expanded soon. Get your stuff documented and it will save you time later. I don't know how many times I've had to go out on the internet and spend 5 mintues downloading a common driver that I should have had on the network already. With proper planning and documentation, you can have everything you need at your fingertips, stuff you wouldn't have thought of in the first place. So work harder now, don't worry so much about the day to day stuff, and you'll build yourself a great little position in the company where you can solve just about any problem so quickly that you hardly have to work at all.

If you are running around with your head chopped off, your system is not set up correctly. Computers are supposed to make life easier!

Now, I know what you're about to say; "users", "managers" etc. Don't worry about them. Close out the help desk calls without talking to the user. You can do about 1 in 10 without risking retribution. Ignore stupid management requests. Blame miscommunication. Buy time where you can to get your system set up correctly and don't sweat the details. Don't read slashdot for a few weeks.

You can do it.

Re:Anyone can do this job

[thomasa]

I have always been asked, "What if you get hit by a beer truck?" Sometimes it has been, "What if you win the lottery?". I wouldn't mind the lottery thing.

Re:Anyone can do this job

[bladesjester]

If you check, my origional comment was posted at around 8pm. I think that qualifies as being "after work".

Re:Anyone can do this job

[Anonymous Coward]

This might come as a shock to you, but on this planet there are what we call "different timezones", and "different countries". Surprisingly enough, this comment was not posted at 7:30PM.

Re:Anyone can do this job

[vacuum_tuber]

these days coding has become gui but has lost its first requirement of making something which will do the job

Quite so. I know of a case in which a Java weenie group was called in to make an attractive and usable front end for a Wang VS mainframe app. Their starting point was, "We don't know anything about your mainframe so you'll have to export your data every night and stuff it into an Oracle database so we can access it." OK, that wasn't great, but the client went along. The Java weenies proceeded to burn up months of calendar time and six figures of fees, after which they turned over something purporting to be a functional applet front end supported by their server back end.

On first connection, a user was presented with a dire warning message in English, not the language of many of the client's remote users. Ignoring the warning and proceeding, the user was treated to a multi-megabyte download, never mind that many of the users were on dialup connections in third world countries.

If and when the applet finally got to run, it presented a spreadsheet-like arrangement of the data with incorrectly sized columns. In the view of the Java weenies the user could just drag the column dividers around to suit, but on every new connection it initially came up wrong and always had to be manually adjusted just to see the data.

But the real hoot was that when the user dragged the column dividers around, the screen blinked multiple times like a strobe. The Java weenies blamed that effect on the version of Windows the client had selected as the corporate standard. That was proven to be a lie when the client's people traveled and made use of every known type of platform and OS in airport lounges and found the strobe effect to be universal.

The project was terminated and the client called me for a one-day onsite consultation. In that one day I showed them how to manage HTTP sessions in the Web server on their Wang VS mainframe and in one additional day made a minor change to the Web server to provide a small missing piece necessary to completely support session control.

In the couple of months following that consultation the client easily implemented exactly what they had originally wanted, entirely in CGI, at a tiny fraction of the cost of the failed Java project, and went on to implement credit card payments and clearing house authorization in the same mainframe. They suppported their user interface in real time from live data and didn't have to support another box and database or do nightly file transfers to work around the ignorance of the Java weenies and serve up stale data. They were completely satisfied with their fully integrated solution.

My point is that some of the weenies running around pushing trendy new technologies aren't even capable of implementing what they're selling. Even when they can, their solutions are unlikely to be integrated, as they don't want to dirty their hands or minds with proper interfacing to existing technologies. Proper integration, though, may produce far better results without the new technologies than what the anti-mainframe weenies are peddling.

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

[jellomizer]

Just sit there and believe that, while you watch the infrastructure go down the tubes. Most of the training for any platform is more to advertise it then to really teach how to use it. Someone experience know that not everything that is documents that should work will work. An example an Old Prime Mainframe of a particular OS level supports TCP/IP and all the documents show that the system when the Gateway is set it will be used to get out on different subnets but in reality also you can enter in the gateway address it never uses it, and stays in its subnet, when these systems were made the internet wasn't very popular and TCP/IP was use for intranet usage, no one needed to go to a different subnet until Prime went out of business, when the internet became more useful. So all the training and reading the Prime books tell you that this will work all fine and dandy but in reality it doesn't work. Experience would save you many hours tinkering with the system trying to get it to work right vs. Using the knowledge that it doesn't work right and spending the time on a good workaround. A work around could take 8 hours, vs. Trying to get it to work could take weeks until you gave up and went to a work around.

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

[guyjr]

What's really ironic is how self-referential the article is, without deliberately stating so... i.e., IBM does this sort of crap every day. Hypocrites.

Re:Training

[Breakfast Pants]

I would hate to work at a place that had you on documentation. You overuse commas and refuse to break things up into logical paragraphs.

Re:Training

[McSmithster]

Training, you call what they give new people training? Most training is horrible these days and a lot of companies expect you to be able to start work with minimal training. For example, have you ever had to learn how to use a totally new AutoCAD system over a weekend??? Well I have and its not very nice. Oh sure I got it in about a week but about 4 months in I was still learning new things as they cropped up cause I received only 2 official hours of training on it. Thank god it was only a summer job.

It's the same with IT. Your company may be different but most companies have a bunch of inexperienced guys giving poor training to even more inexperienced college grads. Good training went out with the 80s and I don't foresee it coming back anytime soon

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.

Re:Training

[oddbudman]

This thread reminds me of one of my favorite quotes, goes something like:

"Experience is something you get after you most need it"

Nuff Said

Re:Training

[Antique Geekmeister]

Why, yes. A young person could learn what I've learned. It would take 5 years of dedicated, training-only workttime to learn what I've picked up twice that amount of hands-on and development, especially the lessons of "don't buy from these guys because they lie", or "how to make friends and contribute patches to important software projects so that your requests for fixes are taken seriously".

They would of course be unable to do anything else while trying to learn it at such an accelerated rate, and at the end of that time, they'd be as much of a problem for political middle managers because they'd be worth one heck of a lot of salary and tell their managers why some things can't be done, and why others will cost more than they budgeted, and why the unpatched laptop that the president uses to telecommute is a big security hole. Tjem they'd leave, because they think they can hop elsewhere as a new person with that incredible set of skills and qualifications.

Wait! I already do all that work! Why don't we save the 5 years of doing nothing for the new guy who will flee when he gets married or decides to become a nun or make other life changes, and let me do my job?

Re:Training

[Anonymous Coward]

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?

That one is easy. As you get older, spend a few hours a week trolling around in a mack truck for Candidate As.

Re:Training

[Lumpy]

The other problems are that Candidate A is fresh out of college and has a bunch of certs t oflaunt while Candidate B has actually worked in the field for 20 years does NOT have a CS degree or any certs but has held IT positions and even higher level IT positions and has the knowlege and experience that even a doctorate in CS can not touch.

they still hire the greenhorn fresh out of college because he will take the paltry 35 grand a year. ewhile candidate B knows that the position is worth $52,000.00 and will not take less.

the people that make hiring and firing decisions in todays corperations are idiots and morons. HR does not know squat about IT/IS the director of operations does not know SQUAT about IT/IS it's the IT/IS manager and staff that knows and that also would rather have the seasoned vetran that can jump in and start running within 3-5 days instead of the fresh college grad that will take a minimum of 30 days to unlearn all the BS as to how it's "supposed to work" as taught by his/her instructors and how it really works.... I.E. "I do not care that it is a really nasty hack and a giant security hole. deploy that application tonight sothat sales can use it in the morning." the "I can fix it later" though pattern is a fallacy as you will NEVER get a chance to fix it later, they will have more critical deadline emergencies for you. Proper planning and doing things the right way is not an option in reality unless you have the balls to say "no" to your boss, your bosses boss, and the regional VP when he comes down and asks you to drop everything and work on his pet project.

say NO. these people need to knw that you can not write 27 things at once perfectly within 20 minutes. They need to be slapped in the face with the reality that it takes time and it takes even more time to do it right.

Alas, too many of us in IT/IS are such kissasses that we promise the world and work ourselved into the ground for nothing. if we work all night to meet the manager's deadline you certianly will not see them stand up and say "we made it because of ______'s dedication and excellence!" nope no way in hell.

Although they do get a little pissy with me as I put my name and office location on the bottom of every form and GUI window in a "written by..." makes it harder for them to take all the credit when their name is nowhere to be found on the app.

The seasoned vetrans that know the older stuff should be at the top of the list, and management needs to get a clue that IT is not the bargian basement.

Re:Training

[Viol8]

Perhaps english isn't his first language.

Re:Training

[theonetruekeebler]

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

Yep. Two or three younger, less experienced people can usually perform the tasks in four or five times the time---after they've fucked it up six or seven times.

Keep good documentation and any competent person should be able to get up to speed in a decent amount of time.

Spoken like a soldier who's never been shot at. That "decent amount of time" is called a career.

Sometimes the documentation is written with an experienced audience in mind. Sometimes it's written on the assumption that you already know the basics---"basics" in this case being what you pick up over the first decade. And sometimes---important, career-defining times---you're dealing with things that just aren't documented. Like stuff from third-party vendors. Or for an infrastructure that's decades old. Or problems solved by folks who had already been there ten or twenty years, to whom the solution was so bleedin' obvious it down didn't even occur to them to write it down.

About fifteen years ago a bunch of very clever MBAs---who are usually more interchangeable than janitors---decided that the major RBOC they managed could save a whole lot of money if they "incentivized" their most senior employees into early retirement. So they offered them very generous severance packages and most of them left. Within months the infrastructure started going to hell---badly enough that even the MBAs could tell something was wrong. Subtle problems began to creep up---problems that employees with only fifteen years experience couldn't figure out how to fix. So the newly-retired employees got together and formed consulting firms---and their former employer paid them an amazing hourly rate. It was either pay them or face the choice of letting the current infrastructure collapse or "re-engineering" it at a cost that exceeded the market value of the company. They had already spend two billion dollars studying re-engineering, after which it was discovered that many problems already solved should stay solved the way were solved, because Ghod help you if you unsolved them.

"Why don't we get rid of all those old farts? They never seem to be doing anything." Sounds like the start of one of those wonderful Zen koans where the neophyte discovers that what the masters are doing is so subtle that he'll need half a lifetime to even see it, and the other half to get there himself.

Re:Training

[mhroge2]

that may be the most poorly executed attempt at English I have ever seen. Maybe we SHOULD be hiring outside people to do our documentation. Lord knows we can't.

-This is why they make us learn other stuff in school besides CS.

Re:Training

[hughk]

Similar thing happened in the airline industry. They decided to early retire their expensive managerial staff.

An airline is just a specialised logistics business - with pieces of kit that cost millions of dollars and marginal profitability, so little room for error.

For the airlines, they rely on computer models, but the models don't cover all situations. When things go wrong, such as a major hub closure, the managers left have insufficient understanding to do anything without assistance from the models. Hence an airline left with planes and passengers in different places and no easy way around it. With the huge costs involved, aircraft leases, landing fees and everything else, the airline runs out of cash quickly.

Sure that 30 year old manager looks cheaper than the 50 year old one, but who is going to fix the unusual situations?

The answer is really the same as we should have in IT, to blend youth with experience.

Re:Training

[Grishnakh]

I'm a younger (7 years exp) engineer, and I've been sent to all sorts of expensive training courses by my current employer. Here's my view of them:

They're mostly expensive vacations. We don't have to do any work for a week, we sit in a boring class, and learn very little about the subject matter. Don't get me wrong, with a decent instructor, you can learn a fair amount to get you up to a very minimum competency faster, but it's probably only worth a month or so of sitting around trying to figure it out yourself by reading books, maybe less. It doesn't in any way compare to years of experience.

Since you only work on simple examples and such, you really don't get or retain the type of knowledge that you get on-the-job doing real work, and making mistakes and learning from them.

Re:Training

[Anonymous Coward]

Wait, wait. First you talk about the mythical "documentation", then you go on about the fairy tale called "training." I thought we were talking about the real world, not some story you tell children.

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.

Re:What usually happens...

[scanrate]

Uh yeah. I'm still waiting for that phone call. A year and a half later.

Re:What usually happens...

[Anonymous Coward]

True story:

The local IBM technician who worked on all our old printers and iSeries was nearing retirement with IBM. So he got laid off with nine months to go. Is this the same IBM?

Of course, what they didn't notice was that he had enough PTO to carry him past his retirement date, so he ended up getting it anyway.

Re:What usually happens...

[mjensen]

Did to me.

Was laid off, but I wasn't angry. Budget cuts. They called me in about once a month as a consultant for something I hadn't documented yet, or something only I had experience with.

Now they hired me as a consultant in a different department at consultant rates, and are trying to change the budget to hire me back for real. I said I'd consider it.

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

[oliverthered]

fresh out of training and knows the latest techniques

Your pushing it to assume that schools teach the latest techniques, even the articles in Dr Dobs seem to be a year or so too late to be 'the latest thing'

Re:Ask a relevant question

[kilodelta]

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.

Re:Ask a relevant question

[LookAtTheMonkey!]

That depends, of course on my evaluation of the surgeon. Not my evaluation of their age.

My experience with doctors indicates that it's a wash. Older doctors have their way of doing things, and may not be up on the latest techniques and treatments. Younger doctors have less experience, but are trained on the latest techniques.

A bad doctor is a bad doctor, regardless of age.

What do you call the guy who graduates last in their medical class?
Doctor.

Re:Ask a relevant question

[geekoid]

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 medical equipment, even if there computers are old.

However, I wouldn't want to delute your 'new is always better' attitude with facts and real world examples.

OTOH, you have more fingures

Re:Ask a relevant question

[QueenOfSwords]

How about both? The young doctor can be advised by the older doctor.

Re:Ask a relevant question

[Biogenesis]

Or how about the young one who's up to date with the latest medicine or the older one who's experienced but still believes that any half infected limb requires amputation.

Re:Ask a relevant question

[uncqual]

Number of surgeries is not a qualifier in of itself.

No, but it can be one of several very important factors. Probably if one doctor has performed a particular surgical procedure 100 times this year while another has performed it 200 times on patients in similar circumstances and with similar support staff & equipment, the difference doesn't matter much. But, if one has performed the procedure only five times in the past year while the other has performed it 100 times, the difference is significant. Obviously this applies only if both the doctors are of similar intellectual capacity and both care about what they are doing.

I find that age and length of career has no correlation to the quality of work coming from techies.

My experience is quite different than yours (albeit, I've spent most of my life at startup companies where we could usually pick and choose developers carefully, so we may have very different experiences).

If you are comparing the best-of-the-best from both the "more experienced" and the "less experienced" techie groups, it's been my experience that the "experienced" developers are much more effective at some things - such as tracking down very difficult to diagnose concurrency problems, complex architecture, designing for RAS issues, and prioritizing customer needs against development principles. On the other hand, I find the less experienced developers are more inclined to learn the details of the latest language, tool, interface, or whatever (the more experienced developers seem to be a little less interested in learning every detail of YAD [Yet Another Debugger] unless there is something really unique about it). Also, as techies gain more experienced (aka "older"), they sometimes pick up more family obligations which result in them being less willing/able to work the seventh day of the week or the 15th hour of the day - to the extent that their experience doesn't compensate for this tendency, the more experienced developers lose out.

Re:Ask a relevant question

[Now.Imperfect]

I'm just sticking to the doctor analogy. The article talks about old equipment and what-not and that's gonna be obsolete eventually. companies will need someone to atleast have some initiative to keep things somewhat current. I don't see why they wouldn't hire a newer technician. Its all an analogy, don't take it literal plzkthx

Re:Ask a relevant question

[Anonymous Coward]

his age does effect his way of thinking

"affect".

To the Slashdot editors and coders:

Slow Down Cowboy!

Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 31 minutes since you last successfully posted a comment

Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form.

No, I'm not behind a fucking firewall or proxy, and I didn't click my fucking "Back" button. What happened was that you fucking idiots don't fucking tell me in advance (when I fucking click the fucking "Reply to This" link) how fucking long I have to fucking wait to fucking post. Instead, you wait until I have composed my reply and try to submit it, and only then do you tell me that I should have waited longer. This is totally fucked up. If I didn't have ad blocking turned on, I would email your advertisers and complain about how you treat people who post anonymously when they post useless crap because they are afraid to compromise their kharma.

Oh, and when the fuck are you going to fix the punctuation in your obnoxious message ("It's been X minutes since you last successfully posted a comment" should end with a period/full stop, you stupid motherfucking hamster fondlers)?

Please note that the above is meant to be friendly helpful criticism, and interpret it in that spirit. Thank you.

Re:Ask a relevant question

[SillyNickName4me]

they sometimes pick up more family obligations which result in them being less willing/able to work the seventh day of the week or the 15th hour of the day - to the extent that their experience doesn't compensate for this tendency, the more experienced developers lose out.

Ah yes, god forbid that employees have a life, and actually also take the much needed break at regular intervals...

If you really believe what you just wrote then I bet that you never look further then a few weeks or at best months.

Re:Ask a relevant question

[Now.Imperfect]

lmao! I'm a 17 year old whos had no training to speak of other than what he's picked up himself. But hey, think that if you want.

Re:Ask a relevant question

[uncqual]

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

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.

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.

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.

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.

Re:Ask a relevant question

[LaCosaNostradamus]

For that question, Corporate America has 2 answers:

1. An older surgeon who is forced to take a younger surgeon's pay, OR ...

2. The younger surgeon, and we simply pretend he's doing a GREAT job.

You can live without certain organs, right? There are lower levels of "living" that corporations are willing to accept.

How did your last customer support call go for you? There's a fine example of lowered expectations.

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.

Re:Ask a relevant question

[TomorrowPlusX]

My father became nearly crippled because a cocky young doctor refused to listen to the advice and experience of an older doctor ( who knew exactly what work my father needed: specifically, fusing vertebrae due to a collapsed disc ), and instead did it "his own way". It took a subsequent operation by the experienced doctor to undo the damage.

Discounting the old and experienced simply because you think youth is always right shows you to be a) a youth, perhaps a teenager, or b) an ass. Take your pick.

Both the young and old have a lot to learn from one another. In the case of medicine, if either refuses, I say fire him. There's no room for ego when patients' lives are on the line.

And regarding modern "IT", well, consider that your average IT guy 20 or 30 years ago could actually, you know, write code and build mechanisms to solve problems. Today you've got people with MCSEs who wouldn't know a shell script or a compiler if it bit them on their asses. People who, when they sit at a linux or Mac machine say "Where's the start menu". Criminy.

Re:Ask a relevant question

[Anonymous Coward]

I second that.

Re:Ask a relevant question

[Cervantes]

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

I dunno, how would you qualify Dr Nick Riviera?

IBM is trying the save a piece of his bizness

[timeToy]

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)

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

[jellomizer]

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.

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

[Prof. Reginald]

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, welfare checks, child support, or retirement systems to name a few. Some of these migrations have been going on the whole time I've worked here (almost four years), with nothing happening but the mainframe power-down date being continually moved back by months at a time. I'm sure some of the problems are stemming from the choice of staff, and could be completed by more competent people. But I'd still like to see someone migrate our Commonwealth's welfare system to off-the-shelf servers. Any takers?

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

[deanj]

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.

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

[hjstaruk]

In the mid-1990a, a company I consulted for tried to rewrite a mainframe COBOL/CICS/VSAM system (originally written in 1960's, heavily modified through the ages) using C++. They put 90 people (1/4 of their staff) on writing the new system which had to at least duplicate the functionality of the old system. As updates, regulatory changes, etc. were applied to the production system, they also had to be applied to the new one. Eventually, the changes took up the entire time of the staff allocated to the new system. The company found that, even with the latest documentation techniques, man-hours per change was much higher on the C++ system than on the COBOL system. After 2 years, they decided that they could no longer afford to keep up parallel development and trashed the new system project.

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

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

[Prof. Reginald]

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 is that is what that govt. agency was using before we got the contract.

It is interesting to note that with my contract with Unisys, we have been constantly trying to push the government into "upgrading" systems (so Unisys can sell more hardware and support). But the IBM contract here seems just happy with IBM mainframes and has not been making any push to migrate, although they have gained a few IBM Linux servers. (There, that should keep the /. masses content.)

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

[gardyloo]

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 that. The young engineer used the buzzwords, but the older, conservative guy was probably a lot safer.

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

[Viol8]

Unfortuntalely this sort of thing is directly a result of the problem
that the original article mentions. Newbies coming into the business (and
I include managers there , not just IT people) have been brought up on
Windows usually , far less unix than used to be , and virtually no mainframe
experience. Consequently for them , a machine crashing now and then and
needing a reboot just because an app (not the OS) has got itself into
difficulty is the norm and they accept it. Occasionally they wring their
hands in frustration as to what they can do to improve it but they're too
clueless/stupid to know what the solution is. Windows is a fine desktop
enviroment but its a pile of sh1t for running a 24/7 backend setup not only
because of the dubious reliability of the OS itself but also because PC
hardware (not matter how "high-end" the OEM claims) simply does not have
the reliability of true high end systems. Theres a reason true high end
vendors charge through the nose proper high end hardware and its not just
because they can (tho that does come into it! :). For the same reason
(hardware) I wouldn't use PC linux for a 24/7 setup either.

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

[DickBreath]

I hear they even run Linux nowadays. Far out (to use the terminology that seems appropriate).

To use terminology that seemed appropriate twenty five years ago.

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

[Kahlus]

That was the point. He was talking about mainframes being able to do something cool.

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

[vacuum_tuber]

I'm a taker. I'd like to see what the applications are written in. We're replacing legacy Wang VS mainframes with a virtualized VS that is 100% binary compatible with the original. The Wang VS metaphor is the easiest mainframe metaphor to work with, in programming, operation and use. The New VS offers twice the processing/user capacity of the largest, fastest Wang VS made (the 1999 VS18950) and with all the hardware virtualized it is much nicer to work with. Most things that were agonzing hardware decisions in the legacy world are mere matters of virtual configuration in the New VS. Want to have 50 or 100 virtual disk drives? Just carve them out of RAID and initialize them. Want to support 500-1000 users? That's easy.

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

[QuietLagoon]

Out of my entire comment, you seem to choose two words for critique that are the least relevant to the concept I was trying to convey in the overall message.

Typo

[Anonymous Coward]

Stray '1' located just prior to the last sentence.

i, for one

[54v4g3]

I, for one, welcome our new grandpa-tech overlords

interesting

[Anonymous Coward]

Interesting, my father was laid off from IBM a couple years ago after working for them for over 20 years. Now he works for a company that contracts with IBM to do.. you guessed it work on mainframes.

For more information....

[GenKreton]

For more information see this link.

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.

Re:I got out of mainframes 15 years ago

[generic-man]

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.

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

Re:Same old problem, different questions....

[Mostly a lurker]

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 location I worked at, were a partial failure, in spite of the fact that funding and good staff were available. In every other company I have worked for, disaster planning was little better than using a four leaf clover.

And what about

[Mycroft_514]

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

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

Re:And what about

[RaveX]

1. You really think that the demand for people who program in COBOL is expanding?

2. Do you think that some system other than capitalism (say, socialism) would solve the problems associated with growth and development, like transitioning to more efficient languages?

Actually, come to think of it, they probably would. We'd just still be using COBOL.

Re:And what about

[00lmz]

At my college, I have RPG and COBOL classes taught on AS/400 systems. Actually, I'm taking the COBOL class this semester. I can say without hesitation that while RPG is tolerable, COBOL is just too verbose for my tastes.

The AS/400 is an interesting system though...

Re:And what about

[Mycroft_514]

AND they should be teaching a few languages. In my school (years ago), some languages were 1 credit options. Everything else was taught in a language that pretty much no longer EXISTS.

Where I am, I see the need for COBOL still expanding all the time. We have hired in half a dozen COBOL programmers this year alone.

And int he general sense, it occurs elsewhere. We have DB2 as the database system for the largest systems here. We have reqs out for some new DBAs right now.

Basic COBOL is not that hard to pick up, but to really use it is. And add in CICS and DB2 access, and it isn't something you can pick up in a week.

Re:And what about

[Mycroft_514]

And that is your tastes. Personally, I detest C C++ and C#, but that is my tastes. In the meantime, we are hiring COBOL programemrs here, and not hirign C, C++, and C# sharp programmers, or Java programmers or any of those other languages.

Re:And what about

[krislyn]

> PL/I, Cobal and Fortran are not hard to pick up.

They're not all that easy to spell, though.

Re:And what about

[vacuum_tuber]

Back when I was just a wee young'un, back in ought-60-something, I hated the very idea of COBOL. Later, when I came to my senses, I discovered that COBOL is very nice indeed for business data processing, including interactive apps. It's the verbosity that makes it readable, and with proper tools nobody actually types all that stuff... one uses boilerplate, one uses copybooks (=includes), one copies sections of code and modifies them, one duplicates lines, etc.

Re:And what about

[vacuum_tuber]

That's the beauty of the Wang VS mainframe... unlike IBM's model, where CICS was the workaround for getting a batch OS to handle interactive stuff, Wang COBOL is built on an interactive OS and has integrated workstation I/O. Screens can be defined inline, each screen being just one COBOL statement, or they can be kept in copybooks. When you compile this way you get your screen-related errors as compile errors, not runtime errors. And transaction processing is integrated at the OS/filesystem level with rollback and rollforward recovery. Host Language Interface for the PACE database supports RPG and COBOL 74/85, so database metastatements are standard. The PACE subsystem even generates skeleton COBOL database programs at the touch of a key.

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?

Re:Well..

[TubeSteak]

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

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

Re:Big iron

[Mordaximus]

n Learn COBOL
n+1 Profit!

Re:Big iron

[Anonymous Coward]

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

You don't know much about big iron or COBOL, do you? The good side of COBOL is that I can get a complete application up, running, and in the user's hands while you are still trying to figure out which set of libraries to use for your C/C++/Java/Javabeans/C-sharp/VB/PowerBuilder/etc monstrosity that no one will be able to maintain after you've skipped to your next job with the monstrosity as a new line in your resume. Some COBOLs can generate Java object for servlets and applets. Try competing against an experienced mainframe programmer who knows the data and the business, who can also generate Java object, when all you have is the trendy tools of the day and total ignorance of the data and the business. We've seen that many times. The outside firm says they can do a job in six months -- while it's doubtful they can ever do it -- and the big iron dogs go in the back room and come out three days later with the finished app, and it's fully maintainable without half a dozen skill sets and tools that will go out of fashion in six months.

But hell, if you don't like COBOL you can do C and Java et al on big iron. See, what you think of as a dinosaur is not a stationary target for extinction. Mainframes now do TCP/IP, Web service, Linux, etc., and on a scale that would take a PC server weenie's breath away.

You have to know what you're barking about before you can even think about running with the big dogs.

I'm probably the illest mc

[Anonymous Coward]

believe it or not

How many IBM employees...

[Slashdiddly]

How many IBM employees does it take to keep the lights on?

Three.

One to do screw in the light bulb.
One to incentivize the first one.
One to burn the dictionary.

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

Re:Maintaining legacy Infastructure

[YrWrstNtmr]

...a great bunch of people that have been around even before the Internet...

You say that as though it is unusual.

Re:Maintaining legacy Infastructure

[Batman64]

Haha no not unusual. They are just faced with working with pre-net tech that kept all the terminals running, spliced together with thinnet, data running through 110block phone ports, voip, digital phone, analog phone, and dual oc3 lines...it's a very interesting mix of tech. I enjoy sitting back on slow afternoons while many of the older retired persons stop in, catch up on the latest goings on with the campus tech, talk of the past,..etc.

Re:Maintaining legacy Infastructure

[kabz]

Yeah, I'm not old, and I started at Uni in 1984. Pre-email. Man it sucked when started getting our assignments by email. We has to manually un-UUENCODE them and print them ourselves. Man how we bitched.

We never thought that electronic mail would catch on.

Re:Maintaining legacy Infastructure

[vacuum_tuber]

Even before the Internet? Gosh, son, the Internet is quite new on my calendar. How about before integrated circuits? How about before transistor logic? How about before large parts of rural America had electricity?

Who would you rather make a diamond broach?

[Stephen Samuel]

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

Re:Who would you rather make a diamond broach?

[gr84b8]

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

Only problem with that analogy is that every 60 year old jeweler is not a MASTER jeweler. Similarly, most of these older experienced mainframe programmers are probably not 'master' engineers.

Re:Who would you rather make a diamond broach?

[deanj]

mainframe programmers? Hell, MOST engineers aren't "master" engineers. Lots of them THINK they are, but most aren't.

Re:Who would you rather make a diamond broach?

[Stephen Samuel]

Similarly, most of these older experienced mainframe programmers are probably not 'master' engineers.

True, but if they like what they're doing, chances are that, with 40 years of experience, they'll have picked up some really nice tricks that the youngsters will yet to have thought of. Yes, you've got to look for the masters, but they're more likely to be in the oldsters then the youngsters.

All you have to do is . . .

[Blackeagle_Falcon]

. . . hire Sid.

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:It's not just IT

[Hamstij]

What a load of rubbish.

With virtually every country in the world experiencing soaring levels of unemployment amongst both skilled and unskilled workers, I think there are plenty of people to take their places.

The world's populating is spiralling upwards out of control. There are more than enough young people to take over!

Re:It's not just IT

[baomike]

Maybe;
Can the skilled workers get into this country?
Can the job be exported?
Is the country in question in even worse shape than the US?
Numerous countries face an even bigger problem than we.
Think they might be doing the same thing we want to try?

Re:It's not just IT

[MurphyZero]

Yes many of the baby boomers are approaching retirement, but can they afford to retire? That may delay the effect 5-10 years. How many companies are going to work their boomer employees to death?

Re:It's not just IT

[Anonymous Coward]

Might I also suggest:
Lost Knowledge: Confronting the Threat of an Aging Workforce;
by David Delong

Re:It's not just IT

[SillyNickName4me]

Can the skilled workers get into this country?

h1b?

Can the job be exported?

Offshoring?

Not necessarily

[NineNine]

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.

Re:Not necessarily

[Anonymous Coward]

Yeah but do you really want some old guy sitting in the break room going "Yeah, we had to program entirely in 0's and 1's, and sometimes we only had the letter 'o'."

Not to mention the old man smell.

Re:Not necessarily

[Anonymous Coward]

Great Dilbert joke :-)

Pretty good advertising by IBM...

[NeoBeans]

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

Re:Pretty good advertising by IBM...

[mparaz]

Good call. IBM Developerworks is now the richest source of articles about Geronimo, and Eclipse Webtools, but if you need support... there you go.

3X their former pay

[dpilot]

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

Re:3X their former pay

[Courageous]

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.

Your itemized list does not account for the primary reason to charge at or near a multiplier of 2X: business variance (i.e., the cost of down time between contracts, marketing, finding a new contract, and so forth). If you could count on having the same contract, year in and year out, 2X is generally an overcharge. Alas, one cannot count on that...

I know business that run on multipliers in the ~1.5X range, and they make a profit, by the way. What they do is send their employees to the employers site, offer no facilities (the faciltiies falls under contract), and the day the employee is not covered by the contract is the day the employee is not paid.

If I could turn my current job around at 1.6X, with a guarantee of employment, but had to conver all my own SS, medical, vacation, sick leave, etc, I'd take it in a heart beat. I'd incorporate as a California-S and be in $$$ city...

C//

Re:3X their former pay

[jimi the hippie]

Yeah, brilliant. Incorporate so that they can tax you twice and you just loose almost all of that 60% bonus you just got.

Re:3X their former pay

[Wavicle]

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,000/month.

Medical Insurance: Maybe $500/month?

Dental: Maybe $100/month?

Your office space: Maybe $3/sq.ft. * 250 sqft (a large 16*16 office with window space). $750/month. (this is space that will be paid for and used regardless of whether or not you use it)

Worker's Comp: Not much for this type of job, very little risk. Say $400/month (probably more like $20/month)

Voice Line + Fax Line + Fast Net Connection (A resource typically shared by lots of people) = $200/month

Electricity (most business paying that kind of office space premium usually do not pay for electricity or HVAC): $50/month

That's about $3000/month on some *VERY* liberal numbers. Not even 50% over the base salary.

Unless this guy is chugging $5,000 per month in free coffee, I just don't buy it.

Re:3X their former pay

[Anonymous Coward]

Yeah, brilliant. Incorporate so that they can tax you twice and you just loose almost all of that 60% bonus you just got.

Yep, wouldn't want to "loose" that bonus. If only he were as brilliant as you clearly are.

Re:3X their former pay

[frenetic3]

Subchapter S corporations (what I think he was referring to by saying "California-S": a California S corp) don't get double-taxed.

-fren

Re:3X their former pay

[Anonymous Coward]

Your country might be different but where I live, you have to administer two additional tax returns for the most corrupt, bzyantine agency in the country. In my experience, anyone who attempts to start a business in Canada MUST retain both a lawyer and an accountant and should expect better than half of their annual income to be quietly dissappeared into the tax system (in addition to what you actually owe). Revenue Canada is the reason I am not longer in business for myself: aside from having the ethics of weasels on crack (actually their individual behaviour patterns tend to map remarkably well to the symptoms of late stage addition but I digress), I found that the costs in professionals, time, money and heartache made it a stupid choice for anything less than AT LEAST 2x what I was making as an employee.

I won't say I made all of the right decisions (see above about professionals) but right now I am sitting with all of my company's assets being held by those thugs. They've acknowledged that they have the money but refuse to give an explanation of why, what they told the judge to obtain it or to give the money back. Since they originally got the money by lying to a judge, I can understand that they don't want to answer the 2nd question and now that they have it, I guess they figure I'll owe it to them eventually. In the meanwhile, my company has basically been driven back to square 0 because I can't buy any new equipment, tools or materials.

rantmode=on
In short, fuck you Revenue Canada, I hope every one of you parasites dies on a slow spit. If you assholes had half the accountability and transparency of the rest of our government, shit like the sponsorship scandal and the Bronfmann deal would not be possible. Of course, half of you pricks would be in jail too so what can you do?
rantmode=off

Re:3X their former pay

[Anonymous Coward]

Don't forget to add business insurance (professional liability in particular can be very expensive, and may be required by your client), professional fees (legal, accounting, etc.), professional development expenses (you are now paying for your own training to keep your skills current), administrative fees (there are recurring fees---licensing fees, filing fees, and so forth). You may have to advertise regularly to ensure you have another engagement after this one ends.

You will be performing overhead duties---paperwork of all kinds, marketing, taking your clients to lunch (generally not as glamorous as it sounds), and so forth---all time which is not generally billable. The big companies pay other people to perform those duties; will you not pay yourself something for that time? [More hours for the same salary is a step down.]

Next, all of those expenses---salary and overhead---are paid over 12 months. Just like the company, the consultant doesn't earn that revenue over a full twelve months of constant labor (2,080 hours). Deduct four weeks of "vacation" (which you may as well call marketing time), 11 Federal holidays (where you may not be allowed to be present on your customer's facilities, for instance, to conduct your work), and seven sick days and your down to 1,776 hours---you have to mark up your costs by 17% in that case to cover that minimal downtime. If you're not on a long-term engagement, that increases. [A recent survey showed that consultants generally bill 65% of the available 2080 hours, if I recall correctly.]

Finally, as a consultant, you're a fool not to consider profit. You are a business, even if you're only a business of one. You are taking a risk by working this way. Profit (or "Fee") is the reward associated with the risk.

And don't think that there is not a mutual benefit enjoyed by the company engaging you. For instance, as a consultant, you may not be paid if you fail to perform. Your contract may be for one task with a finite duration You may individually be locked down by contract to perform that task, and should you fail to perform the company has legal recourse to sue for damages. You are at risk. An employee may quit at will midstream, or begin to haggle demanding raises, hijacking the project. In general, an employee is not at risk for failure to perform---the company employing him is. Operating under contract, you and your costs are predictible, and that is worth something to the purchasor.

But all of this analysis is essentially moot. All things being equal, the consultant's economic motivation is to charge as much as he can (after all, you only have so many hours here on Earth to sell), and the company is motivated to pay as little as possible (to increase the profit margin). If the consultant is charging too much, the company will eventually find another willing and able to do the work for less. Market forces dictate rates. [I know, that's not necessarily entirely true, but it's fair enough.] If 2x is the stable point, than 2x it is. You want to do it for less? Enjoy---and then learn the hard way what the consultants who have preceeded you have learned the hard way.

-JM

Re:3X their former pay

[Anonymous Coward]

you just loose almost all

"lose".

To the Slashdot editors and coders:

Slow Down Cowboy!

Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment.

It's been 30 minutes since you last successfully posted a comment

Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form.

No, I'm not behind a fucking firewall or proxy, and I didn't click my fucking "Back" button. What happened was that you fucking idiots don't fucking tell me in advance (when I fucking click the fucking "Reply to This" link) how fucking long I have to fucking wait to fucking post. Instead, you wait until I have composed my reply and try to submit it, and only then do you tell me that I should have waited longer. This is totally fucked up. If I didn't have ad blocking turned on, I would email your advertisers and complain about how you treat people who post anonymously when they post useless crap because they are afraid to compromise their kharma.

Oh, and when the fuck are you going to fix the punctuation in your obnoxious message ("It's been X minutes since you last successfully posted a comment" should end with a period/full stop, you stupid motherfucking hamster fondlers)?

Please note that the above is meant to be friendly helpful criticism, and interpret it in that spirit. Thank you.

Re:3X their former pay

[Kahlus]

Great points, and even still, you left off some things. For instance, my employment includes a discounted gym membership, a monthly transit card (about $50), a 4% matching to my 401k and disability insurance. Those are things I would lose (and that I like) if I went out on my own.

Your costs as a consultant should factor in the fringe benefits you might get from a full time position.

Re:3X their former pay

[Anonymous Coward]

Incorporate so that they can tax you twice and you just loose almost all of that 60% bonus you just got.

You are utterly ignorant and haven't a clue as to what you are talking about.

C//

Re:3X their former pay

[Wavicle]

Yes, all nice points, but I wasn't discussing the costs incurred by a consultant. I was discussing whether or not the cost of an employee to a company is 2x that of the employee's pay.

Re:duh

[tomhudson]

Old people = dumb p<b>oe</b>ple

Well, we sure won't have to worry about your code crashing ...

... because it will never compile with your typo rate ...

... and nobody's going to hire a kid whose english makes perl look good.

Maybe IBM should eat its own cooking?

[Anonymous Coward]

After years of laying of senior employees, IBM's now saying these same people have invaluable information? Puhleeze...

Anybody who's been at IBM's IGS for more than six years is "senior" and is targeted for replacement by younger recent-graduates. Anybody who's been in any other part of IBM for more than ten years is a pension liability that must be terminated to reduce that liability.

Re:Maybe IBM should eat its own cooking?

[Anonymous Coward]

"younger recent-graduates"? Maybe three years ago. Now they're just replacing everyone with foreign contractors.

Re:Maybe IBM should eat its own cooking?

[ScrewMaster]

After years of laying of senior employees,

I dunno ... if they've been getting their senior employees laid it might be worth putting in a few years.

Re:Maybe IBM should eat its own cooking?

[SillyNickName4me]

Interesting, IBM did quite a bit of efford to retain me there when I left after 11 years of employment...

Re:Maybe IBM should eat its own cooking?

[drbenphd]

From the author: Whoops. See what happens when you use spell check? Sorry for the typo. Interesting conversation though.... Ben L.

rewrite

[oliverthered]

I expect you'll be subject to the oldest trick in the book, a rewrite, and what's even better is that the rewrite may even build on your mistakes and work better than you did.

Agreed...

[Jeian]

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

[Anonymous Coward]

Wow, only 19, and your post is basically "back in the old days..." :)

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.

I work for the phone company

[edanshekar]

Who you telling about "Old Belles" knowing more about the ancient systems then us young bucks?!?

How many of those here assembled...

[TFGeditor]

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 still alive and in need of a predator to keep them in line.

Re:How many of those here assembled...

[stevesliva]

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

Re:How many of those here assembled...

[Hasai]

No DG stuff, but the DECs bring back memories.
The paper tape was kinda fun; we used to make wreaths out of it for xmas. And who hasn't had the electric thrill of ducking a flying magtape when the hub froze on rewind?
];)

Re:How many of those here assembled...

[LaCosaNostradamus]

HOLY CHRIST! Are people still using Data General minicomputers? I worked on those in the mid 1980s in the Air Force ... on the NOVA 840 and 1220 models. Here we are 20 years later and you're telling me that people haven't at least upgraded those systems to DEC, Honeywell, or Unisys systems?

I fondly recall flipping those front-panel dip-switches to load and diagnose the NOVA 840.

Re:How many of those here assembled...

[TFGeditor]

Yep, still in use, mostly for very specific realtime control applications. In my case, it is realtime test applications.

Novas and eclipses later evolved with a "virtual console" in lieu of the switch panel. Pity, the switches and all the blinking ligts made them look like they were doing something, like they were "real computers."

Not sure what kind of drives the Nova you worked with had, but perhaps the following will mean something to you:

100073 RESET/PR LOAD
100033 RESET/PR LOAD

Re:How many of those here assembled...

[LaCosaNostradamus]

Those do look familiar, but we're dredging some particularly compressed silt in my brain, so I'm not sure. For instance, I can't remember why bit 16 was always set to 1. My USAF training at Colorado forced us to go through the NOVA processor clock-tick by clock-tick, gate by gate, flipflop by flipflop, watching each instruction change the processor ... so it's a shame that I can't remember now.

Did you read "Soul of a New Machine"? It documents the development of the Eclipse.

Re:How many of those here assembled...

[TFGeditor]

WHen I first started working with Nova 3 machines, they had genuine core memory. I still have a functioning top-loader cartridge disk drive (DG 6045) that had a whopping 10 megabytes distributed over two 14-inch platters. Drive the size of dishwasher.

"Did you read "Soul of a New Machine"? It documents the development of the Eclipse."

In fact I did! Tracy Kidder wrote it, as I recall. I remember (1) a description of a poster with flame-singed edges (a veiled reference to a rumor that some DG exec had torched a DEC--or some other competitor's--facilities), and (2) that the FINAL TEST of the Eclispe prototype was to successfully play to completion a game of Collosal Cave Adventure. Actually, now that my mental silt is stirred up, I remember a lot of neat stuff from that book: industrial espionage, dispute over including a mode bit, and bit more mental detritus.

Re:How many of those here assembled...

[LaCosaNostradamus]

Gawd, yes, that was the first time I saw actual core memory. To this day I'm amazed how they managed to string such tiny wires and ferrite rings together. It looked like metal cloth.

My favorite part of SOANM was the unknown processor bug that was fixed by soldering in a single AND gate (obviously, part of a 7400-series chip). Nobody knew why that gate fixed the processor, but it did.

Ultimate Disaster Recovery Plan

[Safety Cap]

1. Print out resume

NASA still uses Amiga's

[Anonymous Coward]

Obligatory AMIGA post (but true)

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

Re:Rubbish

[Spy der Mann]

In all my experience, older employees become mentors to the new recruits.

Speak for yourself. Here in Mexico people over 40 aren't hired *AT ALL*. No matter how much they might know. And there's no way to sue the companies because there's no way to PROVE they didn't hire you for your age.

But everybody knows.

Intended

[Kadin2048]

I think that's the point: in large part this reads like a critique of IBM itself, from the point of view of one of it's systems consultants. However to avoid coming under fire for actually criticizing anyone in particular within IBM, it's instead written as an external publication.

This makes it a lot more palatable for internal IBM managers to read and apply, without getting immediately defensive. If it's advisory and critical of some vaguely defined external audience, then an IBM manager can go 'hey, that's a great idea. We should do that.' As opposed to if it were an internal memo, which would imply a lot of seriousness and engender a lot of ass-covering and denial.

Until it got slashdotted, I'll bet that the majority of the actual readership of any given publication like this is predominantly by IBM-ers (especially because it probably pops up on their portal webpage), not other people who just stumble into the site from the outside.

You really don't understand the mainframe!!!!

[Anonymous Coward]

Mainframes are a dying beast, but they are relatively good at what they do, which is IO work, IBM mainframes have tremendous IO ability but pretty bad processing ability. In number crunching an Opteron will kill a mainframe processor and the biggest z990 mainframe which we have at my company is maybe 32 processors.

There are a few keys to the mainframe, from a security standpoint mainframes have excellent access control but are not build for modern management techniques or the internet age which brings along many risks in a system designed for use before people had access to computers to breach your mainframes security. So there are real problems making mainframes secure while integrating their technology into modern environments.

The truth is mainframes can handle their load also because their programs were written for efficiency and speed on modest hardware. The truth is a modern unix system can run circles around a mainframe when equipped properly. To those who doubt the power of distributed systems look at some enterprise systems using distributed computing systems. Honestly it has been within the last 5 years that industrial unix systems have caught up with the enterprise features of the mainframe. But in reality the old timers should be teaching the young-ins business logic and how to get apps off the mainframe.

The mainframe really is an antiquated technology, but it works and there is a vested investment albeit at a greater cost and at the expense of dependence on ibm. So while I think the mainframe is a viable tool short term, the future looks bleak as superior Unix Oses and hardware with modern risc processors continue to mature into platforms capable of much more than a mainframe at a lower operating cost.

Wouldn't it be darkly funny

[gelfling]

If Y2K finally came to us in the form of management indifference and negligence on the altar of efficiency?

To understand why young people are being hired...

[rd4tech]

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

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

Re:A misunderstanding

[Veteran]

No question that good technical management is both rare and valuable. It is rare because most managers are not very good technically. They seek to hide that fact from themselves by 'proving' that they are better than those they manage by denigrating the importance of technical ability. The thinking is: "If I can't do it, it must not be important."

People who are good technical managers seldom progress very far on the management scale: they are feared by the managers above them who will do anything they can to sabotage their careers.

I have a good friend who is a brilliant technical manager who got great work out of his team for an unnamed major computer manufacturer over a period of 15 years.. The new turd one level up from him purposely assigned his team a task that could not possibly succeed on a schedule no one could have met, When the inevitable failure occurred my friend was relieved, given an "unsatisfactory" performance rating (after 15 years of consistent "superior" ratings) and transferred to the corporate equivalent of Antarctica where he now supervises a couple of penguins.

There is a fundamental rule which corporations ought to follow: anyone who aspires to management should never be allowed to be a manager..

Re:A misunderstanding

[TheLink]

Uh good managers are not easily replaceable.

A good middle manager is like a good "middleware" between upper management and the subordinates.

Also just because you're not that up to date with tech stuff doesn't mean you can't tell when someone is bullshitting you or not.

Even if you can't tell at first whether your subordinate is bullshitting you, you can always note the stuff down and check it (with google or someone else). If you handle it well (and that's the trick), after that I doubt they'd dare bullshit significantly, and might even respect you a bit more...

If you are a manager, what matters is how well you know and handle people (you can use this for your selfish benefit or for the benefit of the company (or both), go figure).

The Art of Management isn't easily taught either. Judging from the vast quantities of silly management books and the vast numbers of crappy managers.

I guess a possible problem is the crappy managers don't know (or care) that they are crappy, and so are willing to take the jobs, whereas the slightly less crappy ones know they are crappy and thus don't want to be managers.

As for people being easily interchangeable and replaced, I prefer to use a different concept: roles/jobs can usually be filled by others. But usually good people do more than their role. And no two persons do the same "extra" things the same way. If you only want to fill a role/seat, you're being a bit stupid/negligent as an employer/manager - better to get more bang for the buck.

Re:A misunderstanding

[ScrewMaster]

There is a fundamental rule which corporations ought to follow: anyone who aspires to management should never be allowed to be a manager..

No kidding ... never put anyone in power who wants to be there, because they probably only want to be there because of the power. Instead, pick somebody who is qualified for (if not necessarily enamoured of) the position, and tell them that if they do a good job they can get out in three years.

It sounds like your friend got a totally raw deal but you can rest assured that his team's output went to hell, and that the corporation got exactly what it deserved. Unless, of course, they managed to hire someone with equivalent management capability and leadership skills. Even if they did, it sounds like his immediate superior is enough of a dick that the replacement wouldn't last either. Oh, eventually upper management wises up to situations like that but by the time they do, any vestigial esprit de corps left behind by your friend will have long evaporated. It's really, really hard to heal the wounds dealt to a tight-knit, productive team by a truly bad manager. Often they can't be, and the team collapses and people leave for greener pastures. I've seen that happen on a number of occasions, and it's one of the most depressing things to witness.

However, a lot of managerial success depends upon the engineering staff itself. For example, I've been at my current position for almost seven years ... the rest of the software guys have been there for fifteen or more. While our manager is an engineer (electronics, as it happens) he's not a software manager. But that works out extremely well for us, because the engineering people know their jobs, and his role is to issue directives, schedule our time, make sure our approach to a given problem makes at least a modicum of sense, and then make sure that the required resources are available. He's also a great guy that respects his subordinate's opinions and creates an environment where they can do what they do best, and he does his best to keep all the political stuff away from us. The only real complaint I have about the job is that I've been on the same project for seven years, but it's a big project with lots of room to grow so at least I'm not bored.

Contrast that to a team composed of young, perhaps highly-motivated but inexperienced engineers. You absolutely must have a manager that is capable of leading them and understanding enough about their work to direct them and keep them on track. As you say, that's not likely to happen in most cases, which is why this nationwide pogrom to fire off the (ahem) "overpaid" senior staff and replace them with wet-behind-the-ears college grads is often a fatal mistake. Penny-wise and pound-foolish, at best.

Amputation?

[Trejkaz]

Amputation? Haven't you heard of leeches? Get with the time, man!

Re:Amputation?

[slazar]

Or maggots! http://my.webmd.com/content/article/94/102721.htm
http://www.larve.com/Images/ mmmm tasty!

Obviously Not a Member of Any Medical Staff

[Black-Man]

The director's *do* a lot of the surgery you dumb ass, why do you think they pay them the big $$? Stand around and consult? And the grunt work?? That is handled by the RESIDENTS, because it is exactly that. The difficult surgeries, you better believe the senior staff member is in the OR.

Looking at it from a different angle

[Zzyzygy]

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

Re:Looking at it from a different angle

[ScrewMaster]

but where and when does experience and wisdom rule over copper-tops?

Sad that being in your early forties qualifies you as an old fart, technologically speaking. I'm in my mid forties and I'm seeing the same pattern. A fellow we hired a while ago said, "It's really getting brutal out there" and he just turned fifty. I think it's because it's really, really hard for a manager to justify to a corporate beancounter the extra $30K he's paying that experienced engineer. And it's worse, if you do your job so well that there aren't any major problems or snafus along the way: the impression then is that the job is easy and that anyone can do it.

Where I work the owner actually prefers to hire engineers that have been around the block: it makes his life a lot easier. But I agree with you, that's not too common these days.

Re:Looking at it from a different angle

[Zzyzygy]

Where I work the owner actually prefers to hire engineers that have been around the block: it makes his life a lot easier. But I agree with you, that's not too common these days.

Two questions: 1) where do you work and 2) are you hiring? :-)

-Scott

Re:Looking at it from a different angle

[buss_error]

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 worked with a majority of variants of Unix, including Linux. I've got Linux experience since Kernal 0.96. through kernal 2.6"
Then he said, and I kid you not...... "What's this "kernel" stuff? I need L-I-N-U-X people."

My resume, right in the first sentence, says "7 years experience with Linux in current employment". The guy didn't read it, I guess, nor was I called again. I heard the project folded, so I guess it's all for the best.

And just who....

[Anonymous Coward]

...will be providing this so-called "training" to the inexperienced young new-hires???

Mainframe vs pc: false dilema

[Vermifax]

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

There are newer large mainframe computers.

Re:Mainframe vs pc: false dilema

[Anonymous Coward]

Well put. Mainframes are massively scalable, thoroughly reliable, secure multi-purpose servers that can run 24-bit COBOL batch applications written 40 years ago alongside 64-bit Java and Linux applications written 5 minutes ago. They can run thousands of applications concurrently while a technician replaces a failed processor (which statistically happens once every 40+ years) without those applications suffering the slightest bit of inconvenience or interruption. Linux included. PCs...can't. :-)

The fact that mainframes *can* run older code is a *good* thing. It means businesses don't constantly have to rewrite code just because some vendor is anxious to get some more "planned obsolescence" revenue. Last I checked, debits still must equal credits. They did 40 years ago, and they will 40 years from now. But if you're tired of your 40 (or 30 or 20 or 10 or 1) year old code, replace it! Nothing whatsoever stopping you. The mainframe is more than ready to run the latest and greatest Java, Linux, PHP, and whatever-else-is-new with style and grace as fast as you can write it. Alongside the 40 year old code that somebody else didn't want to be forced to rewrite. All on a single server in a single footprint. (Or two with an under 100 km fiber link if you want some earthquake proofing. But then they still function as one.)

Re:Mainframe vs pc: false dilema

[SillyNickName4me]

They can run thousands of applications concurrently while a technician replaces a failed processor (which statistically happens once every 40+ years) without those applications suffering the slightest bit of inconvenience or interruption. Linux included. PCs...can't. :-)

A single PC usually can't.. a few PCs running something like XEN however come very close and may even be able to fully do that, for a fraction of the hardware cost.

This kind of technology is still pretty new for the PC world, but it is rapidly developing into a solution that at least on the level of reliability can rival that of current mainframes (due to lots of redundancy, not due to quality)

Similar to mechanics

[Anonymous Coward]

IMHO, this is similar to the Northwest Airlines mechanic's strike. I would much prefer to fly on a plane that has been maintained by a mechanic who knows this kind of plane like his wife of 20 years than a "scab" (newbie) who may have just left mechanic's school and not ever done any kind of apprenciceship.
If I were a manager, I would also prefer to have the "disosaurs" maintaining the mainframe apps, while looking to the new blood to update the technology. This assumes the feasability of doing so, which may not always exist.
I think there is without question value in having someone who knows a system well through years of experience maintain it. New ideas and new techniques are fine, but keep them to new development or major enhancements (i.e. *replacing* the mainframe app) and don't assume that that dinosaur is easily replaced. Very simply, experience has value.

Absolutely false. Cf SPENGLER.

[mosel-saar-ruwer]

What a load of rubbish. With virtually every country in the world experiencing soaring levels of unemployment amongst both skilled and unskilled workers, I think there are plenty of people to take their places. The world's populating is spiralling upwards out of control. There are more than enough young people to take over!

What you have said is absolutely false. The world is in the middle of a population implosion the likes of which we haven't seen since the Black Plague.

If you are at all curious about these things, I cannot overemphasize the importance of the work that a pseudonymous author is doing at the Asia Times, under the name "Spengler":

The Complete Spengler

I would urge you to read everything he has written on the subject.

PS: No one knows what will happen to these nations as they enter their death spirals. Almost all socio-economic models are based on the idea of a expanding population, and no one knows what will happen to these societies as their populations begin to contract.

By means of comparison, almost all financial models are based on an assumption of an increasing money supply [what we call "inflation"]. However, the only time this nation ever experienced a monetary deflation [when the Federal Reserve foolishly contracted the money supply in the late 1920s], we entered a two decade long economic calamity so terrible that it is now known as "The Great Depression".

Re:Absolutely false. Cf SPENGLER.

[Random Hacker]

It is you, sir, who is spouting rubbish. Over 70 million people get added to the world's population every year. There is no sign of a population implosion, but there is plenty of evidence of population replacement.

The following populations have had below replacement levels of fertility for several decades and will eventually face population declines (if they aren't occuring already):

Whites almost everywhere -- including in Europe, Russia, North America, Australia, and New Zealand -- the only exception I'm aware of is Muslim Albania.

Chinese in China, due to a one child policy imposed by the government.

Japanese.

However, fertility rates are above (and often far above) replacement level in the following places:

Africa (AIDS or no AIDS, the population keeps climbing).

Every majority Muslim country.

Mexico, and most other Latin American countries.

India

So while there will be declines of certain groups, those declines will be more than compensated for by the growth in other groups happy to take their places.

We see this in microcosm within the U.S. The (for the time being) majority white population has had below replacement fertility rates since about 1970. So, surely, you might think, the U.S. population is heading towards stabilization, if not already shrinking outright? Nope. In the decade of the 1990s the U.S. population grew by 32 million, the largest one decade population increase in its history. How can this be? First, the black American fertility rate is still above replacement level (blacks were 10% of the U.S. population in 1960, 13% now, and black children are 15% of all American children, so in another couple of generations, blacks will be 15% of the U.S. population). But, of far more significance demographically, the population of Latinos has soared (it now exceeds the black population). This came about through massive levels of immigration and a Latino fertility rate that is well above replacement level. Then of course, there are the numerous other immigrant groups -- from India, China, the Middle East, and just about every other place with a growing population. Back around 1970, before the floodgates of immigration opened up, the Census Bureau projected that the U.S. population would stabilize at about 300 million within a decade or so of the new millenium. The U.S. population will indeed hit 300 million within a year or so, but there is no sign of stabilization in sight. The Census Bureaus' middle projection gives a population of about 410 million by 2050, and there will be more after that.

Globally, population is expected to increase by at least another 50% before it stabilizes, assuming it ever does.

So, there's no hint of a population implosion, neither globally nor within the United States. There is ample evidence that some groups will be replaced by others.

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.

Today's "dinosaurs"...

[Nick Driver]

...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, and expensive IT staff.

It's a viscious cycle... in just a few more short years the next wave of "web services" -based technology that is presently trying to push client-server aside, will all too soon be staffed with aging folks who want to be paid more money that management wishes to pay.

Face it, corporate management always wants magic technology to solve all their problems, but never wishes to pay what the technology really costs to implement and operate fully properly for the entire duration of it's lifecycle, but are always far too eager to pay somebody else outside their organization a boatload of money for the empty promises of the "next wave that will supercede the dinosaur".

Are you reading what you're typing?

[SuperKendall]

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?

Re:Are you reading what you're typing?

[Xiaran]

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

One just itching to try new experimental techniques?

You hit the nail on the head. Young programmers who dont have that much real world programmer get all het up about the "next big thing" in design and development. Im not blamign them... they are at least enthusiastic. And to be honest with you I did exactly the same things when I was in my first job. Some of the first OO code I wrote is still lurking around on my personal CVS... some nice libraries that work fine and are well tested. But looking at the code itself is disturbing and embarrising :)

Re:Are you reading what you're typing?

[Doctor Memory]

Heh, sounds like my current gig. The three most common books to see around the farm are Teach Yourself Java in 21 Days, Enterprise Java Beans for Dummies and Programming Jakarta Struts. We've got an application with close to 100 JSPs with corresponding action forms, then they all funnel down into 14 action classes. Each action class has two corresponding EJBs: one to implement the SessionFacade pattern and one to do the actual work. It's like the worst part of the 70s all over again: big, monolithic modules held together with logical cohesion, and the performance you'd expect from such a system. But, since it's all based on Java and design patterns, it's golden and nobody dares criticize it.

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.

Re:Maintenance Strategies

[Moeses]

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.

When to rewrite isn't a function of the codes age, it's a function of cost. How much will it cost to work around code versus rewrite it and when will the return on investment be made. Since most engineers work for businesses the proper evaluation of this will involve business issues outside of the scope of the technical work. Managing a business isn't really that much different than engineering, at least from this self-employed engineers point of view.

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.

That's the (unkept) promise of every new programming paradigm. OO *is* great. The point is to make abstraction and isolation easier than it was in procedural programming. It's a godsend in large applications for this reason, but it still has problems. One is that abstractions don't start perfect and as other things in the system change the likelihood of having to do extra ugly work-arounds or a rewrite (see previous paragraph) is high. What OO does do for you is that when it it is used well it helps the developer have to think about fewer issues while programming, which should increase productivity.

Fix the problem

[digitalamish]

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.

Re:Fix the problem

[LaCosaNostradamus]

Yes it will cost money to covert it, but in the long run you save.

Long run? What long run? You (the manager or exec in charge of the legacy system) have to justify the expense NOW ... and there's hardly any justification for "saving support money in the future". This is DOUBLY true when the executive class is completely hot for outsourcing and offshoring. There's no point in making long-term infrastructural investments when much of said infrastructure will not be owned by the company within 5 years.

For the 1-2 year period prior to my outsourcing, my previous company stalled even more alarmingly on buying virtually anything -- parts, tools, stock equipment, training, etc. They well knew that there was no point in investing in us, just to get rid of us. I'm sure they also tried to underfund the operation for many fiscal periods so the outsourcer wouldn't realize the true extents of the costs of running the operation ... hence screwing over the outsourcer for the length of the contract.

Re:Fix the problem

[Anonymous Coward]

", but in the long run you save."

But there wont be any long run because a few years down the line you'll need to upgrade to ${buzzword2.0) in order to "save money in the long run".

Migrate Unisys to IBM

[BBCWatcher]

You should consider migrating those Unisys mainframes to an IBM mainframe. The IBM mainframe is thoroughly modernized and thriving (Linux!), and it's the one platform that has the characteristics you're going to need. It's also the lowest total cost platform for organizations that are of any scale (i.e. not the corner hardware store). An IBM mainframe is also much more likely to have the tools and resources needed to pull off a successful migration. And there are many, many former Unisys shops that have made the switch, so you won't be the first. Your Commonwealth's taxpayers will be much happier if you cut your losses now and, unlike Unisys, IBM will actually want to help you get off Unisys.

the bad part abt this argument is

[Anonymous Coward]

how can there ever be old guys if no one is willing to let new guys have a chance? every old guy was a new guy once.

from personal experience i have found it extremly hard to get into a major IT company at ground level after graduating from university. everybody wants someone with experience. if no one is willing to let someone start with no experience, how can they gain it? i even ended up at a compnay with what was susposed to be an IT job, but ended up being an accounting job due to the different types of workload. its crap, but i need the $$$. if anybody in Australia does want to hire me, email me at Dgullispamblock@spamblockgmail.com... just remove the spamblock parts!

when this generation of old IT guys go, there is going to be a huge shortage because no one wanted to hire the new graduates, even though they may have the same skills! its a fucking crazy world we live in.

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.

Re:Rubbish

[deanj]

So, what do those people do? Start their own companies? Consult? ....Become....(yeeech)... managers?

Moving to Dead End?

[Anonymous Coward]

...was involved in moving a major mainframe-only app to Unix/J2EE...

Well, at least it's J2EE, because now they can move it back to z/OS or Linux to save even more money. As UNIX's marketshare shrinks, thank goodness there's a growing platform that can scale and more reliably handle that J2EE code you helped them write -- along with lots of other J2EE applications that don't really need all that expensive, dedicated, dead end, aging UNIX hardware you sold them. Otherwise they're going to be stuck with more and more expensive proprietary UNIX hardware from vendors that don't have the financial resources to continue to invest in their UNIX platform or in its processor technology.

It's amazing what Linux can do, isn't it? :-)

You know I guess they're right,

[Anonymous Coward]

senior citizens, although slow and dangerous behind the wheel, can still serve a purpose.

I'll be right back, don't you go dying on me!

Re:You know I guess they're right,

[Anonymous Coward]

big gulp, eh? well ... see ya later!

UNIX Is Dying

[Anonymous Coward]

I couldn't disagree more -- and neither could the market. Gartner and IDC both report that UNIX is dying, with consistent and continuing declines in marketshare ever since the dot-com bust. But IBM mainframes are growing, due in part to their full embrace of Linux which does indeed run circles around UNIX boxen. You can take that 32-way z990 (actually now a 54-way System z9 which is roughly double the z990's formidable capacity) and carve it up into hundreds or even thousands of Linux instances to do real business work with extreme reliability. In a single server, one footprint! And you pay the same software rates per processor as UNIX -- maybe even less because you only pay for the ones actually used, not physically present -- and you need far fewer processors in the real world of development, test, QA, and production.

For example, Oracle is a whole lot cheaper on IBM mainframes than it is on UNIX, with a very few exceptions for oddball work. And for that oddball work (certain business intelligence workloads) you might as well get Linux blade to go with your Linux mainframe so you can simplify life and use one operating system. And anybody who has Oracle licenses already has mainframe Linux licenses, so there are no software transition costs.

I can't wait...

[Nice2Cats]

...to see the first of these type articles coming from Bangalore, India.

Legacy systems

[Animats]

Misery is a legacy system written in Perl. COBOL is reasonably readable.

Re:duh

[Anonymous Coward]

and nobody's going to hire a kid whose english makes perl look good.

I don't know, they might be looking for a new slashdot editor sometime soon.

Re:duh

[jrockway]

Old people = dumb p<b>oe</b>ple

Then again, your code didn't exactly compile either :)

Must be an IBM I've not seen before...

[threaded]

Is not IBM the company that has been sued numerous times for ageism in several countries?

Or is this another company using the name IBM?

IBM doing exactly this.

[SlashTon]

I have worked for four years for IBM in the Netherlands. I have personally witnessed two rounds of blanket 'early retirement' offers to any employee older than x (I believe it was 52 or something at the second round). The offer was good enough that you'd be crazy or a workaholic not to take it. I certainly would have, had I not been way too young. It was just the easy solution to a head-count problem. Unfortunately, I really doubt that the responsible manager pinheads will get publicly beaten over this even when IBM itself publishes articles on what a bad idea this can be.

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

Software Development Is not Like Engineering

[iangoldby]

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.

Re:Software Development Is not Like Engineering

[TheLink]

Cool. So I'm not the only one.

For quite a while, I've been telling people the difference between software engineering and civil engineering is with software, the clay/plastic "wind tunnel" models work and are sold as version 1.0. The detailed blueprints/designs "compile and run", and are sold as version 2.0. The "real thing" is version 3.0 of course, and 3.1 is after the fixes on the real thing :).

And the trouble is each step costs about as much as making the real thing. Whereas making copies costs almost nothing.

Fortunately so far many customers are willing to sponsor the preliminary stages :).

Chhanges

[Anonymous Coward]

face the change and quit trying to shovel technology from the 1970's

Re:Chhanges

[Anonymous Coward]

face the change and quit trying to shovel technology from the 1970's

By that logic you'd better be ready to give up fire, the wheel, power machinery, telephone communications, antibiotics, computers, and everything else that wasn't invented or discovered until your amazingly short attention span began.

Fuckwit. More of what you depend on daily is running on what you erroneously describe as "1970's" technology than you can imagine. Fuckwit.

Training != experience

[CrazedWalrus]

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

Lathe? Welding?

[sczimme]

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.

:-)

"drive forward and encourage growth." ??!

[Viol8]

Oh give it a rest with the fscking marketing speak! SOunds to me like you're
fresh out of newbie training yourself or you wouldn't even go within a mile of
someone uttering that BS newspeak, never mind come out with it yourself.

Ugh Primos...

[Anonymous Coward]

One of the scariest projects I was ever on was replacing a very lucrative financial application that ran on a Prime. This was about 10 years ago, Prime was long gone, and there was an informal network of people desparate for parts.

The Prime sat in the computer room with about tangle of accumulated wiring a foot deep behind it. Nobody knew where anything went. Nobody traced anything, when they had to make a change they cut the old wire and dropped in a new one. It was unbelievable.

There was one guy who understood the prime code, and he was a bit of a jerk, and a bit miffed that his position of absolute guruhood was being threatened.

The point? My guess is that there are a lot of companies out there relying on very old hardware and software to get their jobs done, and when they go, it's going to be very hard to recover.

-- ac at work

because they can, even if they shouldn't

[paulsomm]

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.

Re:Rubbish

[cabazorro]

The old saying goes:
Chango viejo no aprende trucos nuevos
Méxicos work laws are a joke
. Fairness is a void concept in México.
What México calls business practice in other countries is called abuse-discrimination.

Re:duh

[tomhudson]

Context - I was ragging about source, I showed source - and the last I looked, the tag is 100% html 4.01 compliant, though w3c.org prefer you use <strong> :-)

Just like the source to the above:

Context - I was ragging about source, I showed source - and the last I looked, the &lt;b&gt; tag is <b>100% html 4.01 compliant</b>, though w3c.org prefer you use &lt;strong&gt; :-)

On a side note, does ANYONE use <strong> when hand-coding?

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:This is bigger than an IT problem

[Anonymous Coward]

Of course, the threat of a terminated employee stealing a company property is a different problem and is not a good reason to keep them on board. The risk of a terminated employee doing something illegal and harmful on their way out has to be planned for in the termination planning.

Re:This is bigger than an IT problem

[LaCosaNostradamus]

Terrible, isn't it? Until a catastrophe happens, we workers are simply unable to convince managers, execs, board members and ultimately stockholders to make the continuing investments required to maintain installed plant.

Keep an eye out for accusations of employee incompetence with legacy systems. The IT industry is already being hit with accusations of "being unqualified" with employer needs, hence the use and abuse of the H1B and L1 visas. This kind of thing can carry over into all industries as all the golfing buddies seek to further demonize the American worker.

Re:Anyone can do this job ESPECIALLY w/ ISO stds

[Anonymous Coward]

"But, how do you replace intimate knowledge of network layout, homegrown code, machine function, and how to get around policies to get things done?" - by totallygeek (263191) on Sunday September 25, @07:30PM

You can't, not yet, not totally... VMWare type emulations apps + remote communications programs (e.g.-> Terminal Server based technologies like RDP/Citrix with ICA/PCAnywhere & the like) are the key to THAT imo.

This area you mention? That's ONLY a matter of time... especially with ISO standards documentation in place, that outlines the intimate details of one of your examples - network topology intimate knowledge that makes YOU, you, for your employer: The SOLE keyholder to said areas.

Thus, you become a "non-expendable asset", which in their eyes, makes you dangerous & unreplaceable.

In fact, this 'strategem' of outsourcing's been what has forced myself @ least to seek more of my "roots" in this field as employ again (generally forensics work now), & that being what you state - network engineering/administration type roles, rather than coding ones exclusively, in order to survive.

Network Engineering/Administration? It is MUCH simpler than coding imo, which IS a "good side" to this change on my end, but not nearly as high-paying. I speak from having done both for years. It may be opinion, but from having been to both sides of both, & to "enterprise class" size program designs as well as multi-campus/multi-tier network designs & administration.

You have to understand 1 thing my man (but, I think you do already so I am preaching to the choir in you totallygeek) - business is out to make you an EXTREMELY "replaceable spark-plug" & expendable asset.

Why? Go to the very root/foundations of it - the Stock Market! It's always forcing 'boards of directors' to go reaming the butts of mgt. in companies' is why, for MORE PROFIT!

(I have always wondered - how much is enough? How many yachts & private jet planes does a wealthy man need before he feels his penis is large enough basically/in essence?? And, if that is not his view, how much do you need to setup your descendants futures really???)

I don't know about you, but you have hit what I feel truly is, the "last bastion" of employ in this field & the fact that trying to ship, say a mass migration of systems overseas for a datawipe of their drives for instance, is NOT feasable or practical from a finance/accounting standpoint.

The "Holy Dollar" is apparently all that matter, with a LOAD of short-term thinking present out there in the world of business today... and what is the simplest thing for mgt. to control to show a short-term profit gain?

PAYROLLS!

Thus, the nature of the beast is used against itself - they still cannot manage that yet or dare it.

E.G. -> Especially if the data on the drives is highly volatile and NOT to be risked getting into the hands of others. You need somebody there securing said systems, locally.

TotallyGeek imo? You hit the nail on the head - IMO, in the U.S.A.??

The employment future for any computer geek's (as much as I hate to say it) in the U.S.A. is that of a network engineering menial - not that of a creative mind & doing coding due to outsourcing running rampant.

(Many networkers will not like how I put that, & I don't care - I'm NOT here to comfort you, but to point out facts & wake you up so you can "smell the coffee" is all... my methods might be questionable, but not the reasoning!)

Believe-you-me: I had to make this choice & go with it. Coding opportunities (my fav thing in this field to do) are disappearing faster & faster being sent overseas... & what bugs me the MOST?

Isn't that it affects ME so much directly, because it had, but mostly the fact that in business, the old successful motto of:

"You can shear a sheep many times, but skin him only once"

Has gone by the wayside. If you don't provide disposable income to us sheep (working-c

Call this an unfair generalization if you must ,

[Anonymous Coward]

but old people are no good at everything.

Again, absolutely, manifestly false. SPENGLER!!!

[mosel-saar-ruwer]

This myth that you seem to be invested in believing [or worshipping?] probably wasn't true thirty years ago - in the 1970s - when it was a pseudo-intellectual fad enjoying its fifteen minutes of fame.

Frankly, to believe that the earth's population is expanding - rather than beginning its descent into a death spiral - is akin to believing that the earth is flat, rather than round.

Again, I cannot overemphasize the importance of the work that "SPENGLER" is doing at the Asia Times:

The Complete Spengler

If you are the type of person who suffers from even the slightest twinge of curiosity, then please, please read his work.

Re:Lathe? Welding?

[sysadmn]

Welding on a lathe - how eighties!

The Clueless Suit Culture

[vacuum_tuber]

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

Re:Call this an unfair generalization if you must

[chawly]

But...but ... well, I'm quite good at being me. Of course I've had lots of experience.

Re:Again, absolutely, manifestly false. SPENGLER!!

[J.R. Random]

I do wonder who keeps modding this guy up.

I don't see any reason to give this "Spengler" guy more authority than the U.S. Census Bureau.

screw that 'older workers legacy' stuff

[dmh20002]

in the defense/aerospace world I work in, the older workers (40 on up to 60 something) do the cool hard stuff. we give the crap maintenance assignments to the new kids. You are no longer new after about 10 years experience. Our management knows that there is a large body of experience-based knowledge that you need to be able to cover all the bases when you are designing and building something to work in the real world and not in an air conditioned computer room. In this world, being an employee with 20 years+ at the company is a big plus, not a negative.

Agreed!

[Anonymous Coward]

I'm 25 and have been writing Cobol and maintaining ERP systems for the last 5 or so years. I'm the youngest guy I've seen in this profession (for this particular ERP anyways) and NEVER use Cobol outside of this product (although I have and have had other responsibilities.) As you can imagine, this gives me a fairly narrow level of experience w/the language, not to mention the tools and language standard (cobol-85) are ancient and unweildly.

We've been recruiting for over a year to land another Cobol programmer with no luck. We either get old salts who are overqualified or folks with no practical experience in anything (windows monkeys.)

Cobol just isn't as accessible, fun to use or attractive for future employers, that's why it's dying off. Myself? I've just applied for an email admin position, I'm trying to distance myself from the ERP space, it's profitable if you want to consult, but it's just not my thing anymore. I want to stay current, even if it means competing with a larger pool of talent.

I'm going to be 50 so what to do?????

[RamblerRandy]

So when I finally get the BA every business said I needed I'll be too old to be employed in IT so what line of work should I pursue? Landscape Architecture?

We are turning off the Mainframe next week

[Anonymous Coward]

I work in a mid-size, important Federal government agency.
With the new Federal Fiscal year, we will port all of our systems off to a wintel/sql server environ. We also moved all data, flat files, and loaded into sql server databases.
Today, I ftp's all of our old COBOL apps over to the server, just for the documentation. We are keeping all flat file data too. Does anybody have an IBM mainframe tape reader for a wintel box?
But back to the subject at hand, we have boxes and boxes of useless documentation. I am probabally the only one in the building who could (and did until Oct 1) support the mainframe apps.
Don't cry for me, I am fluent in sql server, access, c#.net and Crystal Reports, so I can and will support the same apps in the new environ as I did in the prev. We still dont have any documentation, even tho the developer/contractor team gets the "big bucks".
I have yet to see good documentation in any mainframe (or other) environment. The reason is obvious, it is economic. It is also short-sighted, and i could use a few other non-complementary adjectives.