7 ms·

Invented here syndrome (2015)

89 points by delian66 10y ago

dzhiurgis 10y ago
https://en.wikipedia.org/wiki/Inventor%27s_paradox https://en.wikipedia.org/wiki/Inventor%27s_paradox
deleted 10y ago
[deleted]
mamon 10y ago
One reason of "invented here syndrome" is proliferation of crappy developers. I've seen that many times in the companies are worked for (as senior dev / architect): the code that is required by some web framework or library is quite clean and well structured, code that is at core, business logic is a mess. Tell some junior to mid-level developer to write any significant piece of application and the host of bugs and NullPointerExceptions will follow. Finding a library for everything and only leaving simple gluing them together as a task for developers seems like the only way of ensuring minimum required code quality.
- k__ 10y ago
  The other extreme is people who end up with hundrets of deps in their project.
  - ben-schaaf 10y ago
    'node_modules' can get quite scary
- sgift 10y ago
  If all they are allowed to do is gluing code together they will never learn and will never get better at anything than .. gluing code together. Sounds like a bad idea.
  - mamon 10y ago
    Maybe part of the issue is that I personally never work as full-time employee. I'm more like consultant, hired on per-project basis, so training less experienced developers is neither in my job description nor in my schedule.
    - Nursie 10y ago
      I work as a consultant on a project-basis too. I would tend to consider training up of any permanent staff on the team to be part of my job. Perhaps not on basic technology, but certainly on what we're doing. That way, when I leave, there's still knowledge in house. This may seem to limit business opportunities, but I consider it part of a job well done.
  - lmm 10y ago
    If gluing code together is sufficient to solve the business problem (and 99.9% of the time it is) then it's probably the most efficient thing to be doing, and absolutely what they should be focusing on.
- awinder 10y ago
  Invented here and not invented here are equal signatures of crappy developers, in my opinion. I'll admit there's some skill involved, sometimes, in the engineering efforts of the NIH minded developer. But I've also seen NIH developers insist on building things like CI servers, company wikis, and message queues. And none of them have even been tangentially better than the alternatives. They're both mindsets that speak to immaturity and lack of judgement, but man, I've seen way more of NIH than IH, and in a lot more business-destructive senses
- ohnomrbill 10y ago
  On the other hand, I've just been at a place where "invented here syndrome" masked crappy developers to the detriment of the business. One tester spent 3 days tracking down a simple python dependency bug - but in the meantime he was productive because Travis is so easy to set up, and his Ruby tests worked. Travis is definitely more appealing to me than maintaining my own Jenkins instance. But I can't help but feel that we would have caught this guy's crappiness much earlier if he had to set up his own Jenkins job instead of a travis.yml file.
V-2 10y ago
> Perhaps a library covers only 95% of the requirements 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often. If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. > Being available in a package manager, being downloaded by thousand of people, or having a fancy web page, are no indications of a good product. 1. Being used by thousands of people isn't by itself a guarantee that it's good, but it surely makes it more likely. 2. Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument.
- wolfgke 10y ago
  > If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. Depending on the situation this can mean having to understand lots of gory details of the implementation of the library. It is often easier to write an own implementation from scratch than having to understand these details and subtile interactions. Typically "open source" just means that the source code is available under an OSI-compatible license and not that there is also a documentation available that guides you from barely understanding the library to understanding every implementation details that is necessary to do internal changes.
- wtbob 10y ago
  > If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. You're not wrong, but you are assuming some things: 1. That the library is written in a language suitable for the task. E.g. if you're doing real-time programming you probably don't want Visual Basic and if you're doing security programming or text processing you probably don't want C. 2. That the library is written well enough to read. You'd be amazed how much truly bad code is out there. It runs, but … it's not good. OpenSSL is an example. 3. That the library is architected in such a fashion that the 5% functionality can be added without major rework. The functionality may be small, but adding it might require quite a lot of architectural change and refactoring.
  - 10y ago
whatever_dude 10y ago
I take a more selfish approach on this debate. I nearly always write my own code to do something, even when a library already exists... just so I can understand the problem well. Then, when I finally decide to use a specific library, I understand why they're doing something in a specific way more clearly. Maybe not the most advisable route for commercial work, but one that keeps me satisfied.
- moron4hire 10y ago
  You're going to need to understand how the system works regardless. So you can spend the time learning how the internals of someone else's library works, or you can learn how to solve the problem and write your own. In my experience, there is rarely a difference between the two. But when I write my own code, I know how to make it integrate with all my other code better.
