How common is it for a team to write everything in-house? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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!)

Answer 5

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.

Answer 6

It's not common where I live, and I know a lot of companies though colleagues. I'd go as far to say it's an immediate "no thanks" from me.

I won't regurgitate the good points already made, but I will add one thing.

They have just made hiring a lot more difficult.

• All new hires have an even steeper learning curve than just the main part of the software/domain
• The best candidates will be put off as they will not want their skills to become unused.
• People are not likely to stay around long once they realise how bad it is not getting to use their favourite tools, and staff turnover is expensive

Now there will of course be people who like the challenge, but I think they'd be in the minority.

And equally, there will be some companies who operate on "Internet scale", Amazon, Facebook, etc., where they have insane custom needs, but again these are in the minority.

Answer 7

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.

Answer 8

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.

I would personally not go to a place with such culture.

Answer 9

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.

Answer 10

Of course you should walk away. I haven't seen it mentioned here, but the biggest reason to pass over the job is because you won't gain much in transferable skills.

Imagine at your next interview when they ask what technologies you worked with and you can only mention bare bones C++.. That sounds like graduate level

Answer 11

Big companies write everything themselves.

There are several advantages in writing it yourself:

1. You're guaranteed to own the software yourself
2. You can correctly calculate work amounts that went into creating it
3. Repeating your steps becomes possible even if next time the libs are not available
4. It cuts down your requirement bloat
5. You're not repeating what others have done already
6. You're guaranteed to have enough people to maintain it
7. You can modify every part of the software
8. Software size is limited by amount of resources you have

Here's how each of the points break if you use someone elses library:

1. Someone else owns the lib
2. You don't know how much effort went into creating the lib
3. Your next version of product is impossible to create on new platform since same libs are no longer available
4. Ability to implement requirement is dependent on whether the lib implemented it years ago
5. Someone else also uses the same lib, getting same limitations and features
6. Since you didn't create the libs, you don't have enough people to maintain all the software in your product
7. Libs are binaries, nonmodifiable. Even if source is available, you don't have enough people to modify that large amount of code.
8. Maintaining the code you created + the libs is bigger effort than you originally estimated