In Favor of Homegrown IT Solutions

snydeq writes "Today's IT organizations turn too readily to vendors, eschewing homegrown solutions to their detriment, writes Deep End's Paul Venezia. 'Back when IT was "simple," several good programmers and support staff could run the whole show. Nowadays, [companies] buy hefty support contracts and shift the burden of maintaining and troubleshooting large parts of their IT infrastructure on to the vendors who may know their own product well, but have a hard time dealing with issues that may crop up during integration with other vendors' gear. ... Relying solely on support contracts and generic solutions is a good way to self-limit the agility and performance of any business. In short, more gurus equals less hand-wringing and stress all around.'"

Comments

So contracted labor isn't all it's cracked up to b

[sethstorm]

When you treat people like second-class citizens by making them contracted labor, especially in IT, this shouldn't be a surprise.

IT shops are run by MBAs those days

[Anonymous Coward]

I was trained to be an IT manager, where most people move on to an MBA. All the classes taught were BS outsource this, best of breed that, vendor support another. The technical skills were deemphasized to the point that they are "complementary skills" rather than primary ones. You don't need to know how to manage a server, or configure Active Directory, or run an Exchange mail server. All that you know is to write business requirements for vendors to come in and set everything up.

My company decided to go with a vendor for their accounting platform, Great Plains. And now whenever we want to do any shit in that application, the vendor would take eons to come back with a workable solution and bill a fortune -- a great pain! Fortunately, the IT director, who is a highly technical guy, saw the problem and sent a few folks for Great Plains training.

Re:IT shops are run by MBAs those days

[jellomizer]

Those must be some bad MBA schools in your area. I got an MBA and I was never taught we should outsource everything.
We were taught to get venders when the requirements word distract the existing staff from their mission focus. I had to read case studies where outsourcing worked well and when it failed miserable and should have kept the inside staff. We were taught the complexities of global business and that American staff tend to be more productive and creative even though they cost more. How bean counting causes you to miss the good envestments. And a good HR policy means treating your workers right and at a good pay.
I am willing to bet there are less MBA but BBA who are out of a 4 year business with no experience, trying to save money by stepping on the backs of anyone who gets in their way. The MBA program is far more responsible.

Re:IT shops are run by MBAs those days

[AK Marc]

In my MBA program, we discussed that outsourcing almost always costs more than insourcing for the simple matter that if it costs them $10 to do it, or costs you $$10 to do it, they'll mark it up 50% and sell you the service for $15, but if you'd had the capability to do it at cost, you'd be out $10. Oh, and that the single greatest "cost" of outsourcing is almost never counted. Risk. What's the risk the outsourcing company will close down? don't know? Then you shouldn't be relying on them for a business critical function. What's the risk that your competitor could pay off your outsource company to get access to your systems? Don't know? Then why are you outsourcing?

Re:IT shops are run by MBAs those days

[ghostdoc]