- morbidhawk 10y ago
  I do the same thing all the time and I'm trying to break this habit since it might be holding me back. I'm trying to realize that I can learn a lot from someone else's work and by diving in and learning the ins and outs and even reading the library's source code I can learn a lot more than experimenting around trying to produce similar functionality myself. Reading code is far more tedious though than being able to creatively experiment with something. The creative learning is important I'm just trying to use it in other applications than re-inventing a wheel that already works well
imagist 10y ago
The longer I work, the more NIH I get. There are two reasons for this: 1. The ease of creating a library these days is resulting in a proliferation of utterly crap libraries, so bringing on a new library is more and more of a liability, both to future reusability of code and to security. 2. As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs. These combine to create a situation where I'm less and less likely to want to import something.
- mortoray 10y ago
  #1 has a big influence on my argument. I think it was Python and NodeJS library systems that made it super simple for people to publish libraries. There are a lot of trivial libraries out there, and many of questionable quality. Sometimes using a library ends up as more work than writing the bits of code myself. It's not like I'm going to decide to write a new 20k line library for my project, but if something is only a few hundred lines of code it's definitely easier to just rewrite.
- onion2k 10y ago
  "As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs." That's a good sign. As you get better and more experienced as developer you start to realise the benefit of thinking things through before launching in to writing code or reaching for an existing library. Some times you want to do the first, and other times you want to do the second. There isn't a straightforward "one size fits all" rule to say which approach is best.
- awinder 10y ago
  #2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost
_RPM 10y ago
Do you think this guy could pass the hazing rituals of bay area companies? Reverse this binary tree for me, that'll tell me if you're a good programmer.
- mortoray 10y ago
  I (the author) can certainly do the silly algorithm tests, but whether I can contain my snide remarks enough to get the job is uncertain. :)
  - _RPM 10y ago
    The funny thing is, when you're interviewing, your blog, open source projects, etc won't count. I know this might not seem real, but it's the truth.
- justinlardinois 10y ago
  Being asked to demonstrate knowledge of common algorithms is "hazing"?
  - _RPM 10y ago
    Yes, it's called hazing. You seem surprised and confused about this.
erikb 10y ago
Certainly a big problem of mine, or at least in the past. Just as the not-invented here syndrome people will eventually learn that there is good code out there, people like me, eventually learn that you need to code some modules yourself, and sometimes the 400 line if-else-for crap is exactly what is needed to just get a step further and realizing that the customer actually wanted another feature to begin with.
sigcode 10y ago
Example that comes to mind is libcurl. How many of the functions in the third party library are actually used in the program? What if some names conflicts with the name of a system function? (curl is exempt, but other examples are not as careful.) Solution: Link them all in anyway. Let someone else worry about it. ar x /usr/local/lib/libcurl.a nm libcurl_la-* |sed '/^$/d;/:/d' |wc -l 2443
bitwize 10y ago
Iron law of open source: you either use a solution with extensive community support, or you forge your own path, assuming total responsibility for maintenance and support of any code that comes from off the beaten track (whether developed in-house or not). For code that falls outside the company's core competency, is it any surprise why companies are more inclined to use an external library?
headcanon 10y ago
Naturally, like all engineering, its a balancing act with tradeoffs. We are responsible for all the code that runs in our application, but we are also responsible for shipping. It doesn't make sense in this day and age to write every line myself, but at the same time it is irresponsible to include buggy dependencies. One of the first things I do when asked to solve a problem or implement feature X is to check around to see if there is an existing solution. Its very likely that I will find something that at least is close to what I want, and from there I evaluate the library, and ask these questions: 1) how complex is the problem that this library solves? How difficult would it be to implement it in my app? 2) How close is this library to what I want? Is it easy to integrate or do I have to jump through a lot of hoops? 3) How bloated is the library? Do I have to include a bunch of stuff in the production build that I'm not using? (not always a problem depending on how the language imports libraries) 4) Is it well written? Is it actively maintained? Github stars and issue backlogs don't say everything but can provide good heuristics. 5) Do I expect that I will need to customize or optimize the underlying behavior in the future? Ultimately, I think the biggest question here is "Is the library working for me, or am I working for it?" If the latter, maybe its worth considering writing it yourself. It also depends on the language and ecosystem for me, not to mention individual libraries. I'm working with javascript primarily right now, and there are a lot of npm libraries that are so small it makes more sense to just copy/paste the code into a utility (after doing due diligence it of course) and iterating on top of it. But it doesn't make sense to rewrite, say, JQuery, or React. edit: grammar
alephnil 10y ago
In addition that the code you consider including should have high enough quality, it is also important to consider external dependencies. If the library require 35 external dependencies, it is likely to be a maintenance burden in the future, so you better avoid it. Otherwise you may end up in the situation where A upgrade to use version 2.0 API of library C, while library B continue to use version 1.3, and now you sudenly have a compatibility problem. Other factors can be if the library is hard to build, or is only for windows while your product is for windows, mac and linux. The real question is what will create the least maintenance burden in the future.
dqv 10y ago
I came to this realization when I had to make too many concessions to avoid reinventing the wheel. Between the huge list of dependencies and having to change a major part of how I do business, I decided to trade one "good enough" for another.
justinlardinois 10y ago
My first exposure to anything programming related was some web publishing courses I took at a community college when I was a teenager. The classes were intended for people with a graphic design, rather than developer bent, so the classes were mostly focused on HTML, CSS, and web design-relevant Photoshop tricks. I credit those classes with sparking my interest in programming, but they didn't actually cover it to any extent. Instead there was this attitude that you could just find a Javascript file or Perl CGI script that would do what you need, and when necessary you could shoehorn it in, despite having little to no understanding of the involved programming languages. GitHub didn't exist yet, so there wasn't a centralized, trustworthy source of free Javascript modules; instead you had to find them on sketchy ad-riddled sites and hope they did what they said they did. I remember there were even sites that would sell scripts, a concept that feels totally alien to me now in 2016. tl;dr Invented here syndrome is a big thing for web designers who aren't developers
Roboprog 10y ago
I think a related, contributing problem is an inability to create and describe abstractions. Time and again, I see projects where the developer(s) is/are unable to do anything beyond one line after another of calls into low level library primitives, or maybe filling up a bunch of directories named after design patterns which plug into a framework. Beyond that, though, and there seems to be a widespread inability to recognize repetition and then refactor it out, or to make layers to separate domain/business logic from low level details. Also, the fairy tale of "self documenting code" is widespread, vs say "literate programming", and even if many of your in-house staff made their own libraries, the interfaces would be hard to understand. It's amazing how the act of trying to document an interface forces you to keep it clean and orthogonal. Mixing developers with different "styles" (inline vs abstraction) is going to be frustrating for both extremes. I tend to agree with the author in his opinion, but much like "The Big Ball of Mud", you need to understand the forces that cause these patterns to emerge.
Pica_soO 10y ago
The library will seem to withstand a quick and dirty test on performance and scale-ability, and then collapse when near release production puts pressure on it. Then you will rewrite it, and to distribute the crunch, will do so from then on.

