Slashdot Mirror
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.'"
When you treat people like second-class citizens by making them contracted labor, especially in IT, this shouldn't be a surprise.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
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.
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
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.
There's no -1 for "I don't get it."
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...
The loaded cost of a software developer depends a lot on location and industry.
the growth in cynicism and rebellion has not been without cause
Most of those "costs" are general overhead that you'd have to pay with or without the developer.
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.
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.
-- $G
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.
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?
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...
Bow before me, for I am root.
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
You first need to recruit them and that is where the at-least-15-years-experience-with-windows7 headhunters try to score their introduction bonus, providing you with the wrong people loaded with certificates which only prove that they are very good in following the Cisco/Microsoft/Orcale guidelines.
All-round programmers with a solid experience that run entire enterprises with just a small group are a endangered species.
Take good care of them.
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.
Does that include the ivory tower?
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.
Like most things, there needs to be some balance between those things that you get from a vendor, and those things you do in house. Too much of either end of the spectrum is generally a problem. Too much from the vendors and you end up with the scenarios that the author describes. Too much of the in-house work, and you end up with a NMH (not made here) mentality which is ultimately destructive to the company. You end up wasting too much time re-inventing the wheel when an off-the-shelf solution would be adequate for your needs.
In the end, weigh the factors involved (timeframe, cost, how close existing solutions are to what you need ) and just make sure you pick the right tool for the job. Too much time with the hammer, and everything starts looking like a nail.
Hell sometimes you have to educate the vendor's minion's on what their product is supposed to do!
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.
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.
I work at a small law firm, and all of our infrastructure is in house. Since I wear a few hats, and with the IT part of my job now the least demanding part, I've been contemplating moving some of our services out. It does get disruptive when there are fires to be out out right when there are deadlines due.
One thing I've been investigating is abandoning exchange for google apps. It would defiantly help up the security, as we'd only need a single open rdp port. And maintenance, service packs, anti-spam subscriptions would mostly become a thing of the past. Uncomfortable with google though, as we do have a lot of confidential information in our mail flow, and their propensity for analyzing very it of data they an get their hands on seems counter to the need for privacyin our communications.
Or course I haven't read their usage agreement so maybe by virtue of paying them for services, they might eschew the need to learn everything they can about us and our clients.
Point being, there seems to be a trade off that makes outsourcing the deal worth looking into, especially for small firms where budgets and manpower face more constraints than with fortune500 companies.
Any thoughts for or against?
> 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?
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)?
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
My experience has been the vendor theoretically knows their product, in that they know where to configure something.... but they know shit about how their product operates in the IT infrastructure of your company. most of the vendor products I have installed needed quite a bit of extra code to be written just to fit into the environment and be able to be properly monitored so the support staff on our end could go home for a weekend and not have to worry about files that did not process for 4 days with the first alert being the people we send these processed files to bitching.
Another product (an e-forms product) was so difficult to publish new forms in, that when I handed it off I wrote a utility that allowed the new support staff to publish, move, rename, and remove forms from any location in the forms tree.
Vendors pretend that their products are the only ones in your IT department. you still need good staff to integrate them.
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.
When people reference nothing but hardware you know they have no fucking clue about enterprise or the industry in general.
I can count on one hand the number of man-hours spent on switches in a year. There are days when I can't count on both hands and feet the number of man-hours wasted on a buggy vendor-provided API.
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.
Most mature organizations have reached the point of understanding that custom solutions cost too much to maintain and support unless they are core to the business. Organizations make do to with off-shelf-solutions and support. As for integration, more and more organizations are also buying software suites instead of standalone products or relying on contractors for integration.
In fact, custom solutions actually makes organizations less nimble by tying them to their customized in-house infrastructure. By buying off-the-shelf solutions, it is easy to change products and migrate data, as competitors provide tools to make transition from competitor products easy. Migrating data from a customized solution, especially a large one, takes takes at least twice as much time and resources. In addition, if the homegrown solution relies on a few gurus to support it, what happens when they leave? At least off-the-shelf solutions have a support organization that understands the product throughout it's lifecycle.
I do agree with Paul Venezia that it is difficult to measure the trade-offs. But most organizations that have lived through the customization era of the 80's and 90's went to off-the-shelf solutions during the Year 2000 upgrade cycle and haven't looked back since. It was during Y2K that they realized just how much all of that customization was going to cost them. The trade-offs, at least at that point, favored off-the-shelf solutions. My thought is that they still do.....
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.
Read radical news here
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.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
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.
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.
Wow, that's more than I would have thought; I would have guessed 2x at the max.
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.
Someone had to do it.
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.
Several decades of bleeding projects, IP locked in the brains of self professed 'gurus' is what brought this about.
How many large projects have you been involved with that a) developed reasonable quality support documentation b) didn't vest all of the knowledge in the project team and c) Had a thorough handing over to a BAU team, with adequate funding and resources to run it.
Crickets?
Yeah, thats why you outsource. All you need to worry about is the bill, and you've got a handy outside organisation to scapegoat when things go wrong. Substantially lower career risk.
IT nerds with poor project discipline brought this change about.
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.
this is my sig
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.
Table-ized A.I.
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.
Have gnu, will travel.
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.
Chas - The one, the only.
THANK GOD!!!
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.
as long as in-house IT staff are considered mere overhead and not an area of strategic advantage, business will continue to outsource critical functions to the lowest bidder and wonder why they have to keep hiring expensive consultants every time a new project or requirement rears it's head. Then, as soon as the project is complete, they let go of all the expensive consultants only to hire a new batch (who of course need a project plan, specs, integration studies with the existing solutions etc) when the next wave of upgrades or projects starts. Tide come in, tide go out lol...
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.
I'd +1 you ... if I had any mod points. One of the more lucid assessments I've had the pleasure to read.
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?
Leave the gun, take the cannoli -- Clemenza, The Godfather
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.
Ask Texas, Indiana, Virgiania states how well spending unbelievable sums of money - we're talking between 1 to 3 BILLION dollars in each case- on consultants from a Big Name Corp worked out for them.
http://www.inthepublicinterest.org/article/pitfalls-outsourcing-it
Worked out OK for the Big Name Billers I'd say.
Does that include the ivory tower?
I doubt it. $320 a month wouldn't get you a box outside the back of a reputable building here. Sheesh, it wouldn't even get you a Bring Your Own Box lot!
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
maybe it's time for IT unions
So they can at lest not take the blame for a vender mess up and also put presser to do more in house as well.
I imagine these things are VERY specific. Are we talking one person that ONLY supports that one thing? Is it mediocre/shitty service at 200k, costing your business more than the original 200k when considering lost productivity from broken services, bad integration and workflow incompatibility across the whole enterprise? Does having a knowledgeable person on staff open up avenues for future services that you wouldn't otherwise have? Does the employee really cost 200k or would the overhead part of that figure be spent on another kind of worker anyway? How much is irrelevant sunk cost (office furniture... really??)...
Too many variables without a real, specific scenario.
And what does CS have to do with IT?
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.
Business/App ideas are like arseholes: everyone's got one, they're mostly shit, but very rarely they contain a diamond
When ever you get an upgrade from a vendor you have to do an entire retest because there is a lot of changes, most of which got nothing to do with you. When it is home built you only change what you need to and you can do a better job of isolating your test.
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. .
Can we please either have a Computers in Business degree that teaches useful skills
Wouldn't that be MIS (Managemnet Information Systems)?
business sees a CS degree as the basic starting point for a career in IT.
Don't people read the CS sections of college catalogs? Wouldn't the course descriptions make it obvious that this isn't what CS does?
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.
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.
Life is not for the lazy.
Not so far. The vendor keeps telling us that huge savings are just around the corner. Frankly it's starting to sound like "jam every other day". As in, Jam yesterday, Jam tomorrow, but no Jam today.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
"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!
You make it sound like being a contracter is a bad thing. Me and some of my friends are all independend contractors: We like it much better then actually working at those companies. We are treated with respect, are payed for overtime, and are our 'own boss'.
The difference in knowledge is stunning: The bigger the company, the more IT people they have, and the less they get done. Some of my friends are able to replace 5 'normal workers', that are of the kind that only have papers and zero actual knowledge.
Btw we're all in the unix, linux and storage business.
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.
Possibly a small part. I've yet to see any student be good at a job in the first few Months. You still need to train them, so to me it doesn't matter what degree they have as long as they get through HR. I could train a Philosophy student in IT.
And the honest truth is that there is NOTHING like seeing some internally developer solution for which off-the-shelf software exists to convince you internally developed software is a nightmare.
And there is is nothing like seeing 99% of off-the-shelf software to convince you that ANYTHING developed internally must be better.
The REAL honest truth is that 99.999% of software sucks donkey-balls. After a thorough rimming job.
It doesn't really matter where it is developed. Design flaws and bugs ALWAYS end up biting YOU in the ass. It doesn't matter where it is developed, if key developers leave, knowledge gets lost. Sure, you MIGHT think that a large software developer has processes in place to guard against this... but you would be a silly person. IT churn is high and this means any software project is always at risk of loosing the people that truly understand the system. A software house might be slightly better at it BUT will have to force its developers to maintain systems no longer relevant to it (do you want to work for a company still supporting windows 3.1 because its customers need it) while an internal development might not have anyway to keep a developer intrested with nothing but maintenance work.
There is no easy answer here. Ideally you would have internally a collection of tailored software that was mostly developed externally. Example, I might run my own webscript but use externally developed OS, database, webserver. But wait, that makes all your tailoring known only by your own staff...
In the end, you just got to pick your poison.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
more than 100miles/180km from a major body of water [...] flyover country
There will be a few experienced developers who just happen to come from the place and love it so much they are willing to stay there. If, however you are in a hellhole like that and you want to recruit people with the right skills you will likely have to pay double and you will have to pay extra for the recruiting. Companies in Silicon valley are having to open offices in SFO. Do you think they do this because they are unable to compare real estate prices?
=~ s,(.*),<sarcasm>$1</sarcasm>,g if any_point_you_wish();
The general question can't be answered. YOU need to do research and understand the cost benefits of each approach and make an informed decision based on the specifics of your situation.
This means all stakeholders need to do necessary reserch and then sit down and communicate with each other.
Personally I've seen enough DIY outcomes from IT shops to have a strong default of preference to keep software development as far away from IT as possible.
I don't think it's money that draws you into IT in the first place; if it is, it's probably a bad incentive as money can only do so much to make you happy.
What drew me into IT was passion for the subject, and I do believe that the only way you can possibly do a job for a lifetime is if you're passionate about it.
So while a bigger paycheck *may* be effective in bringing brighter people into the field, they'll probably be as ruthless in their craving to maximize their income as they'd be in other lines of better-paid work (you mentioned security traders, for instance, I'm not sure I'd want those for colleagues ;-))
Ever wondered whats wrong with the world? http://www.ishmael.org/
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.
You can't handle the truth.
I applaud thee, for hitting the nail head on.
But let us not forget that this is our own fault, for thinking we were untouchable in our ivory tower of arcane knowledge. We should've seen the signs as IT matured and learned how to crunch the numbers like a controller do, and market this to the policymakers.
It was fun while it lasted, but now it is all business I'm afraid.
...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.
"If anything can go wrong, it will." - Murphy
Interesting. I never knew that payroll taxes, healthcare costs and property values were identical across the whole wide world.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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..
which is totally what she said
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
What does CS have to do with IT? Having a CS degree and working in IT are two things that are purely coincidental. You do not get a CS degree to work on IT. Ever. The fact that you mentioned both in the same sentence makes your knowledge in both areas suspect.
CS != software engineering != IT != MIS. Overlap != Equality (or equivalence). It's not rocket science for fuck's sake.
If you rent office space, you pay by the square foot typically. Or some managed offices (where the landlord does more-or-less everything - internet, power, telephones, desks, chairs - all you do is show up and run your business) charge you by the desk.
In any event, that sounds about right.
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!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
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
They also tend to buy retarded shit like Citrix while ignoring robust monitoring solutions offered by several companies. So you end up having expensive developers routinely debugging common IT problems like disks being full, NFS mounts being offline and machines being down. But hey, look at the shiny Citrix!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I wrote about this sentiment a few months ago. A few excerpts.
One of the reasons I like and support the use of open source software is that you can avoid most of the drama that comes from relying on 3rd party vendors. By this I mean.. you must pay exorbitant sums for ongoing maintenance, you are locked into their product upgrade treadmill, you have little say in the direction of their products, you have a single source for support, and if your vendor gets acquired there is a very good chance the product you depend on will go away or change in ways that force you to abandon it with even more pain. I’ve seen this play out from both sides of the table having spent time in both enterprise environments and working for software companies.
In my opinion those resources should be spent building and customizing systems based on open source software whenever practical. Rather than spend your time and money propping up another companies bottom line.. spend them internally refining the tools that run your business until they become a strategic advantage. Build your teams.. invest in your people and develop subject matter experts to give IT a growth path within the company. By doing this you own the results and end up with an advantage that can’t be easily duplicated. Too often IT is viewed strictly as a cost center.. and that’s a real shame because with a little leadership it doesn’t have to be that way. Better to be a builder and own the building than pay rent forever and be forced to move every time the landlord needs more money. And if you are a C level executive.. stop basing your IT strategy on what you read in airline magazines or the latest buzzword-laden reports from Gartner and their ilk.
http://jaredwatkins.com/wordpress/2011/04/dont-be-a-slave-to-your-vendors/
Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats. -HLM
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.
The business school I am attending, in a direct attempt to address the issue caused by MBAs running IT departments, created a hybrid business and CS degree to give us the perspective of both worlds. Most of us are already working in IT in some fashion or another, at various levels, so we've got the real world experience already. I suspect more business schools will start looking at this sort of degree - why have a business major running an IT department, when you can have someone who can have an actual "IT" major instead?
Occasionally living proof of the Ballmer peak.
When you have 3 help-desk wookies at $24k/year, they can sit on the support line and click buttons as instructed. They don't need to know how it works, and frankly, most don't usually care. That's what companies want. They will sometimes call in consultants to help with the extra hard stuff because It's cheaper than having a Guru sitting around for 3x the wage waiting for stuff to break/inventing stuff to wait to break.
Until the vendors really, really, REALLY start costing companies more money than it takes to have a guru or two on hand, things will most likely remain the same. Unfortunately, most of the mgrs I've worked for are very easily swayed by sleazy salespeople making holy-grail type claims. The vendors have historically won.
Join the Slashcott! Feb 10 thru Feb 17!
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).
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
That's interesting because I've seen the exact opposite.
When I am rolling an internal app I can sit down with management and the requestors and explain clearly exactly how much time and resources will be needed. I can also suggest better options and usually a compromise is reached where they get 85% of the functionality they want, 100% of the functionality they *need* and it takes me 15% of the time the original request would have.
Comparing that to the attitudes (of others) of vendor software, we're paying them for the software AND support so they'd better damn well bow to our every whim. That usually results in us getting about 0% of what we needed, wasting a lot of time trying to get it and everyone hating the vendor software even more than they did before.
Not to mention that the vendor software rarely if ever works out of the box, as it wasn't tested by us first. Homegrown apps *always* work when they're given the official release because they were tested by exactly the crowd that is going to be using it (as well as those who wrote it).
and/or something similar to the Professional Engineer (P.E.) system. After you receive your engineering degree, pass the Engineer in Training (EIT) exam, and receive your Fundamentals of Engineering (F.E.), you must work (in my state at least) for 4 years under a licensed P.E. (essentially an apprenticeship) before you can even take the P.E. exam and apply for a license.
Sure, passion is ideal. But you're missing a couple of things. For one, people can have a passion for more than one career. You take the group of people who love computers and algorithms and you look at the prospective salaries for different careers, and IT is paying $80,000/year while writing Monte Carlo simulations for financial firms is paying $400,000/year, what do you think many of these people are going to choose?
For another thing, what do you do when you need more people than there are people with the right passion? You still have to recruit some without it. And you're going to have serious issues if those people are idiots and you put them in charge of multi-billion dollar IT systems. If you have to poach candidates from other fields, you had better do it from the ones that already attract smart people, like law and finance, and to do so you're going to have to pay competitive rates.
That's really, really low. The general rule of thumb that I've worked with for 20+ years is a lot closer to 75-100% of base salary. (Granted, that's partly because we have such a warped healthcare system in the U.S. where costs have no bearing on the quality of care delivered.) Bonuses, benefits, unemployment insurance, taxes, fees, etc. all add up, though.
I agree, it *is* amazing that they don't see it. But I think it's part and parcel of not seeing the value of the original organization or the risk involved in outsourcing your IT organization to very junior offshore personnel who only know how to follow written procedures. Once you've reached that point, not understanding why uptime is worse and development is at a standstill, and the willingness to believe the vendor's excuses, is a natural progression.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Based on your broken English (too many examples to point out) and use of the dollar sign as a trailing currency sign, this indicates you're most likely an Indian sand nigger.
There is a flaw in your reasoning though, broken English and trailing currency sign is not enough to narrow it down - so I could even be ... black (regular black nigger you call them I suppose), hispano (hispanic nigger), eastern asian (yellow nigger) or plain european (white trash nigger).
As the first foreigner you meet, let me welcome you to The Internet, the amazing place full of people you can hate.
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.
Either someone has to provide those things and pass on the costs, or the costs are saved through removing those benefits and the savings split between client and contracting company. Regardless any third party will need to make a profit. You save next to nothing and you get what you pay for.
These posts express my own personal views, not those of my employer
So you're saying the contracting company has to pay all this stuff too? Yes, that should be obvious, but it's beside the point. This mini-thread was about saying the loaded cost of a developer being over $200k, and "MrEricSir" wondering why he isn't getting a paycheck that large, when apparently he's forgotten about all the costs incurred in hiring an employee, and other people educating him on this subject.
Anyway, the idea is if you're a company thinking of hiring a team of developers, or contracting something out, you need to know your fully-loaded cost per employee (which as should be abundantly clear after this thread is much more than just that employee's salary), so you can compare doing that job in-house to contracting it out. With the contract option, you don't care about what their overhead costs are; that's irrelevant, and it's part of the cost they quote you, so it's easy to compare that side of the equation; the other side (being how much it'd cost you to do it in-house) is more complex because you need an accurate figure for the fully-loaded costs.
Now you're right, on the face of it the contract option should be more expensive because they'll also have overhead and they'll have to tack on profit too. However, it might still come out cheaper depending on what you're doing and many other details. If their employees are in a low cost-of-living area like Bangalore, Chile, Alabama, or North Dakota, and your office is in Silicon Valley, then their fully-loaded cost will be much lower right off the bat. If their employees have already done very similar stuff before, they may be able to finish the job much quicker and more efficiently than you if you're having to start from scratch. And finally, there's the problem of hiring: if your task is too big to saddle your existing employees with and you'll need to hire a new team, staffing a new team takes a lot of time and effort to find the right people, whereas the contractor might already have competent people on staff ready for this job. Of course, there's lots of risks too: the contractor may be lying about having the right people on staff and may not hire any until the contract is signed, causing them to not meet the schedule. The contractor may do a half-ass job forcing you to either dump their results or worse pursue a court case for breach of contract (though that's not likely to do anything but cost you even more money). But if your own organization is severely broken internally, then you might very well get better results by farming the work out to contractors with good reputations. My last company was like that; they were working on a big new project when I quit, where they were farming pieces of it out to a bunch of different companies (and of course having all kinds of problems, and the fact that I haven't seen this product released yet after all this time tells me it was a failure). However, after seeing the management there, I had no confidence that it would have been any better if they staffed up internally and did it themselves; they were just too incompetent at running an effective organization. Last I heard, they were bought by their next-larger competitor, but that was over a year ago and they're still there, so I'm not sure what happened; maybe the buyer changed their mind after seeing how poorly run the company was.
I agree. My university had two degrees in computer science: Master of Science and MBA (master business agoraphobia?) The problem was that the MBA courses were just bullshit business management courses. If they somehow instead had courses on the practical application of CS in the workplace have taken that track in a heartbeat.
Millions long for immortality who do not know what to do with themselves on a rainy Sunday afternoon. -- Susan Ertz
Nope. You could easily do this with less people, you still dont need to outsource, you DO need to leverage existing ideas and software. That's the difference.
They won't be beholden to talent. Period. They don't want the one in ten thousand programmer working for them, period. By the same token, they don't want to develop talent in house so there's little tradition of apprenticeship in software, at least, that's the bad reason for it, the good reason of course being that the new programmers have a newer and better approach to software.....
On that last point, I get the impression that progressive places like ThoughtWorks (with whom I have zero connection and always will have zero connection) DO have a sense of apprenticeship and Do seek to develop talent. In cases like that, the people doing the mentoring are so good that the apprentice is always benefiting from their tutelage.
When i was in college, our Systems and Analysis teacher, a full professor and also long term corporate vet opened class one day with thsi bomb:
When you take over a department, your first priority is to find that one guy that you absolutely positively cannot do without, and fire him.
No kidding. They don't want anything to do with talent or high achievement. The drive is always to move IT as far a possible at every level toward the McDonald's Model of labor- programmers are commodities who can all do the job we ask of them.
The sad part is, they achieve this only through all programmers being equal amongst other politically driven, power seeking fuck ups.
Yeah that's right, BILLIONS of dollars spent by numerous US states on IT projects with NOTHING to show for it.
It's a diseased system from one end to other.
In my imagination, it's different elsewhere, like, say in Germany.
Am I dreaming, Herr Programmer?
there are lousy homegrown solutions and great vendor applications (and vice versa). It depends on the caliber of the development team.
If you're a reasonable sized company and you hire a team, you generally keep them busy. A lot of what you say only applies if you hire one team per project, and each project is significantly different.
I've worked for small companies and large, contracted and worked directly. There are advantages and disadvantages, as well as hidden costs, to each approach. The best thing about directly hiring an employee and treating them well is that they'll likely take some pride in their work instead of them or their boss trying to treat you as a revenue stream and milk you for every cent they can get. From my point of view as the developer, it is easier not to have divided loyalties.
If you start out with incompetence, it doesn't matter how you set your team up, you'll fail.
These posts express my own personal views, not those of my employer
Then you know very few people. The revised topic says it all.
You're more or less disposable, not flexible.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Being with the company directly has the direct benefits and support of the company - versus a disposable contractor that is sought more for easier separation from the company than any merit.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.