I'm a long-term developer studying an MBA at the moment. I'd recommend it to everyone working in commercial IT, it really helps you to understand why some of the decisions are made so badly from a technical point of view (because they're taken from a business point of view where they make more sense). More usefully, it also gives you the tools to explain why those decisions are technically bad in language your decision-makers will understand.

You don't need to know how to manage a server, or configure Active Directory, or run an Exchange mail server. All that you know is to write business requirements for vendors to come in and set everything up.

Yes, an IT manager doesn't need to know how to set up an Exchange server, but they do need to know how to write up their business requirements. This is good surely?

Re:IT shops are run by MBAs those days

[Attila Dimedici]

Perhaps they should have taught you reading comprehension. The OP did not say that the MBA program taught outsouce everything (I'm not even sure that he was referring to an MBA program, it appears to have been an IT management training program--at what level appears ambiguous). The OP said that the IT management training program he was part of taught a whole bunch of stuff such as outsourcing, best of breed, vendor support as primary skills and that actual IT skills as not terribly important (nice to have for an IT manager, but dispensable).
I have seen this in many areas, not just IT. The idea that management does not have to have any of the skills needed to do the jobs subordinate to them is very prevalent. While a manager does not need the skills to sub in for all of their subordinates (although it does help), they should be able to do the job of a significant number of their subordinates. Otherwise, they will have trouble recognizing the relative value of different staff members contributions.

yes and no

[Trepidity]

The general in-house versus outsource vs commodity question here is a bit inextricably tied up in the more specific "enterprise software sucks" problem. I've seen moving from in-house solutions to third-party stuff work well, when it's good third-party stuff. For example, near the end of my time there, my university switched from an aging home-rolled email setup to a Zimbra installation, which, while not perfect, was generally better and more reliable. On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.

Re:yes and no

[Mad Merlin]

On the other hand, there is certainly plenty of crap that they pay Oracle and Microsoft $$$ to run that doesn't serve anyone's needs very well, or integrate with anything else.

Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!

Re:yes and no

[roc97007]

It's not necessarily the application, it's the system management. The vendor in our case manages the exact same applications that we used to manage in-house, only a *lot* slower and with hilarious communication issues.

I'm pretty sure the article is talking about infrastructure (partly because the summary *says* "shift the burden of maintaining and troubleshooting large parts of their IT infrastructure on to the vendors") which doesn't at all mean, to me, that the IT admins were writing their own database and the IT manager wanted to use Oracle instead.

Some things *are* generic, like most email requirements, and can be managed in a generic way. But even then, you have to be careful of bait-and-switch, where the vendor parades first class IT engineers in the discovery phase and then what you actually get are former Hyundai assemblers in Sriperumbudur.

Re:yes and no

[BitZtream]

Because there isn't any alternative that integrates with as many other products and provides as many features in as easy to use package as Sharepoint + Office?

If you don't understand why people use sharepoint you don't need to be discussing IT related topics as you're clueless.

Sharepoint, much like Outlook is a steaming pile of shit, but its still better than the alternatives ... which there aren't any.

Re:yes and no

[jonwil]

The problem is not SharePoint, its people who use SharePoint for things it is not designed for.

Re:yes and no

[Tablizer]

I'm not sure what Sharepoint's forte is. It's a file server with a web interface more or less with some MS-Office integration features. Some try to use it as a intranet WCM system, which it does poorly and requires lots of tweaking to work right. I don't get "it".

Re:yes and no

[jd2112]

Like Sharepoint? It baffles me as to why anybody would buy that monstrosity... it doesn't do anything!

Sharepoint does do something, It firmly locks you in to the entire suite of Microsoft products (Windows, SQL Server, Exchange, Office) while at the same time irrecoverably looses your documents.
Actually almost all 'Enterprise' software is like this. No matter how much it costs it doesn't do a damn thing out of the box. To get it to do anything you have to hire an army of programmers and consultants to customize and configure it. The real money isn't in the product itself but in professional services to make it work.

Re:yes and no

[Anonymous Coward]

Well the fileserver portion is actually pretty slick. It's a rudimentary revision control system for said files, with a proper audit trail, unlike using a volume shadow copy, and just reverting by date. Additionally with a groove workspace you can trade files, IM files, or even created workgroup shares harnessed through sharepoint to trade files to Joe in Aruba, and Frank in Seoul. All without using anything more than an https connection. The files themselves do not need to be loaded into sharepoint directly even. They can be sitting on random puters, laptops, and worktstations in or outside of the LAN.

For the early adopters outside of IT, it's turned into a quick way that the marketing geeks trade mp3s without having them on an "official" fileserver as that's verboten. As one of the resident IT geeks and ostensibly the network paratrooper, I know they do it, but I'm turning a bit of a blind eye on it. They don't ask me no questions and I definitely move that traffic into the "less than best effort" diffserv queue in all the switches and routers :D

Your right, it tends to get used for an intranet portal pretty regularly.... and mostly poorly. The forums are grotesquely slow, the group workspaces through the web based part are tedious to use (really ditch it for a Sharepoint/Groove workspace). When you use Sharepoint as a relay between your intranet and the internet to facilitate teamwork it's actually pretty cool.

Could most of the collaborative bits be done in Exchange/Outlook, sure. But you might have to get the exchange team to build you a mailbox or a public folder or a shared workspace. With sharepoint, the users can just spool up their own workspace as needed. They can control the groups and then as rapidly they created the working group, they can also dissolve the groups when the project is done. No IT overhead for operational procedural changes.

It's really about the flexibility you give the users to police themselves.

Now is the cure more complicated than the poison? Good question, hard telling yet.

Re:yes and no

[jimicus]

I think I figured it out myself, but a certain amount of this is guesswork based on observation. Take it with as much salt as you think it needs - if anyone can add to this, please do so.

Sharepoint doesn't give you a lot out of the box, as you've mentioned. What it does give you is a very capable framework with which to put together your own solution.

What I think happens is this:

Person A (who is not in IT - perhaps he's a salesman) works for company B that implements a Sharepoint-based system. Company B is quite joined up - they'll get all the major stakeholders on board when there's a big project. IT will advise on sorting out the underlying infrastructure and making sure it all works; other business units will get involved to make sure the project achieves what it's supposed to. They take their Sharepoint project seriously - they allocate a budget to it, they put together a clear set of requirements based around their business processes (which were already pretty clear) and they hire in or contract out development work. Ultimately they wind up with an extremely competent system that does all they could ever want with pretty good efficiency - and the project is delivered in record time. Yes it's based on Sharepoint but they've really harnessed it to make it work for them.

Person A doesn't know anything about how the project was implemented, however. All he knows is that his employer brought in Sharepoint and it's fantastic.

Anyhow, time marches on and Person A gets offered a new job as a sales director at company C. It's a nice little promotion, so he takes it. What's the first thing he sees? Company C doesn't have anything like the sophisticated computer system he used at company B. So he demands Sharepoint.

Note that person A has a lot of influence in his new job. He's a sales director in charge of a small team who essentially provide the money the company needs to survive. He demands Sharepoint, he gets it. The problem is, nobody at company C - not even person A - actually knows what Sharepoint is. Oh, they know it's some sort of computer-type-system-thingy, but that's as far as they go. Expecting it to be a big project, someone is tasked to look into it and figure out how much it's going to cost..... oh. That's interesting. Apparently, Sharepoint is free. And not free as in "free from some dodgy website", it's a free download from Microsoft themselves.

So instead of putting a formal project together, the IT department simply downloads Sharepoint Foundation, installs it, sends everyone a URL and thinks to themselves "That was easy".

It soon becomes apparent that Sharepoint isn't the all-singing, all-dancing system our blue-eyed boy proclaimed it to be. Sure, it's a competent enough little Intranet and it's a lot less hassle than a traditional fileserver to store your documents on, but the way it was being discussed initially, anyone would think the second coming of the Messiah was in the form of a computer program. It sure isn't that. But nobody quite knows why.

Re:yes and no

[jd2112]

I was thinking more along the lines of SAP

Re:So contracted labor isn't all it's cracked up t

[stephanruby]

Yes, it's better to make them full time exempt employees, this way you can make them work sixty hours a week without over-time.

Re:Loaded cost of a software developer

[MrEricSir]

First of all, if your software engineers are getting paid $200,000, could I forward you my resume?

Second, support contracts can easily cost far more than that.

Re:Loaded cost of a software developer

[Anonymous Coward]

Salary is probably in the neighborhood of 80-90k. There are a *LOT* of other costs. For example the computer, the desk, the chair, the lighting, AC/Heat, internet, 401k, SS, health insurance, etc...

Re:Loaded cost of a software developer

[Rob Riggs]

The loaded cost of a software developer depends a lot on location and industry.

Exactly...

[gadzook33]

I couldn't agree more with this. We run an in-house development shop that continually out-performs areas of the organization that purchase COTS stuff (and then spend millions trying to customize it). In the beginning we got a lot of crap for having a "not-invented-here" approach and coming up with custom solutions. The first time we replaced one of these multi-million dollar solutions with something much cheaper (and easier to maintain) the comments stopped. This isn't to say we don't use commercial frameworks, appliances, etc. But these are tools (sometimes power tools), not pre-fab homes.

Re:Loaded cost of a software developer

[salesgeek]

Loaded cost for an employee is typically 18% of salary + $320/month for real estate overhead. So a $90 K employee ends up costing about $120,000 with benefits.

Integrating Diverse Software

[DERoss]

A high turnover of employees creates problems with in-house development and maintenance of software. The "organizational memory" -- how did we get here, what were the problems, how were they solved -- is lost.

In the U.S. military, cognizant personnel are often rotated to new assignments every 2-3 years. This has the same negative effect on long-term maintenance and evolution of software for military uses. For this reason, military software projects are (or at least were) out-sourced.

For 24 years, I worked for the System Development Corporation (SDC), which eventually became part of Burroughs which then merged with Sperry Univac to form Unisys. We worked with the Aerospace Corporation and with Lockheed. Together, these three companies held the organizational memory needed to maintain computer systems for operating an ever-changing array of earth-orbiting space satellites. Our role at SDC-Burroughs-Unisys was to receive software packages from 10 or more independent software development companies (sometimes the same companies that built the satellites) and integrate them into a single system. We audited the developers' specifications and tests, tested the merged packages, performed configuration management, prepared user documents, conducted training for the end-users, and diagnosed suspected errors. On occasion, we even rejected software and sent it back to the developer company to rework. Contrary to current practices, the most senior professionals also provided "help desk" support. In all the time I worked on this project, not one space satellite was lost due to a software error. Considering the cost of a space satellite, the fact that our task doubled the overall cost of software development was money wisely spent.

While the project on which I worked was technically out-sourced from the U.S. Air Force, the repeated renewal of our contract and the contracts of Aerospace and Lockheed created an in-house professionally-skilled environment for acquiring and evaluating software. As a result, a very large software system with an expected life-span of 15 years evolved and was used for over 20 years.

Re:Integrating Diverse Software

[BitZtream]

A high turnover of employees creates problems with in-house development and maintenance of software. The "organizational memory" -- how did we get here, what were the problems, how were they solved -- is lost.

In the U.S. military, cognizant personnel are often rotated to new assignments every 2-3 years. This has the same negative effect on long-term maintenance and evolution of software for military uses. For this reason, military software projects are (or at least were) out-sourced.

You do realize the one of REASONS the military rotates personal every few years is to avoid EXACTLY what you're referring to, right?

Losing any one person doesn't kill a project because there are multiple others with experience on it and no one person 'owns' the project.

Re:Integrating Diverse Software

[Alan Shutko]

If the project has been around long enough, you end up with a bunch of people who only have a max of three years of experience with it, and any knowledge of the full history is second, third or fourth hand. The risk is that as you keep cycling people out, you develop an angry monkey situation.

Re:Integrating Diverse Software

[AK Marc]

When you institutionalize the transfer of knowledge, it doesn't matter that any particular person isn't there. The others are aware of the task, and the "why" is less important.

Re:Integrating Diverse Software

[Kjella]

Institutions don't know anything, people do. You don't get competence on SQL Server by buying a book and putting on the shelf. Why do people think it's different for custom built software? Sure, having documentation certainly beats not having documentation and you can train people to operate it but understanding the design, architecture and code structure behind it if you ever want to change it or adapt it isn't done in a month or even three. Knowledge transfer is a much less than perfect process when you move from concrete operations into abstract design, even if you have some nice charts and overviews.

Source Code License

[dg41]

This brings up a question. My organization replaced our old ERP and CRM-like system which was bought 20 years ago with the source code and heavily customized. The administration (through thir consultants-ugh) declined to buy the source code licenses for the new applications because "modern organizations don't buy source code licenses anymore." Now, predictably, people are upset because we cannot tailor the apps to our business rules. My question is whether the statement of the consultant is crap or not: do companies nor buy the source code license and solely rely on vendors to make changes via upgrades or custom programming?

Re:Source Code License

[BitZtream]

Well, considering the number of companies that still sell source code ... I'd say you should be able to draw your own conclusions.

You can, for instance, get the source to most of Windows, for the right price.

Re:Source Code License

[AaronLS]

It depends on if you mean a vendor's 3rd party product versus outsourced programming.

If you hired an outside consultant and paid them by the hour to produce a custom piece of software, then I'd default to having the contract written up to include the source code as a deliverable. You might encounter resistance if its a big firm and they have reusable libraries they've created and don't want to share them. In this case the compromise might be to provide the compiled DLL's for these, but you are back at square one where you depend upon them to fix issues in those DLLs, but at least this way it reduces the dependencies.

When I think "Vendor" I think of someone who has some premade product, which seems to be what the article is refering to. I.e. its like going to a vending machine and saying I want the "Blah Blah Account Management Software". These products are usually sold to many different customers and thus have had a stream of revenue over a long period of time or for a large team to enhance the software over time. Thus they are somewhat large and even if there was a source code license option available from the vendor(although there usually isn't), the code base would probably be large and probably somewhat difficult to customize by internal staff.

Also, the cost to develop these vendor products is spread across many customers, but as the article author points out, you can pay dearly in the areas of integration and customization. You may find corner cases or new requirements down the line that the software simply cannot handle, and in my experience(having continuously been in one scenario or another dealing with a vendor for the last 5+ years) there are a lot of barriers to cross in getting the customization or fixes done.

If people are upset about the inability to customize the vendor product, then you need to go back to the stakeholders and say hey, "In light of new requirements, we clearly need a solution that 1) has some features that support these customization scenarios, OR 2) has a source code license and developers who have the skills and time to deal with implementing those customization(it's hard to know what you are getting yourself into until you actually see the source code), OR 3) roll our own solution." #3 can be a good option if you are only using a small subset of the vendor's product's features, which I've found to often be the case(since usually over time it has been enhanced to meet many customer's needs, but any single customer will only need a subset of these). Thus to roll your own solution isn't going to be nearly as complex, and may be a breath of fresh air for your users who can be overwhelmed by extra unneeded features/complexities.

I've also found that vendors put a premium on integration features. The more features they provide for integration, the more their fear that you or another vendor's product will stand in place of one of their extra "modules" that they wanted you to buy from them.

Re:Source Code License

[FaxeTheCat]

Now, predictably, people are upset because we cannot tailor the apps to our business rules.

If you need the source code to tailor an ERP and /or CRM system to your business rules, you picked the wrong product.

Shortsighted

[wiedzmin]

While I would love to wave this article at my management and say "hire more gurus", I find it somewhat disconnected from reality. This concept would only work if you had a department dedicated to in-house development, with unlimited permanent headcounts all of whom would be flawless in developing, documenting and supporting their respective applications in a uniform, regulatory-compliance friendly manner and who would never, ever move on to the greener pastures. In reality, you have self-proclaimed "developers" from various departments, writing spaghetti code designed to address their specific problems, then eventually quitting and leaving IT to struggle with supporting the uncommented, undocumented application that now cannot be replaced because it contains "all customer data". And when your friendly neighborhood ISO 27001 auditor comes along, you end up hiring 3 more people to fix every missing data validation, credential management and change control problem in this irreplaceable creation, and then, maybe, it becomes that wonderful application the author is hoping to push for.

On the other hand, if you get a third party vendor to provide you with a solution - your upfront costs will seem higher, but chances are - unlike your departed headcount, that vendor exists for the sole purpose of supporting their solution. Their features, functionality, security and regulatory requirements have either already been hashed out by other customers, or will be hashed out for your if you ask for them. And unless they're a small enough vendor to go out of business without selling their assets to someone else who will take over, they will be there to support that application and provide feature updates while your in-house developers come and go...

Re:Now if only ...

[roc97007]

There are IT gurus out there with free time. Some of them are working in environments that have completely outsourced to vendors, and the gurus end up educating the vendor's minions, sometimes on the most basic operations. Personally I find it easier when I open a ticket with the vendor to copy/paste the exact commands for them to run on servers on which I no longer have root. It saves time.

...and the biggest things we've lost are agility, performance and stability. It takes easily an order of magnitude longer to get anything done, and downtime numbers ratchet upwards. But the company is grimly determined to stick it out, because the vendor has "mature processes" which we supposedly didn't have before.

Not So Fast...

[Harshmage]

While having in-house solutions is great, but what happens when people move on? I work in the EDU part of the IT industry, and we have a particular system that was designed by a former employee, picked up by a second, redesigned by the same person, who denies that anything could be wrong with it. Support calls to them go unanswered, and they're rarely in the office. And they are one of the three Directors in IT. Personally, I work on our Windows 7 deployment, and all the underlying AutoIt scripts, plus the virtualization of our applications. I have trained all of my colleagues in what they may need in the event of my demise (or less worrisome event). And I get paid about $34k a year.

Re:Not So Fast...

[AdrianKemp]

The job length of a well paid and respected employee is far longer than your typical product life cycle.

Re:Not So Fast...

[DarthBart]

Yeah, but what happens when you need support from Whizbang Application Widgets, Inc and you discover that they've closed up shop and gone under?

At least with an inhouse application, you've got the code and can see what needs to be done/fixed.

Re:Not So Fast...

[Belial6]

The same thing that happens when the employees move on from the company you contracted with. You just have a better chance of seeing it coming.

Re:No

[alexander_686]

And
      Company paid training
      Pay Roll Tax
      Vacation leave with pay
      Family leave without pay (Why do you say that's a cost? With a group of about 20 you can expect 1 or more to be off missing for a extended period of time - need to build in some type of cushion.)

A lot of time we go with outside vendors just because it's easier. We will get random regulatory requirements (in 2 years everything must be published in BRML). Do we want to retro fit our current process to that standard (and hire new staff to handle this new technology) or just go with a 3rd party vendor? In this case we went with a 3rd party vendor - because we know next year another huge, random, request will come down the pike.

Re:Loaded cost of a software developer

[Grishnakh]

Wrong. If you don't have the developer, then you don't need as much floor space for your office, you don't have to buy cubicle furniture, you don't need as large an IT staff, etc. Obviously if you get rid of one developer, you're not going to immediately save this money, but when you're looking at hiring a whole team of people versus contracting something out, you probably will (as for a whole team, you'll need to rent more floor space somewhere, unless your company happens to have a bunch of unused floor space, but most don't as that's wasteful).

Also, 401k, SS, and health insurance absolutely do immediately increase each employee's cost.

Re:Now if only ...

[Herkum01]

Hell sometimes you have to educate the vendor's minion's on what their product is supposed to do!

Re:Loaded cost of a software developer

[gutnor]

My company charges 2000$ per developer per day for enhancements, analysis, ... (bug fixes are free though, some client pay more, some *much* less). So you can pay up to 500.000$ per year per dev.

Our client have so little staff that they hire us (at that rate) to analyse their requirements on their systems. Recently they hired 5 people for half a day for basic data entry (skill level = updating status in facebook) They are literally bleeding money anytime their business is not working entirely automatically. Some client have literally outsourced their whole business knowledge to us - they don't have a single person anymore that has experience with what the system is supposed to do and how it interacts with other system in their organisation. The best/worst part ? They pay that rate even if the developer actually doing the work is a cheapo one from our indian office.

But ... we sell that rate because we do our job and that means that generally after a while the system settles. Some of our client have basically no interaction with us for years. So the problem is not as easy as it seems: sure they overpay massively for a short period of time (a few years), but hiring would commit them with long term employees.

Re:Now if only ...

[fsckmnky]

I didn't intend it as anything more than a maybe funny, snide remark. The article was about contracting versus in house gurus, and every month it seems there is always an article about the lack of gurus, hence the comment. The "we contract everything at our detriment" crowd, who complains about the lack of gurus, would contract to get an in-house guru, get it ?

Of course, I'm a guru, but I don't want to work for the "we contract everything" crowd, so maybe thats the problem. ;)

Re:Now if only ...

[hazem]

> and the biggest things we've lost are agility, performance and stability.

What's left that's of any value? Are they saving lots of money?

Find a decent employer, for what rarity they are.

[sethstorm]

Some of us have worked for employers that made the extra hours worth it; that doesn't mean you'll have to exclude large businesses either as well.

How about fixing the overtime law to remove the IT exemption, along with something that makes requirements more reasonable(e.g. if you can't find someone, you're going to be on the hook for directly hiring someone - not as any form of a contractor - and training them as an FTE at full wage)?

Best of Both

[maeglin]

The company I work for has the best of both worlds. They go out and buy a $500,000 piece of Enterprise Software*, forgo the expensive contractors and dump the setup and configuration on 2 or 3 in-house developers, a project manager (who is usually an outside contractor who happens to be friends with an executive -- a budget locust, if you will) and an IT manager. After about a year the esteemed project manager moves on to the next project, the manager in charge gets promoted, the software is blamed for the lack of results and a new $500,000 purchase is made.

*For those that haven't used the stuff, Enterprise Software doesn't actually work out of the box. It's much like a do-it-yourself plane kit with lots of manuals on FAA regulations, a glossy guide full of pictures of planes "other customers" have built and a box full of parts (with a few random parts missing) but no actual assembly instructions.

It depends who is more competant

[Anonymous Coward]

It is better to outsource if you are outsourcing to people who are more competent than your in house staff. Unfortunately the people who make these decisions often are not sufficiently competent in IT to make an informed decision. My boss certainly never believes me when I tell him I'm more competent than those bozos.

Yeah totally stupid.

[unity100]

Imagine - you are trusting a PRIVATE party with your sensitive stuff. they can do something stupid and go bankrupt, get sold, this that. you have no power over hirings there, so you wont know whether they are hiring reliable individuals or people who could leak your stuff at any given point. what are their goals their policy changes this that.

basically you are giving your balls to them. and they grip tightly.

i.t. became too complicated now indeed. but, is that much complication really necessary ? KISS rule (keep it simple, stupid) is applied in software development, but, ironically it is not applied in setting up i.t. infrastructure of an organization - nowadays people try to incorporate every 'next big thing' into the setup. and you get a mess.

KISS outside, KISS inside the infrastructure. And then keep your own infrastructure. That's the key.

Re:Loaded cost of a software developer

[garyebickford]

When I worked at an F500 high-tech company, they accounted the total cost of each software and hardware engineer as 2.5 times salary. This included the buildings, computers, training, and all the other stuff necessary to keep the engineer productive. For big companies that's probably still pretty reasonable.

Oh Dear God No (well, maybe Yes, sometimes)

[enjar]

I work at a company that has a very high "we build it ourselves" ethic. This can be a great thing if you are actually spending time and energy on building the product you are shipping, as that does crazy things like create value for the company and generate revenues because you deliver the features people actually want. Revenues end up making profits. This pays my salary and ends up putting food on the table, paying the mortgage and keeps the house warm. YAY.

What doesn't do a darn thing for productivity and the generation of those features are competing version control systems, programming environments, poorly written/maintained tools, web pages that are barely comprehensible and business processes that make you want to jump out of the nearest window. For every new technology we have adopted over time, in many cases there was some piece of junk that someone had developed in a blitz over a weekend as a "temporary thing". They moved on to some thing else, and the temporary became five years when much better stuff came and went -- and we still did it The Way We Know.

I'm not saying that any internal wizardry should be avoided -- but really when you develop internal solutions you should know what you are getting into, and know how long you are going to put up with it, especially when the remainder of the world moves on -- and leaves you behind the times. Also be VERY wary of what's termed "the lottery problem" or the "hit by a bus" problem -- as in, when the guru who put together your super awesome sales lead processing database / application stack that's central to your company making money doesn't show up at work anymore, what are you going to do? When the desktop machine that's responsible for keeping track of your development metrics is re-imaged by mistake, what do you do then? When the world's best custom-designed project tracker heads for the bit bucket with all the plans in it, what next? Hopefully these kinds of things can be identified and the little projects that grow into business critical services will be properly supported, but I've seen it go the wrong way quite a few times.

Re:Oh Dear God No (well, maybe Yes, sometimes)

[Rumtis]

A good (maybe not great, though) analogy I heard of in regards to in house IT: Designer clothing

An internal team will cost extra, but can create a solution that fits the company perfectly and it looks/works *really* good. The thing is (a) they are the only ones who can build it just to the company's needs and (b) hopefully the size of the company doesn't change dramatically. Otherwise it won't fit right.

On the other hand, a one size fits all may work for the company, but nobody looks good in a muumuu.

Re:Oh Dear God No (well, maybe Yes, sometimes)

[jyx]

I'm not saying that any internal wizardry should be avoided -- but really when you develop internal solutions you should know what you are getting into, and know how long you are going to put up with it, especially when the remainder of the world moves on -- and leaves you behind the times. Also be VERY wary of what's termed "the lottery problem" or the "hit by a bus" problem -- as in, when the guru who put together your super awesome sales lead processing database / application stack that's central to your company making money doesn't show up at work anymore, what are you going to do? When the desktop machine that's responsible for keeping track of your development metrics is re-imaged by mistake, what do you do then? When the world's best custom-designed project tracker heads for the bit bucket with all the plans in it, what next? Hopefully these kinds of things can be identified and the little projects that grow into business critical services will be properly supported, but I've seen it go the wrong way quite a few times.

How does outsourcing solve this? What if the outsourcing companies only developer gets hit by that bus, or even the whole company burns down? What happens when they decide that the custom thingy built for you is no longer worth supporting and there's no end of life code hand over (but there is a new wiz bang product that they sell!)

The big dollars required for outsourcing contracts that properly* cover all the problems you mention will most likely solve them for you anyway.

*As in actually account for them as apposed to 'well, they said they did, amazing considering the price'

There seem to be economies of scale here

[fiordhraoi]

While I can see a larger business being able to support the personnel to have such an experienced/skilled in-house development team, the fact is that for most small and mid sized businesses such a setup just isn't worthwhile.

One of my previous jobs was the systems/network administrator for a 65 person company. The yearly IT budget for software licensing, hardware, etc was about $150k. The software we bought met the needs of the company admirably, with only a little bit of customization required. Myself and one of the other IT staff were reasonably skilled as DBAs and could customize reports from our databases (a mix of Oracle, MSSQL, and MySQL), and the other guy was decent at wrapping the GUI around those queries. There's just no way that the $150,000 of our yearly budget could be stretched into hiring programmers to make custom software for us. Nor was there a need to do so - our needs were small enough - and to be frank, generic enough - that existing enterprise software just plain did what we needed with a minimum of hassle. The benefit as compared to the cost of creating a development team just didn't make sense looking at the ROI. In fact, there was no ROI at all.

That said, I can see companies with unique needs and larger companies with more complex business processes needing a better solution. For them, it may well become worthwhile to consider custom solutions for more of their tricky items.

Re:Now if only ...

[skids]

Doing that now with a product being developed by a major company which shall remain nameless. I'm having doubts the corporate culture is actually capable of engineering such a complex product. We'll see.

The biggest drag about contracted services is that, even if you are lucky and they actually save time rather than waste it, they have external costs in that some of your projects get hamstrung waiting for vendor fixes. The flip side of that is at least you don't ever drown in a sea of options.

Yes, but be selective.

[C_Kode]

This is true, but you have to be selective. Sometimes pre-built solutions makes since.

I've seem way to many people try to build solutions when an off the shelf solution would have been easier and cheaper in the long run. (say after a failure, and sometimes before!)

If you need a mail server with lots of accounts, but no bells and whistles. Build it yourself. You need an mail server with all the bells and whistles. (calendaring, etc) Buy one off the shelf. You will save yourself a lot of head aches. (providing you're not stupid in implementing your off the shelf product)

I have a couple of name brand HA NAS devices. I also have a couple of Linux NFS servers running DRBD and heartbeat. I knew where to buy off the shelf and where I could do it myself.

The blame game

[Glendale2x]

A lot of the time it's because when shit hits the fan then management can shift blame to the vendor and/or support contract.

Compromise - A Kit

[Tablizer]

I'd like to see software "kits" for families of application domains. One purchases the software kit's source code and then customizes it, perhaps with an optional subscription to get future doo-dads.

Doing everything from scratch takes too long and buying pre-built solutions shoehorn you into something both missing features you need and that carries the baggage of features you don't.

Write them in common languages such as Dot.Net, Php, Java, etc.

However, enforcing licenses may be tricky.

Enterprise Software

[PPH]

Its where your business processes are implemented these days. If your company has no competitive advantage over others based upon these processes, then by all means, buy the same s/w package that the guy down the street uses. Or hire the same consultants. More often than not, rather than customizing an application to suit your business, they whip out some boilerplate procedures manuals and get some of their inside people to slip them into your business plans. It makes their subsequent sales job much easier.

There are legitimate issues of core competence vs activities outside your companies value chain. Once you can identify what it is you do that gains you an advantage in your market and apply your IT (and other) resources to that, the rest can be bought off the shelf.

Re:Undisciplined nerds and ivory towers...

[Todd Knarr]

My response is:

• A: How many projects actually budget time and resources to developing documentation? Most of the time management insists on trimming that time off the project because it doesn't deliver any business features and will take longer than the actual development will (documentation is a time-consuming project in itself).
• B: How often does management not want to allocate additional staff to essentially do nothing but learn someone else's job? The usual line I hear from management is that there's no return there, the additional person won't be doing anything that isn't already being done and they could be more useful doing something that isn't already being handled. And see A about documentation.
• C: A good point, developers often aren't good at hand-off. But they aren't entirely to blame, see B and A for management's unwillingness to invest time and resources in the things you need to do a successful handoff. I also see a certain unwillingness to hold a BAU team responsible when the developers are right there and can just help with any problems that come up.

As with many things in IT, it comes down to the fact that the developers are not the ones with the authority to do these things. The authority and the responsibility rests with the managers and executives who make the decisions and set policy. As an "IT nerd" (read "techie, guy who's paid to make the little boxes with the blinkenlights do their thing") I'm often caught between the desire for good project discipline and the reality that management doesn't want good project discipline because it interferes with delivering the most features in the least amount of time (notice that I said "features", not "bug-free working software"). And I can't tell the CIO "No, you're not shaving 4 weeks off the project schedule. No, you're not assigning Joe to another project. No, you're not adding those 5 new requirements to the list without adding additional time to the schedule.". I'd love to, but I'm not his boss so I'm not the one giving him orders. And if he ignores what all the people under him are telling him, there's only one person responsible for the resulting trains-wreck. But his bosses won't hold him accountable for it, so it's no skin off his nose.

Okay, I call bullshit.

[Chas]

I understand that some environments can be more flexible or more dialed-in to company/user needs with a full time, active development staff doing everything homegrown.

But the talent pool for this sort of thing is woefully limited. I've seen "in-house" development groups come up with some of the nastiest, most byzantine pieces of crap-hackery you could possibly imagine. And there's ZERO planning for what to do when the system reaches obsolescence. And don't give me any crap about how it won't ever happen. It WILL. Then, what's the upgrade path? How do you get the data out? And a million other niggling little things.

There's also the problem of relying on a group of individuals like this. It's essentially a thinly disguised form of vendor lock-in. Save the vendor is a group of your own employees. And what happens if they all up and move on to greener pastures? How do you maintain the system? CAN it be maintained? Can it be extended? Can ANYTHING be done with the system without bringing it crashing down?

How do you know Joe WannaSecureMyJob didn't back-door the system?

Yes, a lot of these are concerns you face with vendors too. But with vendor approaches, if you dislike the direction the project is heading, you can kill it, cut out the vendor, and move on to something you find more acceptable.

Not saying it CAN'T work. Just that the level of care you have to take when risk managing is different from what you need with outside vendors.

Re:Okay, I call bullshit.

[jyx]

I'm a contractor that has spent most of my career 'on site' at various large institutions. Never less than 2 years at any one spot - the contract has always been extended even after the original work has been done.

I've seen "in-house" development groups come up with some of the nastiest, most byzantine pieces of crap-hackery you could possibly imagine

Very true, It you hire crap staff you will get crap results. Most of the places Ive worked had environments like this. In fact, its usually why I get called in ("ARGHH!! ITS ALL SHIIIIIIT FIX IT!!!!!!!")

But with vendor approaches, if you dislike the direction the project is heading, you can kill it, cut out the vendor, and move on to something you find more acceptable.

Hang on. Your saying that an IT department that is not capable of hiring even basically competent staff is some how magically able to contract and evaluate a 3rd party to meet their businesses needs?

That's rubbish.

The same lack of management competency that led to hiring crap staff will result in a crap outsourcing project.

If you have a good management layer, you will succeed regardless of outsourcing or in sourcing. If you have a continual need for X number of developers, why pay the over head of a contracting firm? Sure bring in people when you need to, but they should support your in house team not replace them.

I say if your big enough for an IT Department, your big enough for at least one full time developer. If you want to outsource, then walk the walk and outsource THE LOT (Includes all CIO and IT related management positions)

Re:Loaded cost of a software developer

[hawguy]

In my experience, the biggest difference in outsourcing operation of key software is that it forces internal customers to rethink their expectations. If software is maintained in-house, they expect it to fulfill their every whim. When the IT dept says "It will take 3 of our developers 6 months to do what you want", then say "Ok, we need it! Do it now!". But when they are dealing with a software vendor, and they say "It will cost you $175K to do what you want", they say "Hmm...well, that's kind of expensive, I'm not sure we need it".

When you have your own developers, they can tailor the technology to meet the needs of your business. When you purchase pre-packaged software, the business tailors its needs around the software.

Re:Now if only ...

[Anthony Mouse]

The article was about contracting versus in house gurus, and every month it seems there is always an article about the lack of gurus, hence the comment.

I suspect the problem is corporate executives who know the cost of everything and the value of nothing. There is a simple way to increase the supply of something: Pay more. If companies would pay competent IT people more money, then more people who would otherwise go on to be tax lawyers or securities traders will go into IT instead.

By contrast, what you hear in the media is the executives thinking with their MBA brains: If you want to increase supply, you can pay more... or you can go to the government and create artificial incentives to increase supply. More H1B visas. Government education subsidies for tech majors, to divert labor supply from occupations that pay the same or less than IT into IT. More supply at the same price.

The problem is that the latter doesn't create "gurus" -- it creates paper MCSEs. It makes the problem companies have in hiring competent staff that much harder, because you create a population of applicants who have degrees and certifications and even experience, yet have no earthly idea what they're doing. It attracts exactly those people who are too stupid to understand that a $1000 scholarship is a completely asinine way to make a career choice, instead of those who are smart enough to do just about anything and who make decisions based on forward thinking criteria like which career will allow them to afford a house in a neighborhood with better schools and a comfortable retirement.

It's the same disease that allows them to make the IT department a cost center: They count all of the salaries and equipment and ignore the productivity improvements that accrue to other departments as a result of their existence. Which makes it look like cutting staff or replacing them with less qualified but lower paid employees will save them money: The cost savings goes straight onto the spreadsheet, without accounting for the lost profits that will occur when a major system falls over and there is no longer anyone competent working there who can get it running before you lose a big client.

Re:Now if only ...

[fsckmnky]

I'd +1 you ... if I had any mod points. One of the more lucid assessments I've had the pleasure to read.

Diversity and Value

[iPaul]

The first, diversity, was mentioned in the article. In the last 20 years (1990 to 2010) we've had countless "core enterprise technologies of the future" spring forth. Some of these concepts or technologies are still in wide spread use, but others have fallen out of favor or have been overcome by events. Many shops have hodge-podge systems with tough to find skill sets. It's hard to staff these positions and the average tenure of an IT person is about 2 years. With a contractor, it's now the HR problem, not your problem, to find someone who knows Delphi, COM, and DB2 to patch your in house app.

By contrast, the CICS was developed in 1969, System 360 1964, and COBOL 1959?. Anyway, you can take a 30 year period from the mid sixties to the mid 1990's and find almost the exact same mix of products. The versions and features evolved, and some additional COTS products were introduced, but there is an amazing consistency. Even the terminal technology for the mainframe was fairly slow to change, with serial terminals in wide spread use until fairly recently. I think the lack of diversity makes it more economical for companies to train and manage an in-house staff. When it's time to find new staff, you used to be able to find an ample supply of people who had COBOL/CICS on their resume.

But I think this problem could be overcome if senior management saw their IT as delivering a competitive advantage relative to their competitors. Even in the mainframe days there was a lot of outsourcing. If we're all using the same COTS packages and building the same applications on the same platforms, it's more about not screwing up than it is about doing something excellent. Companies are more likely to keep their "secret sauce" in house but take the stuff everyone has to do and outsource it to try to reduce cost. That's not to say that companies don't use consultants to help with projects.

You sometimes see this as "know your knitting," meaning understand what makes your company great, it's core competencies and what makes it special. Don't get distracted by the other stuff and just focus on that. If IT isn't something that makes your company special - why would you spend one nickel more than you had to?

What business are you in??

[billybob_jcv]

You need to decide what business you want your company to be in - if you want to be a SW development company, fine - be a SW house. However, if you want to be anything else, then don't write your own SW. Keep your business focused on what you really do. You don't want to spend resources tracking, designing and coding the annual changes to the tax code, or all the deprecated functions in your chosen framework or the latest trends in user interface design. There is no way you can do all the industry research, application design and code maintenance for the price of the annual SW maintenance, let alone match the amount of resources a large commercial SW vendor can devote to the same problem. His R&D costs are spread across all of his customers - are yours?

Oh - and lets not forget a little thing called Sarbanes-Oxley. Do you really want to prove to your auditors that you have built the same level of controls into your homegrown ERP system that are put into tier 1 or 2 commercial systems?

In the vast majority of companies, the "unique business processes" are a very small percentage of the application - and many of those are simply stubborn and egotistical business users who refuse to believe that the vanilla solution would also work just fine for them if they were just willing to try to understand it.

         

Re:What business are you in??

[jnelson4765]

I work as a programmer in the retail industry, and in previous employment have dealt with ERP integration and extending legacy systems. I can tell you with absolute confidence that certain industries do need completely custom software to work properly - grocery stores, bookstores, and clothing stores all have different needs, different workflows, and different requirements. A cash register is a cash register, yes, but everything from dealing with expiration tracking and sales by weight to street dates to clothing sizes to custom orders to EDI interfaces are handled by custom software.

We primarily work with the music industry, and I have to deal with EDI from 4 different POS / Inventory / bordering on full ERP application vendors (some of which have been heavily customized for specific clients) and 2 different distributors, and will be spinning up 3 more distributors in the next year. Our e-commerce system is off-the-shelf for our industry (we can spin up a new customer who has no need for custom EDI integration in less than a day), and we have rescued a number of smaller operations who tried to develop their own system, or adapt various open-source shopping cart applications.

Our software would be of no use whatsoever to the manufacturers and medical, real estate, and legal offices I have dealt with in previous jobs. A completely different regulatory environment, different expectations, and different reporting requirements make any one-size-fits-all useless. That's a perilously bad attitude to take - some things, like payroll and HR, are relatively common across industries, but not understanding how business workflows differ from company to company shows a lack of professionalism. You think UPS uses an off-the-shelf software package? Or Greyhound? I can speak to both of them - they both developed in-house, because there was no software that covered their needs.

My business programming teacher back in high school put it this way: You will be working with obsolete technology, writing boring code to make distinctions between states that you really don't care about or even understand all that well, and will be ignored unless you make a mistake. Your job is to disappear into the background and make the business run smoothly. If your ego can't deal with that, leave this class now, because you will not make it in programming.

IT needs apprenticeship not degrees. Tech school +

[Joe_Dragon]

apprenticeship system. Take today's tech schools and add apprenticeships to them.

CS degrees build theory and a lot of that is high level stuff with out the skills of working on systems / working with stuff at the hands on levels.

Now with a apprenticeship people can build real world skills and companies get people who are not people who can cram for a test and be come a paper MCSE

Re:IT needs apprenticeship not degrees. Tech schoo

[colinrichardday]

And what does CS have to do with IT?

Re:IT needs apprenticeship not degrees. Tech schoo

[ghostdoc]

And what does CS have to do with IT?

Exactly. This. This is part of the problem.
There's a disjunct between how academia sees Computer Science as nothing to do with IT and how business sees a CS degree as the basic starting point for a career in IT.

Can we please either have a Computers in Business degree that teaches useful skills, or a business culture that doesn't expect academic degrees to be vocational qualifications? I don't mind which, either is good.

Also, the reason your company doesn't have any gurus is that no-one is prepared to spend any time or money training their staff, or even giving them self-development time to train themselves. Companies that do decent training have gurus. It's pretty simple.

Problems with upgrades and intergration

[stewartm0205]

When you have different packages from different vendors it is very difficult to manage the upgrade cycle since each vendor has different release dates. It is also very difficult to integrate packages from different vendors. And extremely difficult to keep the integration working as you update the different products. You may save a lot of time using a vendor package instead of a custom build but once you have more than a couple of packages in from different vendors you start to have a lot of problems managing changes to them. .

academia is poor for skilled laber as well

[Joe_Dragon]

In terms of teaching useful skills. Tech schools are better but HR / business culture does not see them as good qualifications.

IT is at the point of plumbers, HVAC, car repair and so on. In where only so much can be learned in class room and only so much theory can get the skills needed to the most common work and 4 years is to long for a starting point even 2 years pure class room is pushing it.
Now say 1 year for basic IT and then maybe some kind of a apprenticeship with on going class and then maybe after that have higher level stuff NOT CS stuff but things like advanced networking, advanced security and so on. CS is way to much on the theory side and the tech schools are lacking the real work place experience.

Right now some can say do a 4 year advanced security and miss out on the part doing the basic work and end up pushing advanced security stuff with out haveing worked with doing stuff at basic level where you find out how at times that advanced security does not work as planed or that you can get by with lot's time wasting work around / paper work coming from a poor security plan.

Re:academia is poor for skilled laber as well

[kilfarsnar]

IT is at the point of plumbers, HVAC, car repair and so on. In where only so much can be learned in class room and only so much theory can get the skills needed to the most common work and 4 years is to long for a starting point even 2 years pure class room is pushing it.

As an in-the-trenches Systems Admin, I agree with this. I have often thought recently that I am like an electrician, or HVAC repairman.

Re:IT needs apprenticeship not degrees. Tech schoo

[DigiShaman]

I keep seeing this posted often on Slashdot. Of all the industries, IT is the absolute worst example you could name being a candidate of some sort of apprenticeship program. That's because Information Technology is fast moving target that defines progress and changes in paradigms. It's also why even IT college degrees are almost worthless too. I'll leave CS out of this because they actually rely on math and other proven techniques that have wide reaching applicability. But certifications such as an MCSE and CCNA only prove familiarity. They do not however prove experience. In fact, I would state that these certifications are best suited to compliment your resume of existing experience.

Re:Now if only ...

[turbidostato]

"Hell sometimes you have to educate the vendor's minion's on what their product is supposed to do!"

Been there, done that, got the t-shirt -literally!

Re:So contracted labor isn't all it's cracked up t

[blackicye]

Large institutions (especially financial ones) do this because of the enhanced plausible deniability.
It's to much easier to blame IBM for your outage / downtime / boo boos, instead of admitting you have poor internal IT practices and infrastructure.

Re:maybe it's time for IT unions

[malkavian]

Although a union to say "You don't have to be forced to give up having a life, just so someone can get their spreadsheets at all times of day" would be nice.
Everyone wants a 24x7 IT system. There's a way to do that; lots of money on the hardware, and three complete teams of core staff who work shifts (with the commensurate shift salary augmentation).
But no, what business wants is a group of IT staff who work the same hours as everyone else, for the same kind of salary as the average pen pusher, who will then, at no notice, respond to a phone call at any time of day or night and get to site (or at least connect up remotely) and spend hours diagnosing network/server/PC/application problems (possibly calling up other IT staff), and then being in for work the next day as if nothing happened.

Re:So contracted labor isn't all it's cracked up t

[roman_mir]

Why do people think that contractor = second rate citizen? I don't know any contractors (including myself,) that want to go full time. I don't understand the mentality that choosing to be paid a rate per hour and have no other connection to the employer is somehow a bad thing.

Re:Now if only ...

[Prof.Phreak]

...and the biggest things we've lost are agility, performance and stability.

This... I find it amazing how many corporations don't see this! No wonder small startups with half a dozen developers can run circles around big corps with "hundreds" of IT staff.

Re:IT needs apprenticeship not degrees. Tech schoo

[somersault]

IT isn't all about shifting paradigms, a lot of the thinking you need to do IT support and build/manage infrastructure simply required the right mindset of considering various possible problems or solutions. I've always been "good with computers" simply because I'm curious, I try things out, and the things I learn from that tend to help me with future things.

I stopped finding IT support interesting within a couple of years though, and have managed to shift my job role in the company to being a lot more programming oriented the last few years. So I guess I'm one of the "gurus" that the article talks about. Unfortunately the department that makes the most use of my software projects has just been sold to another company, and they haven't decided if they want to keep using that software or switch to some general solution yet. I don't really mind either way, management seem to like the idea of me continuing in some kind of programming role for them otherwise they'd have made me part of the deal..

Re:IT needs apprenticeship not degrees. Tech schoo

[DarkOx]

IT is pretty big umbrella and given computers are symbolic manipulators and we understand information to be relationships among facts, expressed as symbols you cannot say CS has nothing to do with IT unless you have a deep lack of understanding where the fundamentals are concerned.

Undergrad CS is a perfectly good academic background for someone who is going to be developing business software. Remember an undergraduate program is supposed to provide a foundation for an individual to build on. Expecting to plop a new college grad in front of Visual Studio and tell them to get to work maintaining your enterprise application is wrong. They will need training and some hand holding by the existing staff until they learn the business and other specifics of how things are done in the organization. Knowing something about how computers are designed, operate, the mathematics behind them and some common algorithms is a fine place to start from, not the only place but a fine one.

Where operations are concerned well there is a MIS degree for that!

Re:Now if only ...

[Vrtigo1]

Unfortunately, this is all too true. Just recently, I had to contact support for one of the largest IT companies in the world. They will remain nameless, but the company has a 4 letter name and they were at one time the largest PC manufacturer. I asked to speak to someone in the support dept for the product I was using, and the people on the other end of the phone had no idea that product even existed.

Re:Loaded cost of a software developer

[garyebickford]

How does someone who makes 100k cost 250k? Really, how?

Building cost- Same (maybe slightly higher if the perosn has a bigger cube)
Insurance costs - Same (maybe slightly higher if you assume someone more experience may be old and have a family)
Bonus cost- 2x (assume same bonus%)
Other $$ costs (401k matching, etc)- 2x
yearly raise cost 2x (this compounds, but the 2-3% typical increase is just not worth it.)
training costs- probably higher, but with higher return as well.
Adminitrative costs (people to handle HR, payroll, etc)- Same, maybe slightly higher if the person has a complex bonus or pay structure

My company assume 2x cost, and even that is absurd when you look at the reality of the situation

I'm not sure what you mean by 'same' - I was referring to what's called the 'fully loaded cost' of personnel. In a large company you can't count the building as a fixed cost - in my particular example I worked in a brand new three-building office park filled with 1600 or so engineers and support staff. This was back when an SW II made about $15000, so the costs mentioned below are in reference to that salary. The buildings (in a dedicated 150 acre office park) cost $multimillions - I don't recall but it was probably in the $100/sq. ft. range back then, so given 250 sq. ft. per engineer including hallways, bathrooms, cafeteria, and all the other stuff that's $2500 per cube, amortized over five or six years. The cost of the cube itself is more than you might think. There were three mainframe computers (a couple $mil each, which came with three full time vendor support people and inhouse support of 20 or so. Every desktop CAD workstation cost several $thousand. Right off the top, FICA employer contribution cost 7.5% above the salary. Support staff (secretaries, draftsmen, parts supply, facilities, networking, cafeteria) was about one for every three or four engineers - one for six minimum (the place had a grounds crew of a dozen). Insurance is a much larger component than you might think, especially health plan. Today in the small company I'm at, the cost of health insurance for a family, paid mostly by the company is more than half as much as the bottom-level employees' gross pay (we're in Massachusetts, land of Romneycare). Then you add in the cost of management and operations (HR, etc.) that are assignable to engineering. So it adds up. Some of those costs might be less these days, particularly the cost of computing; but others might be more (relative to salary).

Re:Now if only ...

[roc97007]

I think part of the reason for that is that the vendors in turn have outsourced routine support to offshore organizations, and one offshore organization can handle support for several vendors. Then, all you need is a call mis-routed, and suddenly you're talking to people who are not familiar with the product you're calling about, and might even be in an entirely different business.

The truth is...

[yoey]

there are lousy homegrown solutions and great vendor applications (and vice versa). It depends on the caliber of the development team.