89 points by delian66 10y ago

dzhiurgis 10y ago

https://en.wikipedia.org/wiki/Inventor%27s_paradox https://en.wikipedia.org/wiki/Inventor%27s_paradox

deleted 10y ago

[deleted]

mamon 10y ago

One reason of "invented here syndrome" is proliferation of crappy developers. I've seen that many times in the companies are worked for (as senior dev / architect): the code that is required by some web framework or library is quite clean and well structured, code that is at core, business logic is a mess. Tell some junior to mid-level developer to write any significant piece of application and the host of bugs and NullPointerExceptions will follow. Finding a library for everything and only leaving simple gluing them together as a task for developers seems like the only way of ensuring minimum required code quality.

k__ 10y ago
The other extreme is people who end up with hundrets of deps in their project.
- ben-schaaf 10y ago
  'node_modules' can get quite scary
sgift 10y ago
If all they are allowed to do is gluing code together they will never learn and will never get better at anything than .. gluing code together. Sounds like a bad idea.
- mamon 10y ago
  Maybe part of the issue is that I personally never work as full-time employee. I'm more like consultant, hired on per-project basis, so training less experienced developers is neither in my job description nor in my schedule.
  - Nursie 10y ago
    I work as a consultant on a project-basis too. I would tend to consider training up of any permanent staff on the team to be part of my job. Perhaps not on basic technology, but certainly on what we're doing. That way, when I leave, there's still knowledge in house. This may seem to limit business opportunities, but I consider it part of a job well done.
- lmm 10y ago
  If gluing code together is sufficient to solve the business problem (and 99.9% of the time it is) then it's probably the most efficient thing to be doing, and absolutely what they should be focusing on.
awinder 10y ago
Invented here and not invented here are equal signatures of crappy developers, in my opinion. I'll admit there's some skill involved, sometimes, in the engineering efforts of the NIH minded developer. But I've also seen NIH developers insist on building things like CI servers, company wikis, and message queues. And none of them have even been tangentially better than the alternatives. They're both mindsets that speak to immaturity and lack of judgement, but man, I've seen way more of NIH than IH, and in a lot more business-destructive senses
ohnomrbill 10y ago
On the other hand, I've just been at a place where "invented here syndrome" masked crappy developers to the detriment of the business. One tester spent 3 days tracking down a simple python dependency bug - but in the meantime he was productive because Travis is so easy to set up, and his Ruby tests worked. Travis is definitely more appealing to me than maintaining my own Jenkins instance. But I can't help but feel that we would have caught this guy's crappiness much earlier if he had to set up his own Jenkins job instead of a travis.yml file.

