

In Defense of Not-Invented-Here Syndrome - jayro
http://www.joelonsoftware.com/articles/fog0000000007.html

======
angersock
_What these hyperventilating "visionaries" overlooked is that the market pays
for value added. Two yuppies in a living room buying an e-commerce engine from
company A and selling merchandise made by company B and warehoused and shipped
by company C, with customer service from company D, isn't honestly adding much
value._

I find Spolsky kind of hit or miss, but this I rather agree with. Then again,
one wonders if the current funding climate _cares_ about this truth.

~~~
WorldMaker
I find Spolsky almost entirely "miss", but then I had something of a feud with
him and that colors my reading of his articles...

I think the clear thing that is missing here in this section you've quoted
(and the article itself) is that if your components are properly factored, or
at least reasonably factored, (whether 3rd party or internal), you can "value
add" on top of the component without rewriting its source code (or even
necessarily treating it as anything more than a black box). Don't throw the
babies out with the bathwater, you know.

The point he tries to make with "If it's a core business function -- do it
yourself, no matter what," is undercut by his over-generalization in "If
you're a software company, writing excellent code is how you're going to
succeed.". If you are a software company and you've scoped "write all the
software" as your job then you're likely to hit a brick wall when it comes to
delivery. Your value as a software company isn't in how well you've rewritten
the parts of code (like say a C compiler) that you can buy off the shelf, but
in getting your final product out the door. From that perspective it truly
doesn't matter how much or how little your product consists of your own code
versus third party code so much as the product delivers the functionality you
intend it have and adds value in meaningful areas.

While the example above of puzzle-piecing a product out of a bunch of well
known smaller components isn't _glamorous_ , it gets the job done and
hopefully pays the bills. Presumably if done right it gets the job done faster
and more productively than your competitors that are reinventing everything
themselves... Also, in the industrial world outside of software, optimizing
the pieces of the puzzle is entire sets of sub-industries (such as Supply
Chain Logistics) and again while that's certainly not exciting work, it can be
profitable and the market is paying for those skills.

Finally, I think it says a lot that the best example Joel could think to use
was an out-of-date example from a version of Excel that no longer exists built
by a team that also no longer exists. I don't doubt that there is code
continuity from that era, but the days of Excel being a walled garden from the
rest of Office, much less the rest of Microsoft, are past... I know there are
critics of the push towards a "One Microsoft" culture and elimination of some
of Microsoft's worsts NIH tendencies at the cultural level, but this consumer
is a fan and watching what Microsoft is doing in Open Source these days is
fascinating and wonderful. I absolutely think this example Spolsky cites is
dumb. If Excel's 80s C compiler was so great they should have handed it off to
the Developer Division to augment or better the C compiler they were selling
as a product! In this case that actually was a core competency of the company
and inter-team feudalism and NIH was decreasing the overall efficiency of the
company and potentially keeping useful, profitable, and marketable
enhancements from the profit center that could most benefit. Really just an
all around terrible example.

