In Favor of Homegrown IT Solutions 265
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.'"
Exactly... (Score:4, Interesting)
Integrating Diverse Software (Score:5, Interesting)
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.
Source Code License (Score:3, Interesting)
Re:Now if only ... (Score:5, Interesting)
Of course, I'm a guru, but I don't want to work for the "we contract everything" crowd, so maybe thats the problem.
Find a decent employer, for what rarity they are. (Score:4, Interesting)
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)?
Yeah totally stupid. (Score:5, Interesting)
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:Integrating Diverse Software (Score:4, Interesting)
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 [blogspot.com].
Oh Dear God No (well, maybe Yes, sometimes) (Score:2, Interesting)
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.
What business are you in?? (Score:4, Interesting)
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.
IT needs apprenticeship not degrees. Tech school + (Score:5, Interesting)
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 (Score:5, Interesting)
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.
academia is poor for skilled laber as well (Score:4, Interesting)
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:maybe it's time for IT unions (Score:5, Interesting)
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.