3 ms·

The caveat here is in the "if your team is competent", and, as much as I love some of the people I worked with, their code can be downright horrible. Sure, they

The caveat here is in the "if your team is competent", and, as much as I love some of the people I worked with, their code can be downright horrible. Sure, they write good code in language ABC, but not in language CDE, but insist that they do. Or maybe they write great code, but no documentation. Maybe they even write good code, and a lot of it, and then leave. And suddenly, you have to not only find someone who - can read the code, and - is good at this technology, and - has the domain specific knowledge to work on it, but also someone who will be part of your team. Further, NIH only works out well when youre not under strong pressure. Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are.

ramesh31 4y ago
> Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are. It can go both ways though. You have the opposite of NIH, and say "there's no way in hell I have time to build this", so you pull in some huge unwieldy library that mostly solves the problem, and end up spending more time jamming a circle into a square hole and plugging up the gaps than you would have spent just solving the problem.
- brundolf 4y ago
  Yeah. Usually the cost of adding a dependency is over the long-run, so it disappears in the near-term decision making, but sometimes it's so significant it shows up in the near-term. It's good to notice when that's going to be the case and point it out to those applying the pressure, because that will be in a language they'll hopefully understand
- rqtwteye 4y ago
  You see that a lot with some enterprise software. They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality.
  - vsareto 4y ago
    >They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality. This is a good time to push back on requirements unless there's real money waiting to pay for that feature. Usually things are not completely established up front, so you never have a good picture of things you're going to have to build with some dependency. In these situations, your choice of software and how well it supports future features may as well be a dice roll.
    - ramesh31 4y ago
      >In these situations, your choice of software and how well it supports future features may as well be a dice roll. It's definitely a judgement call, and that's where having the experience to make that call correctly can save a ton of headache down the road. Some times YJGWI (You Just Gotta Write It).
- deterministic 4y ago
  Yep. This always happens in my experience. Or there is a bug fix or feature you badly need and it will never happen for various BS reasons. So now you either have to rip out the dependency and start all over or start maintaining a massive pile of garbage software that you didn’t even write (assuming you can even get access to the code).
toast0 4y ago
> The caveat here is in the "if your team is competent", Maybe it's from a place of privilege, but I have no interest in working where the team is not competent. But, even if your team is incompetent, there's no guarantee of competence of the people who wrote the dependency you use instead of building it yourself. Most of the time, I'd rather deal with local incompetence than remote incompetence. At the end of the day, if you want your project to work, you're responsible for the whole thing, include the dependencies you outsourced to others.
- lionkor 4y ago
  That's a very fair point. > there's no guarantee of competence of the people who wrote the dependency This is, in my opinion, the best reason to build stuff in-house. Thank you!
deterministic 4y ago
What makes you think that developers writing Commercial or Open Source libraries that you depend on are any better? Most software code is pretty bad. There aren’t many good developers out there. I would guess one in 20 maybe (30+ years of experience working for software companies in 5 countries).

ramesh31 4y ago

> Someone tells you to build XYZ, and you have NIH syndrome and build dependencies yourself, you will do so under a lot of time pressure, and it will be shit no matter how good you are. It can go both ways though. You have the opposite of NIH, and say "there's no way in hell I have time to build this", so you pull in some huge unwieldy library that mostly solves the problem, and end up spending more time jamming a circle into a square hole and plugging up the gaps than you would have spent just solving the problem.

brundolf 4y ago
Yeah. Usually the cost of adding a dependency is over the long-run, so it disappears in the near-term decision making, but sometimes it's so significant it shows up in the near-term. It's good to notice when that's going to be the case and point it out to those applying the pressure, because that will be in a language they'll hopefully understand
rqtwteye 4y ago
You see that a lot with some enterprise software. They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality.
- vsareto 4y ago
  >They get you started quickly but then you spend enormous amounts of time and energy customizing it to achieve the last few percent of functionality. This is a good time to push back on requirements unless there's real money waiting to pay for that feature. Usually things are not completely established up front, so you never have a good picture of things you're going to have to build with some dependency. In these situations, your choice of software and how well it supports future features may as well be a dice roll.
  - ramesh31 4y ago
    >In these situations, your choice of software and how well it supports future features may as well be a dice roll. It's definitely a judgement call, and that's where having the experience to make that call correctly can save a ton of headache down the road. Some times YJGWI (You Just Gotta Write It).
deterministic 4y ago
Yep. This always happens in my experience. Or there is a bug fix or feature you badly need and it will never happen for various BS reasons. So now you either have to rip out the dependency and start all over or start maintaining a massive pile of garbage software that you didn’t even write (assuming you can even get access to the code).

toast0 4y ago

> The caveat here is in the "if your team is competent", Maybe it's from a place of privilege, but I have no interest in working where the team is not competent. But, even if your team is incompetent, there's no guarantee of competence of the people who wrote the dependency you use instead of building it yourself. Most of the time, I'd rather deal with local incompetence than remote incompetence. At the end of the day, if you want your project to work, you're responsible for the whole thing, include the dependencies you outsourced to others.

lionkor 4y ago
That's a very fair point. > there's no guarantee of competence of the people who wrote the dependency This is, in my opinion, the best reason to build stuff in-house. Thank you!

deterministic 4y ago

What makes you think that developers writing Commercial or Open Source libraries that you depend on are any better? Most software code is pretty bad. There aren’t many good developers out there. I would guess one in 20 maybe (30+ years of experience working for software companies in 5 countries).