But essentially you're right: anything that allows you to distinguish your core business from other peoples' efforts is something you should do yourself. All too often, people look at their IT budgets, go, "this isn't our core business", and outsource stuff they shouldn't.
If you work in a time critical environment, don't outsource things on your critical path, because EDS will never jump as quickly or as high as your internal staff.
Doing core functions yourself and outsourcing everything else is good business. Core functions are where you create sustainable competitive advantage, which is where market value comes from. If you outsource your competitive advantages, they won't be sustainable.
Michael Porter wrote an excellent article in HBR a few years back on a similar topic (but not at all about code reuse, of course).
He argued that 'operational effectiveness', which is what you get when you use the same system everyone else in the industry is (or will be) using, is not sufficient for success; companies need to figure out what unique value-add they offer and then focus on performing those activities better than anyone else in the industry.
NIH is different than "Manage risk".
NIH to me means "we didn't think of it, so it can't be right."
Manage risk means understand where your internal and external risks are, and deal with them in the best way you can.
From the point of view of the Excel team in the example, this meant "we know from painful experience that we can't count on the compiler team, so let's maintain our own compiler."
There's a cost to that, and if the team would never, as a knee-jerk reaction, look to offload that cost, *then* there's some NIH going on (or maybe they should take over the compiler team :->).
Your conclusion is accurate, however: don't outsource your core competencies. That's risk management.
The problem is, naturally, identifying risks. Most people don't do a good job of that.
I, for example, get extremely nervous about third-party software that I can't build from source in my SCM sandbox. The risk is that if there's a bug, my project will be at the mercy of someone else. That doesn't mean I won't use such third party software, it's just a risk.
Take another example: if your area of core comptency is "Y", but before your excellent code implementing "Y" can run, you depend on "X", but no third party can seem to get that right, then you'd be dumb to not *get* a core competence in "X" (or run away quickly).
Risk is just another thing to trade off against cost, schedule, and quality. I can cobble something together with a bunch of third party components, and that'll work great for a demo, or maybe even for a small deployment. Or maybe even forever. But the risks of using third party components just simply weight against, for example, the risk of not getting something done.
NIH is much more dangerous. It says that the risk of external ideas (or code) is infinite, and the risk of internal ideas is zero. Very dumb, even if you are smart.
ill Hofmann
Monday, October 15, 2001
However, my experience has been that 1 or 2 very high-quality developers are worth about 15-20 average developers. Not only is the system architecture more consistent but you don't have to deal with 10 developers who have a hard time finding their butt with both hands and don't add any value to the team. Find good people and take care of them. Pay them well. Let them have Friday afternoons off to play a round of golf. Trust me, you'll save money and end up with a better piece of software.
Comments