This is a great point. It turns out that there are many companies with a track record of hiring "permanent" employees to fulfill a large contract, and then firing them when the contract is over.
Defense contractors are some of the worst offenders. I've lived in the NE/Boston area for a long time, and I've seen wave after wave of hire/fires over the years, as these companies' fortunes wax and wane with the latest and greatest contracts (or completion of contracts) from Uncle Sam.
From the companies' standpoint, one can see that they're over a barrel. What are they supposed to do? It's a feast/famine type situation, and a lot of defense contracts seem to be awarded rather capriciously. It's hard to manage the business such that contracts can be overlapped and disruptions of employment avoided.
From the employees' standpoint, it's a disaster. One minute you're making great money, the next minute you're on the street. And, if you've been employed for a while, you have a "defense" resume, which tends to be a liability in a commercial setting. Many defense environments move slowly, have lots of overhead and procedures, ship products infrequently, have large teams to do relatively trivial things, and so on. That does not translate well to a fast-moving high tech company.
mabhatter's comment goes right to the heart of the debate. There is bound to be a heavy dependency from Munich's power users on Access and Excel, which are the de facto tools for complex ad hoc financial analysis. These users will absolutely NOT be satisfied with anything else, period, end of debate.
So, the only way to make those folks happy is to give them VMWare and a real copy of Office. How many of these users are there, really? Probably not that many. Maybe fifty or so.
But, the problem with giving them VMWare and Office is that everyone who wants to use their work (and this will be "almost everybody else") will also need a copy of Office in order to do so (unless all the macros are flattened out etc., which won't fly).
This is a viral situation. I do not see a solution in the short term. The long-term solution, of course, is to get Office running under Linux, which is why IBM is going down that road. However, Microsoft will not cooperate with any such effort, for reasons that are obvious to everyone but the bonehead judge administering what's left of the Microsoft Monopoly Case.
You're probably too young to remember the Libby's ad, starring Libby the Kid, who always finished the ad by saying "I'm Libby the Kid. That's Billy the Kid spelled sideways, sort of."
Nice of you to re-post. Obviously you are a gentleman/gentlelady.
I've used CountBrass's strategy for years. Allow me to elaborate on point (3):
3) Unless the meeting requires my participation or captures my interest within the first five minutes, I stand up and say, "Excuse me, but I'm not really sure why I'm here. I'm a little behind schedule on my work. Is it OK if I leave? I'll be in my office and I'll make sure I'm available for the next [hour, whatever]. Call me if you need me, and I'll be back immediately." Then I get up and start to leave. If nobody objects, I'm gone.
I've only gotten yelled at once or twice for this. Definitely worth it. I have skipped hundreds of useless meetings. The few times when I have been yelled at, I just say, "Oh, I'm sorry. I hadn't heard anything so far that was relevant to me, or that I could contribute to. My mistake, I guess."
This usually collapses the meeting to the real issues rather quickly, rather than subjecting everyone to 30 minutes of spin before the hammer falls. It doesn't endear you to the person that called the meeting, but they'll think twice before inviting you to the next meeting.
If you're a manager, half the time you're invited just as a courtesy anyway. The above strategy quickly disabuses anyone of the notion that you consider it a courtesy. In fact, you consider it an annoyance. Pretty soon, you're only invited to meetings that you really need to attend.
6.251 was an unusual course, taught by unusual people (John Donovan and Stuart Madnick). Both ended up at MIT's Sloan School. Rumors at the time were that they were forced out by EE department politics. Don't know where they are today.
For example, if you hacked the grading program, you got an "A". They figured if you were smart enough to hack them, you were smart enough to do the assignment anyway. Great guys.
The idea of 6.251 and its follow-on course, which by that time was taught out of the Sloan School (oddly), was "immersion" into the reality of CS, rather than spending a lot of time on largely academic fantasies like funarg problems (a real-world example of which I've seen once in a 25-year career).
How do you sort? How do you search? Why do you sort and search? How do those algorithms really work? What's a relocating loader? What's virtual memory? What's a compiler? What's an operating system? And throughout, write a boatload of code, starting with assembler, finishing with a big piece of a compiler in PL1/F.
If I look back on my undergraduate education, that was the single most valuable course I took. I don't even remember the "core" CS courses. OK, I guess I remember funarg problems.
And it takes some intelligence to realize that there are many tasks more easily done with Visual Basic than with any other tool.
So next time you feel yourself scoffing, think about some concrete things like how long it's going to take you to do the same thing that'll take me about 30 seconds.
And with all the outsourcing uproar out there, any tool that makes you incredibly productive is something you should embrace, not scorn. VB lets you prototype software and have it working the same day the PHB asks for it. Most of the time, it doesn't matter a goddamn how you did it, just that it got done.
Ridiculous. At MIT (6.251) they threw IBM Assembler H and 370 Principles of Operation manuals at us on the first day of class, and we had to teach ourselves. The lecturer just ASSUMED we knew the language. The first programming project was due 3 weeks into the course. I think there were a couple of "extra" TA sessions for those who didn't get it, but that's it.
And, that was 1973. The projects were on punch cards. No full-screen editors, no CRT's, not even a printing terminal. So we had to learn to program keypunches, dup and sequence card decks, learn enough JCL to get by, and so forth -- also on our own.
I guess nowadays it's "Oh, wait a minute... is my object model right?"
No, asshole, half the programming you do ISN'T object-oriented, OK?? And a significant piece of the other half shouldn't be written in Java, OK?? Oh, and by the way, that piece of SHIT code you wrote, multiplied by all the other pieces of SHIT code that you've written so far, adds up to ONE SLOW M-FING APPLICATION, in case you didn't notice.
Remember, we used to run pretty effective word processors in a 48K TPA on a 4mhz Z80. Think about that the next time you power up 37 megabytes worth of MS Word.
I kid you not. "States I Have Been In." This was a section of the guy's resume, covering most of an entire page. We almost brought the guy in just to see what he looked like, but wiser heads prevailed.
Best hiring story: Had a guy show up for a hardware engineering position, to design microprocessor motherboards (Z80's, 64180's, 8051's). The guy was from Raytheon or some other dumbfuck DOD-funded outfit. His experience? He was part of a 20-man (!) team that built a Z80 motherboard. His responsibility, over the 18 months of the project (!) was to -- get this -- design the DRAM circuit. Whoo hoo. When we told him we expected a soup-to-nuts, zero-fault board to show up in 60-90 days (average), and we expected him to design the whole thing himself, he got up and left!
I've been a senior software executive for 20 years. I've never met a CEO who was interested in direct criticism (or even suggestions) from line employees, no matter what s/he says.
Period.
So my advice is, work through your manager or director. If s/he is a fool, change jobs. There's no relief at the top, because the agenda is usually SO DIFFERENT from what you may imagine. Your concerns will either be twisted into some political nonsense, or misunderstood, or ignored, or (worst) used to screw you directly or indirectly, either now or later.
You make some excellent arguments. I agree, physical proximity is extremely important for solid communication, and a willingness to accept risk can partially counter the lower labor costs of the offshore providers.
As you point out, though, there will continue to be pressure on rates.
From a budget perspective, offshore resources are less expensive than permanent hires, who are in turn less expensive than local contractors. You are suggesting substitution of the most expensive resource for the least expensive. Your suggestion makes sense if you believe that contractors can produce the same productivity edge over permanent hires that I claimed really good local permanent hires would have had over the overseas resources we used. Unfortunately, in my experience this is not true. Contract personnel are generally equivalent to really good permanent hires in terms of productivity. The numbers, therefore, don't work.
As far as the giant sucking noise is concerned, it continues all around us. I've moved on to better things, and I don't have any offshore resources at the moment. But it's clear to me that this issue isn't going to go away, and it's also very clear to me that if I am ever in the position of competing with an organization that can swarm a problem for 1/3 the cost that I can, I lose.
There will always be highly-paid jobs for people who can do amazing things, but to the extent that basic programming skills are a commodity, and (let's face it) they are increasingly commoditized for a lot of business applications, there will be movement of work to the cheapest labor sources.
I do suspect that offshore resources will be perceived as less competitive over time. This is because there are hidden management and communications costs in dealing with offshore resources that raise their effective cost. But we'll need to wait for another year or so before that realization sinks in.
I moved four projects to India with reasonable success. We did not use a lowest-cost provider; instead, we used a company that charges more than Wipro or Infosys, but fields better talent than they do (in fact, they cherry-pick from Wipro and Infosys for new recruits).
Here are my conclusions:
1) We were able to ramp up faster than if we had tried to hire locally. 2) We were able to overcome personnel issues more quickly -- the vendor was able to add higher-powered programmers very quickly when they got into trouble, and "swarm" the problem with bodies. In our case (simple Web apps) it worked, although there are situations in which it obviously would not have worked (mythical man-month, blah blah blah). 3) The quality of the finished product was reasonable. Call it B/B-. Which was OK for us, maybe not good enough for some, but acceptable.
It turns out that if I had hired a much smaller number of local programmers as permanent employees (consultant rates would not have worked) -- very good ones at market prices -- and they had performed up to expectations -- I could probably have brought the same projects in on the same schedule for the same price. I probably would have ended up with a better architecture, and better code.
So maybe it's a wash. Except, I would have had the following problems:
1) Hire/fire. When the work was over, I didn't need the teams any more. With the Indian vendor, I could cut back without worry. With permanent hires, I'd have a serious morale problem. 2) Risk. If my gunslingers ran into a problem, I wouldn't have been able to "throw bodies" at it. My budget wouldn't have allowed for that. 3) Maintenance risk. The Indian teams can be scaled way back, but I could still keep 3 people on the project for continuity. If I scaled back my own teams similarly, I'd only be able to save one job, and if that person quit, I'd be hosed.
So there are a lot of subtle factors that play here. The Business Week guy alludes to them, but doesn't really itemize them well.
I hate to puncture the "I love QNX" bubble, but I've seen plenty of kernel dies on QNX 4. I used it heavily 1992-1995. They have their own version of the Blue Screen of Death, which I remember vividly. And maybe this is just me, but a bug in the filesystem takes down any system I've ever built, I don't care if the kernel is still up or not. The kernel keeps running? So what?
Yeah, yeah, nuclear power plants, medical monitors, blah blah blah. I've heard the schtick. Maybe I buy it, maybe I don't. Can't forget the Blue Screens of Death, though.
... to 1976. Remember PSL/PSA? RSL/RSA? All their brethren and siblings? Probably not -- many of you hadn't yet achieved zygote status at that point.
Anyway, the same breathless hysteria about how processes improved, productivity increased, errors decreased, etc. etc. blah blah blah was rampant back then. I was a (very) junior member of a non-profit team hired by the Army to figure out whether these claims were true or false.
Our conclusions were simple. The productivity and other claims were hopelessly inflated. However, we were able to conclude that any systematic methodology seemed to produce somewhat better results than no methodology at all -- and it didn't really matter what the methodology was.
In most cases, as a programmer peon, you really don't know what's actually going on in your company. Oh, sure, you think you do, but you don't. Do you review the sales pipeline every week? Do you know the state of your company's balance sheet and financials? How about its credit facilities and payables? When's the last time you sat down with the bankers or the investors and heard the real story?
Do you really know what's going on with the competition, or do you just believe what the suits tell you? Is the pricing strategy correct, or are the Marketing people on drugs?
The problem we all face when we are in your situation is that we are operating in a vacuum. I've been a coder my whole life, spent the last 10 years in upper level management positions. Let me tell you something profound: You do not know what upper management knows. They will never tell you the whole truth. Therefore, you cannot make a rational determination as to whether this request to work overtime is reasonable and thoughtful, or whether it is just the last frantic thrashing of the whale's tail before death.
I've been coding for 32 years, I've started two companies, worked for many. Here are two general observations that may or may not apply to your specific situation:
1. If you are working massive overtime, do so because you are starting a company on the side, not because your current company has understaffed the department.
2. It is easy to believe in your own importance, and that you can make a difference by working OT. Sadly, you probably won't make any difference at all.
1) BEA releases really bad code. Version 6.0 almost cost me my job. 2) BEA costs a fucking fortune. 3) JBOSS is way faster. 4) JBOSS deploys apps better. 5) JBOSS is extremely stable. 6) JBOSS support is better - I get better answers from the open sourcers than I got from the paid support we had with BEA.
We've ripped BEA out of 5 apps, working on #6. The sooner we are BEA-free, the better. We'll never look back.
I suggest you change the way you make a living, bro, before it's too late.
Seriously, you have to be nuts to use Websphere or BEA when JBOSS is available for free.
Wiring has noise problems, plus you have to install special crossovers to get past transformers in large buildings. There are commercial systems that use wiring, but the bandwidth is not that high. Last time I checked, about 6 years ago, it was hovering around 9600 baud. Anybody have more recent info?
The Massachusetts Turnpike, also labeled I-90, is a ridiculously expensive limited access toll road running the length of the state of Massachusetts.
The time you get on is known. The time you get off is known. It's been known for 20 years. All the state has to do is subtract the times, divide by the distance, and if you averaged more than 65 mph (the Pike's speed limit), you're docked by mail.
This has never happened. It never *will* happen. If Massachusetts was serious about stopping speeders on the Pike, it would have implemented a system like this 20 years ago.
There is no political will in the United States to stop speeding. We *like* to speed, and we don't like people who try to stop us.
So chill. Let the Brits have their fun. It'll never happen here.
You're totally missing the point. YOU HAVE TO THINK LIKE A SENIOR EXECUTIVE, not like a worker bee.
Basically, every failing company represents an opportunity. How far are you going to get at some stable company like, say, HP? And how quickly? Gee, there's only 50,000 engineers JUST LIKE YOU who work there.
So, think a minute. You know this company inside out. You probably even know what to do to fix it.
So what would induce you to stay at this sinking ship? I'm sure there's a price. Money, equity (no matter how remote the possibility of realizing it), a management position so you can fix what's wrong -- all of the above -- something.
The way an senior executive reasons about this is, OK, here's what I need to make this an OPPORTUNITY for myself rather than JUST A JOB.
A job is an employment CONTRACT, no different than a temporary job, because they can fire you at a moment's notice, and they will, if it suits them.
So, think about it clearly. Draw up what position you want, propose a compensation arrangement, lay out your plans for what you would do to turn things around, make an appointment with the CEO, and MAKE YOUR PITCH.
That's the best way to help yourself and your friends. If the CEO laughs you out of his/her office, then you move on, because you can't help anyone, including yourself.
Remember: YOU WERE LOOKING FOR A JOB WHEN YOU FOUND THIS ONE.
to link to a redirecting page. An ordinary link to a redirecting page will leave your hapless user with no "back" capability, since when he hits "back", he'll get redirected again back to.. er.. where he is. Chances are he also doesn't know how to use "history" to find his way home. Buh-bye.
Another reason to open a page in a new window with javascript is to keep your primary page visible. Many novice users don't know how to right-click to open a link in a new window. Instead, they keep redisplaying the root window over and over again by going "back" to it. This tends to be slow, and tends to piss people off. You risk them experiencing "lack of attention span fever" and going elsewhere.
You can solve this on your own pages with a navigation frame or with navigation tables that replicate everywhere, but what about foreign links? Serving up other people's pages in frames is not a good solution for lots of different reasons which I won't go into here.
So, yeah, there are good reasons to use javascript to pop up linked pages. But I also agree with your general complaint -- too many automated page generation tools generate stuff for no apparent reason.
I've been on the other side of this, and firing people really sucks. Over the last 12 years I've done it to three people for cause, and to three other people (at one shot) because of events beyond my control (reorganization).
There's no easy way to do it. On the reorg, it was done professionally and was completely out of my control. Laid-off people were met at the door when they arrived and escorted to their work areas where boxes had been set up for them to pack their things. Then they were escorted to a holding area where HR lectured them on their options. The rest of the employees were sent to a central meeting area where the layoff actions and reasons were explained.
On the cause side, I'm not proud of my first effort. The guy turned out to be incredibly strange. He interviewed well, but when he started work he didn't seem to understand instructions, and he couldn't communicate with the other employees. After a few weeks he became upset and sullen. Nobody could understand what he was upset about. He didn't seem to understand or to be able to follow verbal instructions. Finally I gave him written instructions on what to do one week, and reviewed his progress at the end of the week. There had been none. So I gently told him I would have to let him go. He did not seem to understand. I repeated this about 6 different ways, but he still didn't seem to understand. Finally after about 10 minutes of this I completely lost it and just yelled at him, "HERE IS A BOX. GO TO YOUR DESK. PACK UP YOUR THINGS. GET OUT. CALL HUMAN RESOURCES TOMORROW. GET OUT NOW. GO." This is literally true. It was as ugly as you could imagine. Everyone was horrified (although sympathetic).
The second two firings (done together) I handled better. I had taken over an Engineering organization for a turn-around effort. I gave everyone tasks, and most people responded really well with great original ideas and enthusiasm. Two guys didn't seem to "get it", though. A more experienced manager urged me to fire them immediately. He said that on a turn-around effort, the people that aren't willing to turn things around stand in the back with their hands up (figuratively), saying "Please fire me." But I didn't listen, and kept giving them more chances. Finally after two months it became clear that they simply couldn't (or wouldn't) do their jobs, and I had to fire them. I met with them individually, and explained that I couldn't keep them on because they had not been able to accomplish their objectives. It was unpleasant, but I felt that I had given them every chance possible, so I could look them in the eye without flinching. So I felt that I handled it OK from a human perspective. From a business perspective, though, I really hosed up my schedule by keeping them on the payroll, because all their work had to be tossed and re-done by others. I should have taken the advice of the more senior manager.
No matter which way you cut it, firing people is hard and ugly and messy. Also many managers are avoidant -- they don't *want* any contact with the people they are firing. I think the right thing to do is to go face to face, regardless of what happens. Even if the employees are angry, and they probably will be, at least they will respect you later for having the guts to talk to them mano a mano and explain in detail why they're being let go. And you can keep your self-respect too, for being honest.
Like anything else, one learns by doing. A lot of people become "managers" way before they're ready. It's not surprising that they fuck up the hiring/firing process -- where were they supposed to learn how to do it? Business school? Don't make me laugh.
Slashdot Mirror
Right, they don't sell beer. They sell PANTHER PISS. Blecch.
This is a great point. It turns out that there are many companies with a track record of hiring "permanent" employees to fulfill a large contract, and then firing them when the contract is over.
Defense contractors are some of the worst offenders. I've lived in the NE/Boston area for a long time, and I've seen wave after wave of hire/fires over the years, as these companies' fortunes wax and wane with the latest and greatest contracts (or completion of contracts) from Uncle Sam.
From the companies' standpoint, one can see that they're over a barrel. What are they supposed to do? It's a feast/famine type situation, and a lot of defense contracts seem to be awarded rather capriciously. It's hard to manage the business such that contracts can be overlapped and disruptions of employment avoided.
From the employees' standpoint, it's a disaster. One minute you're making great money, the next minute you're on the street. And, if you've been employed for a while, you have a "defense" resume, which tends to be a liability in a commercial setting. Many defense environments move slowly, have lots of overhead and procedures, ship products infrequently, have large teams to do relatively trivial things, and so on. That does not translate well to a fast-moving high tech company.
So, it could be worse for Our Hero.
mabhatter's comment goes right to the heart of the debate. There is bound to be a heavy dependency from Munich's power users on Access and Excel, which are the de facto tools for complex ad hoc financial analysis. These users will absolutely NOT be satisfied with anything else, period, end of debate.
So, the only way to make those folks happy is to give them VMWare and a real copy of Office. How many of these users are there, really? Probably not that many. Maybe fifty or so.
But, the problem with giving them VMWare and Office is that everyone who wants to use their work (and this will be "almost everybody else") will also need a copy of Office in order to do so (unless all the macros are flattened out etc., which won't fly).
This is a viral situation. I do not see a solution in the short term. The long-term solution, of course, is to get Office running under Linux, which is why IBM is going down that road. However, Microsoft will not cooperate with any such effort, for reasons that are obvious to everyone but the bonehead judge administering what's left of the Microsoft Monopoly Case.
You're probably too young to remember the Libby's ad, starring Libby the Kid, who always finished the ad by saying "I'm Libby the Kid. That's Billy the Kid spelled sideways, sort of."
Nice of you to re-post. Obviously you are a gentleman/gentlelady.
"Vole" is just love spelled sideways, sort of. I buy it.
This is the funniest post I've seen in years. Please encourage this person. Sir or madam, you are a fucking riot.
I've used CountBrass's strategy for years. Allow me to elaborate on point (3):
3) Unless the meeting requires my participation or captures my interest within the first five minutes, I stand up and say, "Excuse me, but I'm not really sure why I'm here. I'm a little behind schedule on my work. Is it OK if I leave? I'll be in my office and I'll make sure I'm available for the next [hour, whatever]. Call me if you need me, and I'll be back immediately." Then I get up and start to leave. If nobody objects, I'm gone.
I've only gotten yelled at once or twice for this. Definitely worth it. I have skipped hundreds of useless meetings. The few times when I have been yelled at, I just say, "Oh, I'm sorry. I hadn't heard anything so far that was relevant to me, or that I could contribute to. My mistake, I guess."
This usually collapses the meeting to the real issues rather quickly, rather than subjecting everyone to 30 minutes of spin before the hammer falls. It doesn't endear you to the person that called the meeting, but they'll think twice before inviting you to the next meeting.
If you're a manager, half the time you're invited just as a courtesy anyway. The above strategy quickly disabuses anyone of the notion that you consider it a courtesy. In fact, you consider it an annoyance. Pretty soon, you're only invited to meetings that you really need to attend.
6.251 was an unusual course, taught by unusual people (John Donovan and Stuart Madnick). Both ended up at MIT's Sloan School. Rumors at the time were that they were forced out by EE department politics. Don't know where they are today.
For example, if you hacked the grading program, you got an "A". They figured if you were smart enough to hack them, you were smart enough to do the assignment anyway. Great guys.
The idea of 6.251 and its follow-on course, which by that time was taught out of the Sloan School (oddly), was "immersion" into the reality of CS, rather than spending a lot of time on largely academic fantasies like funarg problems (a real-world example of which I've seen once in a 25-year career).
How do you sort? How do you search? Why do you sort and search? How do those algorithms really work? What's a relocating loader? What's virtual memory? What's a compiler? What's an operating system? And throughout, write a boatload of code, starting with assembler, finishing with a big piece of a compiler in PL1/F.
If I look back on my undergraduate education, that was the single most valuable course I took. I don't even remember the "core" CS courses. OK, I guess I remember funarg problems.
Don't know if I answered your question, but HTH.
And it takes some intelligence to realize that there are many tasks more easily done with Visual Basic than with any other tool.
So next time you feel yourself scoffing, think about some concrete things like how long it's going to take you to do the same thing that'll take me about 30 seconds.
And with all the outsourcing uproar out there, any tool that makes you incredibly productive is something you should embrace, not scorn. VB lets you prototype software and have it working the same day the PHB asks for it. Most of the time, it doesn't matter a goddamn how you did it, just that it got done.
Ridiculous. At MIT (6.251) they threw IBM Assembler H and 370 Principles of Operation manuals at us on the first day of class, and we had to teach ourselves. The lecturer just ASSUMED we knew the language. The first programming project was due 3 weeks into the course. I think there were a couple of "extra" TA sessions for those who didn't get it, but that's it.
And, that was 1973. The projects were on punch cards. No full-screen editors, no CRT's, not even a printing terminal. So we had to learn to program keypunches, dup and sequence card decks, learn enough JCL to get by, and so forth -- also on our own.
I guess nowadays it's "Oh, wait a minute... is my object model right?"
No, asshole, half the programming you do ISN'T object-oriented, OK?? And a significant piece of the other half shouldn't be written in Java, OK?? Oh, and by the way, that piece of SHIT code you wrote, multiplied by all the other pieces of SHIT code that you've written so far, adds up to ONE SLOW M-FING APPLICATION, in case you didn't notice.
Remember, we used to run pretty effective word processors in a 48K TPA on a 4mhz Z80. Think about that the next time you power up 37 megabytes worth of MS Word.
Christ.
OK, I feel better now. Thank you.
I kid you not. "States I Have Been In." This was a section of the guy's resume, covering most of an entire page. We almost brought the guy in just to see what he looked like, but wiser heads prevailed.
Best hiring story: Had a guy show up for a hardware engineering position, to design microprocessor motherboards (Z80's, 64180's, 8051's). The guy was from Raytheon or some other dumbfuck DOD-funded outfit. His experience? He was part of a 20-man (!) team that built a Z80 motherboard. His responsibility, over the 18 months of the project (!) was to -- get this -- design the DRAM circuit. Whoo hoo. When we told him we expected a soup-to-nuts, zero-fault board to show up in 60-90 days (average), and we expected him to design the whole thing himself, he got up and left!
I've been a senior software executive for 20 years. I've never met a CEO who was interested in direct criticism (or even suggestions) from line employees, no matter what s/he says.
Period.
So my advice is, work through your manager or director. If s/he is a fool, change jobs. There's no relief at the top, because the agenda is usually SO DIFFERENT from what you may imagine. Your concerns will either be twisted into some political nonsense, or misunderstood, or ignored, or (worst) used to screw you directly or indirectly, either now or later.
Be warned.
Re-read Conclusions, (2).
You make some excellent arguments. I agree, physical proximity is extremely important for solid communication, and a willingness to accept risk can partially counter the lower labor costs of the offshore providers.
As you point out, though, there will continue to be pressure on rates.
Sure, I'll explain.
From a budget perspective, offshore resources are less expensive than permanent hires, who are in turn less expensive than local contractors. You are suggesting substitution of the most expensive resource for the least expensive. Your suggestion makes sense if you believe that contractors can produce the same productivity edge over permanent hires that I claimed really good local permanent hires would have had over the overseas resources we used. Unfortunately, in my experience this is not true. Contract personnel are generally equivalent to really good permanent hires in terms of productivity. The numbers, therefore, don't work.
As far as the giant sucking noise is concerned, it continues all around us. I've moved on to better things, and I don't have any offshore resources at the moment. But it's clear to me that this issue isn't going to go away, and it's also very clear to me that if I am ever in the position of competing with an organization that can swarm a problem for 1/3 the cost that I can, I lose.
There will always be highly-paid jobs for people who can do amazing things, but to the extent that basic programming skills are a commodity, and (let's face it) they are increasingly commoditized for a lot of business applications, there will be movement of work to the cheapest labor sources.
I do suspect that offshore resources will be perceived as less competitive over time. This is because there are hidden management and communications costs in dealing with offshore resources that raise their effective cost. But we'll need to wait for another year or so before that realization sinks in.
I moved four projects to India with reasonable success. We did not use a lowest-cost provider; instead, we used a company that charges more than Wipro or Infosys, but fields better talent than they do (in fact, they cherry-pick from Wipro and Infosys for new recruits).
Here are my conclusions:
1) We were able to ramp up faster than if we had tried to hire locally.
2) We were able to overcome personnel issues more quickly -- the vendor was able to add higher-powered programmers very quickly when they got into trouble, and "swarm" the problem with bodies. In our case (simple Web apps) it worked, although there are situations in which it obviously would not have worked (mythical man-month, blah blah blah).
3) The quality of the finished product was reasonable. Call it B/B-. Which was OK for us, maybe not good enough for some, but acceptable.
It turns out that if I had hired a much smaller number of local programmers as permanent employees (consultant rates would not have worked) -- very good ones at market prices -- and they had performed up to expectations -- I could probably have brought the same projects in on the same schedule for the same price. I probably would have ended up with a better architecture, and better code.
So maybe it's a wash. Except, I would have had the following problems:
1) Hire/fire. When the work was over, I didn't need the teams any more. With the Indian vendor, I could cut back without worry. With permanent hires, I'd have a serious morale problem.
2) Risk. If my gunslingers ran into a problem, I wouldn't have been able to "throw bodies" at it. My budget wouldn't have allowed for that.
3) Maintenance risk. The Indian teams can be scaled way back, but I could still keep 3 people on the project for continuity. If I scaled back my own teams similarly, I'd only be able to save one job, and if that person quit, I'd be hosed.
So there are a lot of subtle factors that play here. The Business Week guy alludes to them, but doesn't really itemize them well.
I hate to puncture the "I love QNX" bubble, but I've seen plenty of kernel dies on QNX 4. I used it heavily 1992-1995. They have their own version of the Blue Screen of Death, which I remember vividly. And maybe this is just me, but a bug in the filesystem takes down any system I've ever built, I don't care if the kernel is still up or not. The kernel keeps running? So what?
Yeah, yeah, nuclear power plants, medical monitors, blah blah blah. I've heard the schtick. Maybe I buy it, maybe I don't. Can't forget the Blue Screens of Death, though.
... to 1976. Remember PSL/PSA? RSL/RSA? All their brethren and siblings? Probably not -- many of you hadn't yet achieved zygote status at that point.
Anyway, the same breathless hysteria about how processes improved, productivity increased, errors decreased, etc. etc. blah blah blah was rampant back then. I was a (very) junior member of a non-profit team hired by the Army to figure out whether these claims were true or false.
Our conclusions were simple. The productivity and other claims were hopelessly inflated. However, we were able to conclude that any systematic methodology seemed to produce somewhat better results than no methodology at all -- and it didn't really matter what the methodology was.
Deja vu all over again.
In most cases, as a programmer peon, you really don't know what's actually going on in your company. Oh, sure, you think you do, but you don't. Do you review the sales pipeline every week? Do you know the state of your company's balance sheet and financials? How about its credit facilities and payables? When's the last time you sat down with the bankers or the investors and heard the real story?
Do you really know what's going on with the competition, or do you just believe what the suits tell you? Is the pricing strategy correct, or are the Marketing people on drugs?
The problem we all face when we are in your situation is that we are operating in a vacuum. I've been a coder my whole life, spent the last 10 years in upper level management positions. Let me tell you something profound: You do not know what upper management knows. They will never tell you the whole truth. Therefore, you cannot make a rational determination as to whether this request to work overtime is reasonable and thoughtful, or whether it is just the last frantic thrashing of the whale's tail before death.
I've been coding for 32 years, I've started two companies, worked for many. Here are two general observations that may or may not apply to your specific situation:
1. If you are working massive overtime, do so because you are starting a company on the side, not because your current company has understaffed the department.
2. It is easy to believe in your own importance, and that you can make a difference by working OT. Sadly, you probably won't make any difference at all.
Hope this helps.
Golly, Alex, let's list the reasons.
1) BEA releases really bad code. Version 6.0 almost cost me my job.
2) BEA costs a fucking fortune.
3) JBOSS is way faster.
4) JBOSS deploys apps better.
5) JBOSS is extremely stable.
6) JBOSS support is better - I get better answers from the open sourcers than I got from the paid support we had with BEA.
We've ripped BEA out of 5 apps, working on #6. The sooner we are BEA-free, the better. We'll never look back.
I suggest you change the way you make a living, bro, before it's too late.
Seriously, you have to be nuts to use Websphere or BEA when JBOSS is available for free.
Wiring has noise problems, plus you have to install special crossovers to get past transformers in large buildings. There are commercial systems that use wiring, but the bandwidth is not that high. Last time I checked, about 6 years ago, it was hovering around 9600 baud. Anybody have more recent info?
The Massachusetts Turnpike, also labeled I-90, is a ridiculously expensive limited access toll road running the length of the state of Massachusetts.
The time you get on is known. The time you get off is known. It's been known for 20 years. All the state has to do is subtract the times, divide by the distance, and if you averaged more than 65 mph (the Pike's speed limit), you're docked by mail.
This has never happened. It never *will* happen. If Massachusetts was serious about stopping speeders on the Pike, it would have implemented a system like this 20 years ago.
There is no political will in the United States to stop speeding. We *like* to speed, and we don't like people who try to stop us.
So chill. Let the Brits have their fun. It'll never happen here.
You're totally missing the point. YOU HAVE TO THINK LIKE A SENIOR EXECUTIVE, not like a worker bee.
Basically, every failing company represents an opportunity. How far are you going to get at some stable company like, say, HP? And how quickly? Gee, there's only 50,000 engineers JUST LIKE YOU who work there.
So, think a minute. You know this company inside out. You probably even know what to do to fix it.
So what would induce you to stay at this sinking ship? I'm sure there's a price. Money, equity (no matter how remote the possibility of realizing it), a management position so you can fix what's wrong -- all of the above -- something.
The way an senior executive reasons about this is, OK, here's what I need to make this an OPPORTUNITY for myself rather than JUST A JOB.
A job is an employment CONTRACT, no different than a temporary job, because they can fire you at a moment's notice, and they will, if it suits them.
So, think about it clearly. Draw up what position you want, propose a compensation arrangement, lay out your plans for what you would do to turn things around, make an appointment with the CEO, and MAKE YOUR PITCH.
That's the best way to help yourself and your friends. If the CEO laughs you out of his/her office, then you move on, because you can't help anyone, including yourself.
Remember: YOU WERE LOOKING FOR A JOB WHEN YOU FOUND THIS ONE.
Well, for example, you're forced to use:
href=javascript:window.open("target.html"); document.window.back;
to link to a redirecting page. An ordinary link to a redirecting page will leave your hapless user with no "back" capability, since when he hits "back", he'll get redirected again back to.. er.. where he is. Chances are he also doesn't know how to use "history" to find his way home. Buh-bye.
Another reason to open a page in a new window with javascript is to keep your primary page visible. Many novice users don't know how to right-click to open a link in a new window. Instead, they keep redisplaying the root window over and over again by going "back" to it. This tends to be slow, and tends to piss people off. You risk them experiencing "lack of attention span fever" and going elsewhere.
You can solve this on your own pages with a navigation frame or with navigation tables that replicate everywhere, but what about foreign links? Serving up other people's pages in frames is not a good solution for lots of different reasons which I won't go into here.
So, yeah, there are good reasons to use javascript to pop up linked pages. But I also agree with your general complaint -- too many automated page generation tools generate stuff for no apparent reason.
I've been on the other side of this, and firing people really sucks. Over the last 12 years I've done it to three people for cause, and to three other people (at one shot) because of events beyond my control (reorganization).
There's no easy way to do it. On the reorg, it was done professionally and was completely out of my control. Laid-off people were met at the door when they arrived and escorted to their work areas where boxes had been set up for them to pack their things. Then they were escorted to a holding area where HR lectured them on their options. The rest of the employees were sent to a central meeting area where the layoff actions and reasons were explained.
On the cause side, I'm not proud of my first effort. The guy turned out to be incredibly strange. He interviewed well, but when he started work he didn't seem to understand instructions, and he couldn't communicate with the other employees. After a few weeks he became upset and sullen. Nobody could understand what he was upset about. He didn't seem to understand or to be able to follow verbal instructions. Finally I gave him written instructions on what to do one week, and reviewed his progress at the end of the week. There had been none. So I gently told him I would have to let him go. He did not seem to understand. I repeated this about 6 different ways, but he still didn't seem to understand. Finally after about 10 minutes of this I completely lost it and just yelled at him, "HERE IS A BOX. GO TO YOUR DESK. PACK UP YOUR THINGS. GET OUT. CALL HUMAN RESOURCES TOMORROW. GET OUT NOW. GO." This is literally true. It was as ugly as you could imagine. Everyone was horrified (although sympathetic).
The second two firings (done together) I handled better. I had taken over an Engineering organization for a turn-around effort. I gave everyone tasks, and most people responded really well with great original ideas and enthusiasm. Two guys didn't seem to "get it", though. A more experienced manager urged me to fire them immediately. He said that on a turn-around effort, the people that aren't willing to turn things around stand in the back with their hands up (figuratively), saying "Please fire me." But I didn't listen, and kept giving them more chances. Finally after two months it became clear that they simply couldn't (or wouldn't) do their jobs, and I had to fire them. I met with them individually, and explained that I couldn't keep them on because they had not been able to accomplish their objectives. It was unpleasant, but I felt that I had given them every chance possible, so I could look them in the eye without flinching. So I felt that I handled it OK from a human perspective. From a business perspective, though, I really hosed up my schedule by keeping them on the payroll, because all their work had to be tossed and re-done by others. I should have taken the advice of the more senior manager.
No matter which way you cut it, firing people is hard and ugly and messy. Also many managers are avoidant -- they don't *want* any contact with the people they are firing. I think the right thing to do is to go face to face, regardless of what happens. Even if the employees are angry, and they probably will be, at least they will respect you later for having the guts to talk to them mano a mano and explain in detail why they're being let go. And you can keep your self-respect too, for being honest.
Like anything else, one learns by doing. A lot of people become "managers" way before they're ready. It's not surprising that they fuck up the hiring/firing process -- where were they supposed to learn how to do it? Business school? Don't make me laugh.