How can I combat the "Not Invented Here" syndrome?

Question

In the organization I work for, there is a strong aversion to many things that weren't built in-shop. For example, We make very little use of JavaScript libraries, suggestions for looking at development frameworks such as templating are often never considered or simply put off indefinitely.

We don't have many developers ( < 20 ), so time spent writing code that has already been written, tested and optimized by a community feels like time wasted.

Assuming we don't have any outstanding reason not to adopt third-party code, what, if anything, do you suggest to ease people toward the mindset that libraries can be an acceptable part of our product?

Answer 1

First, point out that many such libraries are FREE. (Many manager seem to think writing code inhouse is cheaper than buying it, but even they can recognize that Free is Free)

Answer 2

The proof is in the pudding. Leverage an existing tool to create something spectacular. Who can argue with success?

For instance use a Javascript library to make a web based interface that far exceeds the expectations, yet didn't take long to produce. Now everyone else looks like a dolt for not using similar technology.

Answer 3

I think it depends on why they are rejecting the third-party stuff. Existence is not necessarily a good measure of fitness for use :)

I think it is generally true that when you use a third-party package (whether it is free or not) 1) you will usually use only a small amount of its functionality, 2) the bigger the package the more complex to learn, and 3) you often have no control over quality or new capability development.

Given these facts, I think it is often perfectly legitimate to eschew 3rd party stuff and just write the small portion of it that you need yourself. It reduces complexity and gives you control.

Answer 4

Ask them if the in-house libraries themselves provides a significant competitive advantage that you weren't aware of. Listen. Next lay out the case for open libs/utilities (which generally constantly improve--even without their potential contribution) which can make your end-product software more competitive (high quality, developed/iterated in shorter time span).

Answer 5

I would suggest using 3rd party tools externally first to help you code (i.e. have it help you generate code that ensures that you stick with an xml schema). Once the management sees how much time it saves and how much more robust the product is, they might be more willing to let you use external libraries.

That being said, TEST! otherwise it'll look bad on you and set this attempt back a long ways. Also make sure you know what rights you have and what you may need to do to conform to the license of the tool you've chosen.

Answer 6

Even if the third party code isn't free, it shouldn't be hard to show whether the amount of time saved by not writing is worth the cost of the product.

Time is money.

Answer 7

For me personally, it's more fun to develop new stuff than to learn the interfaces to something else that's been developed. That's motivation. And there are always places where I would have done things differently (even if they are unimportant) which serves as a weak justification.

This sets up a conflict between personal enjoyment and the productivity goals of the project. I believe this is the fundamental psychological cause of the problem.

To resist it, get your team to focus on productivity, and acknowledge that sometimes it's less fun than writing code from scratch. If they can acknowledge that productivity sometimes comes at the expense of enjoyment, they will be better at controlling their own desire to jump in and start coding.

Answer 8

I've been reluctant to use libraries in the past for 2 primary reasons:

• It will take almost as long for me to learn how to use the tool/library as to just create what I need from scratch (and my own pre-existing code)
• Libraries almost always have way more in there than I need which constitutes unnecessary bloat and all that extra code could have something which interferes with existing code

Both of those reasons are crap. Sure, there is some time required to get to know the ins and outs of what ever you want to use, but once mastered the net impact to the project will be positive.

Many libraries are modular and allow you to tack on only the pieces you need.

The only other reason I can see for balking is the Intellectual Property concern. Who owns the source, what license is it used under, how likely is this to come back and bite us?

You're on your own for the last one, but as a recent convert, I think the first 2 arguments can get your library-using code in the door.

Answer 9

I was in the middle of a similar situation about two years ago. I got annoyed with a co-worker who was bad about using the flavor-of-the-month Java or Javascript library every time he started a new project. It made most of his programs look really nice, but the code was so different in each of them that it was not easy to maintain.

I thought it would have been best to get a group consensus of which libraries were okay to use (stable, open source so we could modify if necessary) and stick with a core group rather than just letting people use whatever they want just because it has a feature they like.

Also, once you start using third party libraries you run the risk of getting into Jar or Dll hell where library A depends on version X of library Z, but library B won't work with version X - it needs X.5.1.

I'd say to try to limit the use of third-party libraries to a few that the group has tested thoroughly, and be prepared to deal with the consequences of that.

Answer 10

I've been in positions like this before. The only way to deal with it is use it on something small and build a business case.

Include how much time you saved, details fo what was invovled. What the possible risks might there be if used.

If it's open source, and even better still being developed & updated, the arguments about not having source soon disappear.

If you can prove a strong business case for it and no one still comes round, it's probably time to make sure your CV is up to date.

Answer 11

I find it difficult to accept a dependency on a third party library for a project because I'm trading work for risk. I know I can make a widget control, but I think I can make a third-party's widget control work for my situation.

I generally start using a third-party library for something non-critical and build my confidence using it so I can know it will work for my next project.

