Slashdot Mirror
Rise of the Corporate Skeleton Crew?
Big Stick asks: "Recently I have noticed a trend in several prominent companies in my area of laying off entire technology departments. Just this week in my own company--a division of a well known, mid-sized corporation--the software engineering department was let go en masse, rather than just a reduction in head count. The rationale for the move being that it would be easier to evaluate the potential cost of developing a new product if groups of contractors were hired, instead of the numbers getting lost in the 'free' work of the full time developers.
The overall impression this leaves is that many major companies are re-prioritizing the need to innovate new technologies for the presentation of their business, relying on skeleton crews of DBAs/SAs to maintain rather than enhance. The main question this raises is, are we heading towards an era where full time software development is more likely to be housed in technology specific firms? Something along the lines of the construction industry where projects are bid on, constructed, and the involvement of the creators with the finished product is minimal?" If others of you are noticing this trend in the industry, please share your thoughts. Do you think this is a move forward or backwards?
The simple answer to your question is Yes. It is cheaper to hire contractors because the benefits normally paid to full-time employees are not present. A full-time employee who makes $50K a year typically costs twice that when taking the cost of benefits into consideration. It makes much more sense to hire a contractor to write a piece of software in 2 or 3 months at $50/hr and let him go at the end of the stint. It's the same amount, but without the strings attached (like termination bonuses, etc).
As for the GPL, which the title alludes to, it is the biggest proponent of contract-based employment there is. Since the GPL encourages sharing, companies will not develop in-house applications on their own dime and then license the software under the GPL. Therefore GPL programmers will not find full-time positions in companies developing software.
This leaves only businesses that need a one-off program to do some sort of processing. This is where the GPL comes in, and is where the GPL really shines. Programmers who have at their disposal the full set of GPL code can use their knowledge in filling these one-off programming contracts. But it is doubtful that they would ever get hired on writing GPL'd code full-time.
In essence, the GPL is killing the concept of the programmer-career path. It is making it easy for companies to cut costs and build their systems upon free software. This means a dramatic drop in full-time headcount, as you have seen in your own experience.
I have been pwned because my
This reminds me of the Dilbert strip where the staff were fired and immediately rehired as contractors for more money ;-)
But, really, this is absolutely great news. Okay, maybe not for the people who were fired, or for people who are full time employees in technology divisions.. but for those of us who are contractors and freelancers, this is wonderful.
It makes more sense for those companies too. They save a heap on labor costs, and only pay for what actually gets done. It's illegal to constantly hire and fire staff according to workload, but it's not illegal to put work out to freelancers. This is the sort of business we live off of.
This sort of downsizing was all the rage in the early 90's and it led to the start of a massive boom for freelancers and contractors. Maybe this is the sign of the next boom. So, hey, perhaps the lull really is picking up folks. Let's hope.
mogorific carpentry experiments
How does this fit into the topic of this discussion? Companies are going into holding patterns, reducing costs and hoping that things will turn around soon. I predict a second wave of large reductions over the next few months. I point to an article that IBM is looking to let go up to 20,000 more staff by the end of the year. By letting whole departments go, costs are being reduced significantly. It also allows the company, if it survives, the ability to restructure, either by contracting work out or rebuilding.
Bottom line, keep the hatches battened down for further stormy weather. Bookmark this. Late in the year we will see if I am right or not.
What you implied, but left unsaid, is that outsourcing leads almost directly to cheaper goods for the consumer. Dana (assuming you mean the drivetrain company) specializes in drivetrains. Why not let them build and design the best drivetrain? Makes sense to me. Why try to build/design a car stereo when there are dozens of manufacturers out there.
The slashdot libertarians should be quite happy about things like this.
The real trick is that (to take the GM example again), does the 'assembling company' (GM) know how to assemble parts from disparate companies, or do they only know how to do the complete package?
BTW, not sure how any of this applies to software. I'm in the medical industry, and you let someone else deal with the government goons.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
Not all consultants are the spawn of evil, but the ability to walk away from something that goes wrong and have plenty of other companies still interested in your services does result in the failure of many a high profile project. In a big economy, a small IT consulting firm just isn't accountable. Mind you, failure often isn't strickly their fault -- if there are no IT people inside a company then there's no one who can really talk to and understand IT consultants. Frequently the two parties will think they've agreed to totally different things.
Unfortunately, the first full-time IT person to walk into a company after an outsourcing balls-up isn't much better off than the consultants, with no-one in the company able to help them define their job and understand the installed systems, so the turnover for the first few permanent staff is also a bit high, leading to problems that look very similar to those caused by outsourcing.
But I mean, what do you do when no-one in upper management understands how the company's IT infrastructure works? And how do we ever get to a point where upper managment at least has a few people who do understand IT when they're mostly so damn horrible to anyone that knows how a computer works?
Zero-inventory = getting the supplies only when you need them, saving overhead in storage and so on. Hiring contractors instead of maintaining employees is analogous. Get workers only when you need them.
However, a worker is not like a part off the shelf that can be popped into place. For projects of any complexity, there is going to be a learning period.
a) About the project
b) About each other. There are always human dynamics to consider, even among focused technical personnel.
I see this as successful only in an environment of standardized work projects--more like an assembly line than anything else. And if it's that standardized, it'll probably find its way to the second or third world pretty soon.
It is easy to imagine management trying to treat a project, any project, as if it could be handled with plug-in workers. It's equally easy to imagine this leading to tremendous delays and failures.
I've been both contractor and employee. Always preferred the freedom of contracting. But I have a high tolerance for being broke.
Then there are bugs. Building a bridge or house you better not have bugs (other than roaches and ants) that cause the house to collapse. How can the software industry make bug free software that works? THEY CANT. Linux has bugs, BSD has bugs, Windows has bugs, Sun has bugs, HP and AIX and MAC ALL have bugs. Palm has bugs as well. THER eis no way you can design a bug free OS and there certain is no way you can design software needed by a corporation to use that does not have bugs.
My company let go of 1/2 of our dev team this week. We need to rewrite or go under. I'd like to take the source, rewrite it and then sell it back to the company as an improved product that they can resell. Ah heck I'm going to get into a different software development market.
Only 'flamers' flame!
I suspect in a large part, this is a housecleaning measure. Corporate environments tend to foster byzantine empires driven more by politics than by productivity. Each department manager fighting to get his budget as high as possible, each manager having his own team of sycophants operating at 5% efficiency while using politics to put a strangehold on other teams.
The contracting houses aren't enmeshed in the corporate political structure, and offer project-based propositions rather than the typical corporate song and dance. Of course, an economic downturn is the perfect time to do this. When things are going well, "if it ain't broke, don't fix it". So, I'd consider this essentially as a corporate maintenance window. Soon, the limitations of outsourcing will rear their ugly heads eg., "oh, you want additional services beyond the contract? 5x the original cost!" which will spur the cycle onward.
Regarding technology-specific firms, I think that's another topic entirely.
In point of the construction analogy, I think the analogue would be software libraries. But the creators of those need skilled people to keep those in order (think movie & image format display stuff)
If you mean in the fabless CPU company sense where a company gives a spec to an engineering company, I think that may end up as a net gain. That way, you get software design expertise concentrated with companies who know how to do that. Think: less hopelessly clueless managers calling shots on software projects, making every mistake in the book and dooming everything to failure through gross incompetence.
Of course, the same companies which would be doing the "design" would need to know a good deal about software to begin with, which brings us full circle to how things were previously: software companies writing commodity software and vertical applications. Internal teams doing specialized work because open-ended/emerging technology is typically not handled well by contracting.
I've never personally seen an IT outsourcing scenario that ended up well for the company doing the outsourcing. Typically this is because of changing business needs conflicting with the locked in contract with the services vendor.