V-2 10y ago

> Perhaps a library covers only 95% of the requirements 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often. If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. > Being available in a package manager, being downloaded by thousand of people, or having a fancy web page, are no indications of a good product. 1. Being used by thousands of people isn't by itself a guarantee that it's good, but it surely makes it more likely. 2. Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument.

wolfgke 10y ago
> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. Depending on the situation this can mean having to understand lots of gory details of the implementation of the library. It is often easier to write an own implementation from scratch than having to understand these details and subtile interactions. Typically "open source" just means that the source code is available under an OSI-compatible license and not that there is also a documentation available that guides you from barely understanding the library to understanding every implementation details that is necessary to do internal changes.
wtbob 10y ago
> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%. You're not wrong, but you are assuming some things: 1. That the library is written in a language suitable for the task. E.g. if you're doing real-time programming you probably don't want Visual Basic and if you're doing security programming or text processing you probably don't want C. 2. That the library is written well enough to read. You'd be amazed how much truly bad code is out there. It runs, but … it's not good. OpenSSL is an example. 3. That the library is architected in such a fashion that the 5% functionality can be added without major rework. The functionality may be small, but adding it might require quite a lot of architectural change and refactoring.
- 10y ago

whatever_dude 10y ago

I take a more selfish approach on this debate. I nearly always write my own code to do something, even when a library already exists... just so I can understand the problem well. Then, when I finally decide to use a specific library, I understand why they're doing something in a specific way more clearly. Maybe not the most advisable route for commercial work, but one that keeps me satisfied.

moron4hire 10y ago
You're going to need to understand how the system works regardless. So you can spend the time learning how the internals of someone else's library works, or you can learn how to solve the problem and write your own. In my experience, there is rarely a difference between the two. But when I write my own code, I know how to make it integrate with all my other code better.
morbidhawk 10y ago
I do the same thing all the time and I'm trying to break this habit since it might be holding me back. I'm trying to realize that I can learn a lot from someone else's work and by diving in and learning the ins and outs and even reading the library's source code I can learn a lot more than experimenting around trying to produce similar functionality myself. Reading code is far more tedious though than being able to creatively experiment with something. The creative learning is important I'm just trying to use it in other applications than re-inventing a wheel that already works well

imagist 10y ago

The longer I work, the more NIH I get. There are two reasons for this: 1. The ease of creating a library these days is resulting in a proliferation of utterly crap libraries, so bringing on a new library is more and more of a liability, both to future reusability of code and to security. 2. As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs. These combine to create a situation where I'm less and less likely to want to import something.

mortoray 10y ago
#1 has a big influence on my argument. I think it was Python and NodeJS library systems that made it super simple for people to publish libraries. There are a lot of trivial libraries out there, and many of questionable quality. Sometimes using a library ends up as more work than writing the bits of code myself. It's not like I'm going to decide to write a new 20k line library for my project, but if something is only a few hundred lines of code it's definitely easier to just rewrite.
onion2k 10y ago
"As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs." That's a good sign. As you get better and more experienced as developer you start to realise the benefit of thinking things through before launching in to writing code or reaching for an existing library. Some times you want to do the first, and other times you want to do the second. There isn't a straightforward "one size fits all" rule to say which approach is best.
awinder 10y ago
#2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote. And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost

_RPM 10y ago

Do you think this guy could pass the hazing rituals of bay area companies? Reverse this binary tree for me, that'll tell me if you're a good programmer.

mortoray 10y ago
I (the author) can certainly do the silly algorithm tests, but whether I can contain my snide remarks enough to get the job is uncertain. :)
- _RPM 10y ago
  The funny thing is, when you're interviewing, your blog, open source projects, etc won't count. I know this might not seem real, but it's the truth.
justinlardinois 10y ago
Being asked to demonstrate knowledge of common algorithms is "hazing"?
- _RPM 10y ago
  Yes, it's called hazing. You seem surprised and confused about this.

erikb 10y ago

Certainly a big problem of mine, or at least in the past. Just as the not-invented here syndrome people will eventually learn that there is good code out there, people like me, eventually learn that you need to code some modules yourself, and sometimes the 400 line if-else-for crap is exactly what is needed to just get a step further and realizing that the customer actually wanted another feature to begin with.

sigcode 10y ago