Answer 12

I believe such a decision needs to be made on a case by case basis, but if you can leverage a library or framework that already exists and is well adopted (not flavour of the month), it will save you time and money.

One other point that hasn't been mentioned yet. There is always the initial learning curve for the team when using a new product, but what do you think the learning curve is when new resources come to your project. The odds of them knowing a well adopted library before they arrive is pretty good (and can be a job requirement), whereas they are guaranteed to not know your proprietary solution.

Answer 13

It also depends on WHAT you are doing. What is the core competency of your firm? A lot of the answers here point out that there are many open or free or stable and established frameworks in many areas to use. But just because it exists, it does not mean that it should be used. Here are some various cases on this:

1. In my experience, use of externally developed code happens once people get fed up with doing something that is obviously not value-adding or too complicated -- and just a standard thing everyone has. A good but obscure example is the edison design group that produce C++ parsers. If you are building a compiler, just buy the parser! No need to reinvent that piece. But the rest, you can surely add value to.

2. If the thing is overwhelmingly huge and generic, it is easy to get people to use something external. Eclipse is a very good example, it provides a platform for IDE UIs that would take any individual company many years to develop. If all you need is a little GUI for your heavy-duty static analysis code product or compiler or other development tool where the value is in the backend, it is the obvious thing to build on. And that is what the Windriver, IBM/Rational, Freescale/Metrowerks and other giants in tools are building on today. You cannot compete if you invent it yourself

3. If the component is core to your product's functionality, I don't think you should use external libraries without thinking really hard about it first. The risk you run by its bugs or unannounced changes impacting your code, or the fact that you do not gain an edge but become like everyone else, can often be a good motivation for NOT using existing things that superficially look like the real thing. For example, the STL libraries are nice, but if you need deterministic behavior in your program, you often need to write your own collections that do iterations over data in a manner based on some immutable property of the data and not some accidental location in memory.

4. Since I am used to working with quite highly qualified people in very complex software, the idea of being able to hire people that know a particular library is really not very important. Any programmer should be able to learn any environment, and the random things they already know should not matter that much. I do not think that should impact the decision, if you assume you will keep your staff for a long time -- which is pretty much necessary to have a well-functioning development organization anyway.

Answer 14

Do the math!

Work out what the costs internally are based on development resources to implement something that's freely available or available at a cost.

Then then numbers should speak for themselves.

We mitigate the risk by either using open source or by only using third party components that supply the source code also so that we can support it should they be unable to.

Answer 15

Some components are made very well and are actively maintained. Thinking that a team of 20 will outrun the production of high grade free libraries is really crazy.

That being said, it is really depending on the kind of app you do and the liability that you'll have when a failure occurs.

If the liability is not that high, then this would be a good thing. BTW, are you going to recode Google maps yourself ? Free API, nice results. Same with GoogleToolKit or Flex. So, a free platform would be acceptable to code against but not libraries...

When it comes to DLL hell or JAR hell, indeed this is a huge issue. Resume-driven development is not the way to go. But the solution is to have a respected technical lead who has seen the light and has proper communication skills and a stick to use when needed.

Nobody's going to rewrite Windows APIs (well, some do but it takes a while, look at Wine). So, why not using other components ?

Look at PHP ADODB or Smarty for example, these are super systems working fine.

Answer 16

First, as others have stated, make sure it really is advantageous to use a 3rd-party solution for a given problem. Often, it isn't.

Second, point out the disadvantages of developing your own solutions (if possible, provide specific, quantitative evidence). These often include:

1. It takes a lot of time to roll out your own solution. (Think of design time and test time as well as development time).
2. It's a pain to maintain your own solution. (You may have legacy examples you can point to that nobody on your team likes maintaining.)
3. Your solution is more likely to be buggy. (Presumably, the 3rd-party development team has more experience in the area and is more focused on the solution. To them, it's their primary work. To you, it's just a small part of your overall work.)

Answer 17

Joel discusses Not Invented Here syndrome and why it may be an appropriate response. His big take-away point is:

If it's a core business function -- do it yourself, no matter what.

One point to remember is that for a JavaScript library - unlike, say, an optional Operating System component like DirectX - you can strip out the stuff you don't want, leaving only that code you want to use; plus, if you find bugs, you can fix them - the source code is sitting right in front of you.

The big JavaScript libraries (for example, YUI) are extensively tested on a range of browsers, and all the cross-platform bugs are addressed.

Contrast this to a browser, something that your team also uses - indirectly. The execution platform for your application is highly variable, some browsers are Open Source (FireFox, Chrome) and some aren't (IE, Safari, Opera), and yet your team isn't off writing their own. They're working within the constraints imposed by the environment.

Even if an inhouse library is a bad idea, you're going to have troubles convincing management of that. You already have an in-house library, so switching to a third-party library is just going to cause pain. Humans also have a lot of trouble letting go of sunk costs, even if on-going costs will be lower.