In a recent interview I asked the interviewers "how do you go about evaluating new technologies and libraries (such as SignalR) and bringing them in to use?". They said they don't, that instead they write everything themselves so they don't have to rely on anyone else.

The firm doesn't work for the government or defence contractors or on any safety-critical projects or anything like that. They were just your average, medium-size software development firm.

My question is: how common is it for teams to write everything themselves? Should I be concerned by teams that do?

Edit -- Most every response has said this is something to be concerned by. Would a second interview be an appropriate time to ask them to clarify/repeat their position on writing everything in house?

I don't think this is as ridiculous as people say... Recently I've wasted an incredible amount of time fixing abandoned libraries for new framework versions, new versions of libraries with severe breaking changes that weren't documented and even huge gaps in significant frameworks like jQuery that make them not fit for purpose. People don't put enough effort into deciding whether third part components will add huge maintenance overhead and often end up with a pike of unmaintainable spaghetti dependency hell.
–
Danny TuppenyApr 21 '13 at 8:08

4

NuGet is awesome, but makes it so easy to do this. I installed some trivial helper library from NuGet recently, and it pulled in Castle and all sorts of other bloated crap. Sure; an outright ban is strange, but it's no more stupid than allowing every dev and his dog to randomly pull stuff in without real thought.
–
Danny TuppenyApr 21 '13 at 8:10

13

Everything? Does that include their own browsers, operating systems and compilers? Otherwise they are just deluding themselves.
–
Muhammad AlkarouriApr 21 '13 at 16:00

4

Of course it's as ridiculous as people say. The fact that a) it's possible to choose the wrong library for the job and b) there are situations where no third party library available will meet your needs better than an in-house one: does not mean that blanket policy of never using third party libraries is correct.
–
user16764Apr 21 '13 at 17:42

11 Answers
11

An attitude of never using third-party libraries is preposterous. Writing everything yourself is a horrible use of your company's time, unless there is a strict business requirement that every line in the codebase was written by an employee of the company -- but that is an unusual scenario, especially for a private-sector firm like you've described.

A more rational and thorough answer may have been that they would only use third-party libraries that:

Meet the needs of the code they would otherwise write themselves

Were available under a license compatible with the company's business model

Included tests

Passed a code review

If those criteria were met (and in my experience the code review is very flexible especially in the presence of good tests), you're no longer "relying on anyone else" -- you're relying on existing, available, and preferably robust code.

If the code is open source, then in the worst case, the third-party library becomes unmaintained. But who cares? The tests prove that the library is suited for your needs!

Moreover, an aversion to established third-party libraries seriously hinders programer productivity. Let's say the company was writing web applications and refused to use (e.g.) jQuery, so instead wrote their own alternative cross-browser library for simplifying DOM manipulation. With near-certainty we can assume that their implementation:

Will have an API foreign to developers already familiar to jQuery

Will not be as well-documented as jQuery

Will not have relevant Google results when encountering problems using the library

Will not be as field-tested as jQuery

All of those points are major barriers to programmer productivity. How can a business afford to give up productivity like that?

You've updated your question to ask whether this is appropriate to bring up in a second interview. It absolutely is.

Maybe you misinterpreted your interviewer's answer in the first interview, or maybe the interviewer just incorrectly explained the company's position and a new interviewer can clarify it.

If you explain that you're concerned about their stance on external libraries, there are at least two possible outcomes:

They're open to change, and your concern about their process makes you look better than some other candidates.

They are not open to change, and they think of you as "the kind of developer we wouldn't want to hire." Doesn't matter, that's not the kind of place you want to work anyways.

"If the code is open source, then in the worst case, the third-party library becomes unmaintained. But who cares? The tests prove that the library is suited for your needs!" You also have the source code, which puts you in the position of having what you are using now and being able to update it to meet any future needs. (Yes, getting used to an "alien" code base takes time, but so does rolling your own.)
–
Michael KjörlingApr 25 '13 at 8:36

That seems incredibly uncompetitive. I've worked in shops that decided to skip the standard open-source libraries like Hibernate and roll their own due to some "critical" missing feature. In the end the software was incredibly expensive to build and maintain. Of course the expense of the in-house library was grossly underestimated. And while the in-house library was written, the standard libraries advanced rapidly, adding new features that weren't available in the in-house library. In the end, work that would take an hour using a standard library instead took two days. And it was bad for the developer's careers, as the world passed them by. I would avoid a shop like that. I like to deliver, and don't have the patience to rewrite when I could reuse.

Since the developers no longer had relevant skills for other jobs, company money lost on extended dev time was saved by not having to replace departing team members! #stratgey
–
Michael PaulukonisApr 22 '13 at 19:40

@Michael: The only people they could retain were the people who were present for the original decision to create in-house frameworks. New hires tended to leave after about a year.
–
kevin clineApr 22 '13 at 22:56

+1 If the missing feature is really, truly, crucial: modify the open-source library and contribute the feature into the main source. Delivers great business value, makes everyone feel good and it's excellent for everyone's CVs because they now have now made an open-source contribution.
–
MarkJMay 20 '13 at 10:56

