Slashdot Mirror
Keeping the Lights On
An anonymous reader wrote to mention an IBM article examining the role that older workers, experienced with legacy systems, should play in system maintenance. From the article: "Many enterprises still execute critical business operations ... via older software systems that run on large, mainframe computers rather than individual PCs. To meet changing business needs, these companies continually update, extend, and integrate their systems. Paradoxically, many of these companies also have policies that threaten the single greatest source of knowledge about their older systems: their most senior personnel. Although the aging workforce represents a vast pool of talent and experience, these businesses neither actively recruit senior workers nor provide incentives to retain those on staff.1 Instead, they mistakenly assume that they can hire younger, lower-paid people to perform the same tasks."
For more information see this link.
Just sit there and believe that, while you watch the infrastructure go down the tubes. Most of the training for any platform is more to advertise it then to really teach how to use it. Someone experience know that not everything that is documents that should work will work. An example an Old Prime Mainframe of a particular OS level supports TCP/IP and all the documents show that the system when the Gateway is set it will be used to get out on different subnets but in reality also you can enter in the gateway address it never uses it, and stays in its subnet, when these systems were made the internet wasn't very popular and TCP/IP was use for intranet usage, no one needed to go to a different subnet until Prime went out of business, when the internet became more useful. So all the training and reading the Prime books tell you that this will work all fine and dandy but in reality it doesn't work. Experience would save you many hours tinkering with the system trying to get it to work right vs. Using the knowledge that it doesn't work right and spending the time on a good workaround. A work around could take 8 hours, vs. Trying to get it to work could take weeks until you gave up and went to a work around.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
In an ideal world, much of that would be handled by appropriate documentation. In the real world, it gets harder...
We like to call ourselves professionsals, but compare our jobs to that of, say, a mechanical engineer. An engineer who jumps on the lathe and starts welding without designing and documenting what he's doing is little more than a skilled craftsman IMO - same for most of us IT guys. There's little to evaluate and test against when something goes wrong later, and the next guy to face your work has to reverse-engineer it before actually doing his job.
The "intimate knowledge" should be written as explicitly a possible, and common workarounds can be put in a cookbook format. Some things - like the political stuff - probably has to be passed word-of-mouth though. We all know about the ongoing costs of IT, and how big an issue maintanence is, so even 1 afternoon a week to write it up is worthwhile in the long term. The problem is pretty common in IT, but IMO it's not good enough (I'm not perfect either). It's a cultural issue, I think... too much hacking and "getting it done" and not enough planning and documentation.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
The director's *do* a lot of the surgery you dumb ass, why do you think they pay them the big $$? Stand around and consult? And the grunt work?? That is handled by the RESIDENTS, because it is exactly that. The difficult surgeries, you better believe the senior staff member is in the OR.
I can attest to the fact that hiring older, experienced workers is becoming more and more difficult. Let me tell you that it's harder for us old farts to find work than it is companies to fill the aforementioned vacancies. I'm in my early forties, and I find it increasingly difficult to compete in today's job market--it seems to me that many companies are after getting workers on the cheap rather than hiring experienced individuals.
Yes, one could probably get two fresh grads for the price of my salary, but where and when does experience and wisdom rule over copper-tops?
-Scott
My other sig is a Glock
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
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'.