Example that comes to mind is libcurl. How many of the functions in the third party library are actually used in the program? What if some names conflicts with the name of a system function? (curl is exempt, but other examples are not as careful.) Solution: Link them all in anyway. Let someone else worry about it. ar x /usr/local/lib/libcurl.a nm libcurl_la-* |sed '/^$/d;/:/d' |wc -l 2443

bitwize 10y ago

Iron law of open source: you either use a solution with extensive community support, or you forge your own path, assuming total responsibility for maintenance and support of any code that comes from off the beaten track (whether developed in-house or not). For code that falls outside the company's core competency, is it any surprise why companies are more inclined to use an external library?

headcanon 10y ago

Naturally, like all engineering, its a balancing act with tradeoffs. We are responsible for all the code that runs in our application, but we are also responsible for shipping. It doesn't make sense in this day and age to write every line myself, but at the same time it is irresponsible to include buggy dependencies. One of the first things I do when asked to solve a problem or implement feature X is to check around to see if there is an existing solution. Its very likely that I will find something that at least is close to what I want, and from there I evaluate the library, and ask these questions: 1) how complex is the problem that this library solves? How difficult would it be to implement it in my app? 2) How close is this library to what I want? Is it easy to integrate or do I have to jump through a lot of hoops? 3) How bloated is the library? Do I have to include a bunch of stuff in the production build that I'm not using? (not always a problem depending on how the language imports libraries) 4) Is it well written? Is it actively maintained? Github stars and issue backlogs don't say everything but can provide good heuristics. 5) Do I expect that I will need to customize or optimize the underlying behavior in the future? Ultimately, I think the biggest question here is "Is the library working for me, or am I working for it?" If the latter, maybe its worth considering writing it yourself. It also depends on the language and ecosystem for me, not to mention individual libraries. I'm working with javascript primarily right now, and there are a lot of npm libraries that are so small it makes more sense to just copy/paste the code into a utility (after doing due diligence it of course) and iterating on top of it. But it doesn't make sense to rewrite, say, JQuery, or React. edit: grammar

alephnil 10y ago

In addition that the code you consider including should have high enough quality, it is also important to consider external dependencies. If the library require 35 external dependencies, it is likely to be a maintenance burden in the future, so you better avoid it. Otherwise you may end up in the situation where A upgrade to use version 2.0 API of library C, while library B continue to use version 1.3, and now you sudenly have a compatibility problem. Other factors can be if the library is hard to build, or is only for windows while your product is for windows, mac and linux. The real question is what will create the least maintenance burden in the future.

dqv 10y ago

I came to this realization when I had to make too many concessions to avoid reinventing the wheel. Between the huge list of dependencies and having to change a major part of how I do business, I decided to trade one "good enough" for another.

justinlardinois 10y ago

My first exposure to anything programming related was some web publishing courses I took at a community college when I was a teenager. The classes were intended for people with a graphic design, rather than developer bent, so the classes were mostly focused on HTML, CSS, and web design-relevant Photoshop tricks. I credit those classes with sparking my interest in programming, but they didn't actually cover it to any extent. Instead there was this attitude that you could just find a Javascript file or Perl CGI script that would do what you need, and when necessary you could shoehorn it in, despite having little to no understanding of the involved programming languages. GitHub didn't exist yet, so there wasn't a centralized, trustworthy source of free Javascript modules; instead you had to find them on sketchy ad-riddled sites and hope they did what they said they did. I remember there were even sites that would sell scripts, a concept that feels totally alien to me now in 2016. tl;dr Invented here syndrome is a big thing for web designers who aren't developers

Roboprog 10y ago

I think a related, contributing problem is an inability to create and describe abstractions. Time and again, I see projects where the developer(s) is/are unable to do anything beyond one line after another of calls into low level library primitives, or maybe filling up a bunch of directories named after design patterns which plug into a framework. Beyond that, though, and there seems to be a widespread inability to recognize repetition and then refactor it out, or to make layers to separate domain/business logic from low level details. Also, the fairy tale of "self documenting code" is widespread, vs say "literate programming", and even if many of your in-house staff made their own libraries, the interfaces would be hard to understand. It's amazing how the act of trying to document an interface forces you to keep it clean and orthogonal. Mixing developers with different "styles" (inline vs abstraction) is going to be frustrating for both extremes. I tend to agree with the author in his opinion, but much like "The Big Ball of Mud", you need to understand the forces that cause these patterns to emerge.

Pica_soO 10y ago

The library will seem to withstand a quick and dirty test on performance and scale-ability, and then collapse when near release production puts pressure on it. Then you will rewrite it, and to distribute the crunch, will do so from then on.