The shop has a disease called Not Invented Here. It is a good reason to terminate the interview on the spot and leave immediately. This can only be cured by a top-down house cleaning that is very unlikely to happen.

To answer your question, it is sadly much more common than you might think and it's definitely a reason to be concerned.

Yes, definitely be concerned! That reeks of arrogance and (sorry to be harsh) stupidity. Any programmer with half a brain will use a library like signalR instead of writing it yourself. There is absolutely no point in wasting your time solving a problem that has already be solved. I would possibly try to find out more information first - they might have misunderstood you (might be difficult though if the interviews are over!)

I have a couple of friends who have both (briefly) worked at software houses with not invented here syndrome. So the mentality is out there.

An observation they both made was around the culture the approach fostered in the development teams. They both ended up working with people who were quite insular in terms of their outlook on software development, and people who were not really driven to learn new things and push for quality. Regardless of what stage you're at in your career, you would always like to be working somewhere where you stand a chance of learning new things from your peers. This sort of environment however seems to generally not be found in places that wish to roll everything themselves.

I don't think a software company can survive today without relying on third party and/or open source software, and in order to remain competive they of course need to actively keep track of new technologies. There are often good reasons, however, to take at least a rather defensive view on it.

As an example, if you sell software and claim to provide 24/7 support and also are legally responsible for your software to operate correctly, then you need to have a very precise idea of what is going to happen if there is a problem with your software in, say, a factory where 1 hour of production downtime may cost several millions of dollars, and then a serious bug happens to be in that open source library you were using. Believe me, you will perform very thorough assessments of the software in question.

From what you've written this scenario does not seem to be at the heart of the matter, though.

If you are a technology based company of a certain size, than it would seem that you will be developing more and more of your own tech, for example: google develops alot if not most if not all of their software while open sourcing most of it in the pursuit to make it an industry standard.

For smaller companies, it would seem like an utter waste of time when they're trying to ship a specific product with it's own business logic, and in my experience I haven't seen that small-medium sized companies do so.

It becomes more intricate when you're talking about heavily-specialized code base, for example: encryption algorithms - some people have a basic understanding on how they work, but the intricate parts of actually implementing a solution would seem like shooting yourself in the foot unless you hire a cryptographer which specializes in such things.

Some companies do allow freedom to create your own open source projects, which seems more appropriate.

What you've got is a really good opportunity to go into the second interview and ask them some tough questions. I don't know what the company does so it's difficult to say why this seems a strange choice. You could use the comment by @Daniel Pryden with regards to Google's usage of third party libraries.

Any piece of software you use, whether it is in-house or from a third party has advantages and disadvantages. Not to use a tool because it's not in-house, even if it is the best tool for the job shows a certain closed mindset and that's never going to encourage innovation and creativity.

Perhaps though, just perhaps, you're the person to introduce that change. Good luck with everything.

"I haven't seen it mentioned here" - did you look at other answers, for example at this one?
–
gnatMay 20 '13 at 6:18

2

Wont gain much in skills? Thats rediculous. Thats only true if you view programming as playing with Lego blocks, stacking components together. If you have to 're-invent' a library, you're going to learn an awful lot about a particular topic.
–
GrandmasterBMay 20 '13 at 16:34

@GrandmasterB You are correct, allow me to clarify - A lot of places ask what tools you worked with. Your chances of getting overlooked are much higher if other candidates can hit the ground running while you would have to learn from scratch.
–
Martin KonecnyMay 20 '13 at 17:21

Wouldn't the logical extension of these arguments be to also write your own compiler (probably for your own language), run this software on your own OS, and probably build your own HW too?
–
timdayApr 20 '13 at 17:59

4

1: Yes and I can pay a fee to use it (without spending money to build it way the difference in cost). 2: If I am not building it I don't care. 3: In business platforms are slow to change. Staying cutting edge is rarely a requirement. But good software moved easily. 4: Not true. You just transfer the bloat from external to internal. 5: Does not make sense. 6: Not true. 7: True but means you need to divert your precious programers (the most expensive part of a project) from real work into bug fixing on something that could be maintained elsewhere. 8: That's a bad thing.
–
Loki AstariApr 20 '13 at 18:08

5

Many big companies make extensive use of open source code in various forms (including libs), often improving on/contributing to the relevant projects. The points are mostly irrelevant or incorrect.
–
MattApr 20 '13 at 18:21

7

@tp1: I work for Google and I can assure you that Google very much does use third-party libraries when they meet our needs. Many times Google has needs that are unique or at a different scale from many other software companies, so for one reason or another Google will often develop things in house. But Google also uses a large number of open-source libraries, and/or open-sources lots of internal libraries, so not everything is in-house. Most of your points no longer apply for open-source software, since by having the source you ensure that you can always debug it and fix it if necessary.
–
Daniel PrydenApr 20 '13 at 23:14

5

"No, the value comes from accurately implementing the requirements. If it was built before requirements were known, it cannot accurately implement those exact requirements." Clue: If you think this argument has any merit at all, then you've failed to understand separation of concerns.
–
user16764Apr 22 '13 at 18:11