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

[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

[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

[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

[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"!

What usually happens...

[Dekortage]

The article states, "For a truly objective assessment, it is usually best to engage an external consultant who is not involved with system maintenance. However, senior organization members are an invaluable resource for these consultants." No, what usually happens (in my experience, 20+ years IT) is that the seniors get fired, then have to be hired back as consultants at 3x their former pay.

Ask a relevant question

[Anonymous Coward]

Who would you rather operate on you: A young surgeon, or an older surgeon with years of experience? (I know, programming/administration != surgery, but I think most people will understand the point.)

Re:Ask a relevant question

[slavemowgli]

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

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

Re:Ask a relevant question

[Now.Imperfect]

Also the young doctor(IT guy) is fresh out of training and knows the latest techniques and is probably more willing to drive forward and encourage growth. Where as the older doctor is losing his steady hand(or his memory for the IT guy) and has been using the same stuff and probably has nearly no drive to keep the technology somewhat current. I see it in my dad, who I'd say is one helluva a sys admin with his grasp of security/networking in general, but its obvious that his age does effect his way of thinking... and its not always "wiser" imho.

Re:Ask a relevant question

[taloobie]

I would want the best trained, most open minded, most passionate person working on me. Number of surgeries is not a qualifier in of itself. The young vs. old or sr. vs. jr argument is so tired. I've worked as a developer and product manager in several companies and on many projects and I find that age and length of career has no correlation to the quality of work coming from techies. In fact, I've found just as many ill-prepared older techies as younger ones. To me, it comes down to whether people are interested in the problems they are working on. Generally most problems will require anyone to train and learn.

Re:Ask a relevant question

[SillyNickName4me]

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

No, it is a matter of choice.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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.

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

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.

Well..

[thisnamewastaken]

I'm sure this article was posted here, but remember also that IBM is sending employees back to school to learn how to become teachers. This program, from what I gathered, is aimed primarily at the 'older' workers, because they could afford a salary drop. Ironic?

Wow. The thermostat in Hell just clicked on

[FlyingSpank]

An article, published on IBM's site, shows the value in older workers.

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

However.

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

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

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

A bit harsh ? Yes, probably.

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

Yeah. A touch grumpy.

Big iron

[Saiyine]

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

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

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.

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

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.

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

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

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

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

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

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.

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?

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

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

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

When you get older....

[deanj]

I'm surprised at the number of young engineers who think that the "old guys" don't know anything about the "latest" tech.

A while back I heard an intern going on and on about how the young engineers (and he considered himself one, even though he hadn't graduated yet) were the best ones to come up with the new ideas for everything. The "old guys" just didn't have what it takes.

What a fool.

This isn't a "young" or "old" thing. This is a "good idea" thing. That comes from being a good engineer, not being young or old.

Not every young guy pays attention the latest technology, just like the old guys don't just stick their head in the sand when it comes to the new stuff. As a matter of fact, the older guys were the ones that were dinking around with all that new computer tech back in the day. Most of them did a lot more than the "fresh outs" do today.

If you're one of those guys that believe that the young guys are the stars when it comes to engineering, and the old guys should just step out of the way..... well, you're going to get old too. When that happens, I seriously doubt you'll feel the same way that you do now.

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

Maintenance Strategies

[anorlunda]

There's more to it than senior versus junior IT workers. The following clips from the article help illustrate.

"Precisely when the organization is trying to gain a return on investment, software operating costs may start to climb. ... At this point, support costs can start to consume a larger and larger part of the IT budget, severely limiting new investments."

The company often feels that software maintainers are extorting money from them. That's especially true when the application is not an external package continuously upgraded with new features. Managers expect that a paid-up static application should cost zero to maintain. This was made very plain when Y2K remediation work was complete and the Y2K workers, young and old, were booted out the door with parting greetings that sounded like "good riddance."

As a senior (now retired) software type I wrestled with the software maintenance dilemma for decades. I saw that old code was designed for the CPU and memory limitations of its day. As time marched on Moore's Law rendered old code useless faster than poor documentation or obscure programming languages.

At one point I resolved to put an upper limit of 10 years on the life of any code. After that it would have to be discarded and replaced. Then I realized that if everyone followed that policy future generations would be doomed to reinventing the wheels (i.e. the logic) invented in earlier versions. Actual progress would approach zero asymptotically. Consider for example code to control a nuclear plant. The plant has a 45 year lifetime, and the laws of physics and principles of control don't change in that time. If we had to reinvent all the control software four or five times in the life of the plant, it would be a terrible waste. The most modern implementation might be more efficient and superior in quality, but there is no assurance that it does a better or as good a job at controlling the plant as the first version.

Both extremes are wrong. Maintaining old static applications indefinitely is wrong. Periodic discard and replacement is wrong. My final conclusion was that old applications need to be rewritten and re-implemented and expanded and modernized gradually. If we re-write or re-implement 10% of the code every year, then none of the parts get to be more than 10 years old. We also deliberately blur the boundaries between old and new applications and the boundaries between developers and maintainers.

In my experience developers resist this notion more than management. Developers love reinventing wheels. I bet every open source developer worth his salt would love nothing more than his/her own chance to invent Unix from scratch, and along the way every application and algorithm that went with it. In any case, they really hate the idea of re-implementing some predecessor's cleverness embodied as code. They would much rather create their own fresh version confident that they can be cleverer than anyone else. It goes with the territory when we seek creative people to program. They like to create -- duh.

One other thing, when our gradual rewrites of old code reach the point where everything is fully expressed as objects, then the burden of rewrites and maintenance should be drastically reduced forever after. Isn't that the promise of objects? Expandability? Adaptability? Any large application well founded on objects should be able to morph itself into any future application one little bit at a time.

Re:Maintenance Strategies

[ciggieposeur]

One other thing, when our gradual rewrites of old code reach the point where everything is fully expressed as objects, then the burden of rewrites and maintenance should be drastically reduced forever after. Isn't that the promise of objects? Expandability? Adaptability? Any large application well founded on objects should be able to morph itself into any future application one little bit at a time.

The answer is "No, for all practical purposes". The most widely-used OOP languages are not much more than structs-with-function-pointers with some syntactic sugar on top. May as well just use C and pass function pointers around like the Linux kernel does. The "real" OOP languages are not as widely deployed as Java or C++, and the skillset is definitely not everywhere. Furthermore, OOP solutions work well when systems can be thought of that way, and not all systems should be.

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

How indispensable?

[mcraig]

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

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.

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.

:-)

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.

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

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