6 ms·
An interesting outgrowth of NIH, including and especially places where the choice is defensible (as in the article), is that quite often the external dependency
by ubermonkey 4y ago
An interesting outgrowth of NIH, including and especially places where the choice is defensible (as in the article), is that quite often the external dependency universe evolves or changes sufficiently to put you at a material disadvantage for not participating.
I worked somewhere in the 90s that had built its own database infrastructure to meet business requirements that existed in the early/mid 80s. If you set out to build the same system in 1995 that they'd built before, you absolutely would NOT use the same approach, but they plodded along with a mishmash of internally developed tech for a long, long time -- long enough that it really hurt them. And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases.
It got hard to hire anybody but fresh kids, most of whom would split after 12-24 months.
So even if you do build your own C compiler or whatever, you have to keep an eye out for offramps to that internal dependency if the realities around your product or project change. In this sense, your internal dependency is no different than an external one -- you've always got to be looking for an alternative even if you're perfectly happy with the current path, because the current path might stop being viable.
- yen223 4y agoThis applies to choosing external dependencies as well. Startups that chose FlowTypes over Typescript are struggling right now.
- hamandcheese 4y agoWhat Flow lacks in community adoption, it makes up for in speed for a large codebase. Not feeling much pain yet (though I am worried about it).
- deleted 4y ago[deleted]
- brundolf 4y agoLike everything, it depends, but yeah- "hitching your cart to a rocketship" is an important class of situation where it may be good to integrate with a dependency
- FrojoS 4y ago[flagged]
- qotgalaxy 4y ago[dead]
- theamk 4y agoI think this a great example of why people don't like ChatGPT. Here is a certain-sounding comment, which took me some time to read and verify. But Google search showed this post: https://www.houstonnwchamber.org/the-legacy-of-compaq/ https://www.houstonnwchamber.org/the-legacy-of-compaq/ which mentions > “California-style” campus in the trees along Cypress Creek ... in the outer suburbs of northwest Houston google maps easily finds Cypress Creek, and it is really in northwest Houston, and it is 25 miles away from "5251 Westheimer Road, Houston TX", nowhere close. Looks like ChatGPT was completely wrong. And those who claim that "but people will know ChatGPT can make mistakes, users will verify"... well, here is a counter-example, ChatGPT junk directly to comment field.
- runnerup 4y agoCompaq has moved a few times since 1995 and being absorbed by another megacorp.
- ubermonkey 4y agoBut, to be clear, was absolutely never at 5251 Westheimer. Nor, to the best of my knowledge, were any software companies or restaurants or retail. It's an office building that was primarily leased by my former employer, which another commenter correctly noted was TeleCheck.
- forevergreenyon 4y ago[flagged]
- InitialLastName 4y agoHas dang ever ruled on the appropriateness of this situation, where someone just redirects AI-generated output to their comment (absent any evaluative substance and on a digression from a digression fully unrelated to the discussion of AI)? It strikes me as a bad-faith way to farm for low-effort internet points, but I'm just some idiot on the internet so I'll have to satisfy myself with a down-vote, a mild complaint, and a minute or two of wasted time.
- quanticle 4y agoI had a similar experience working for a company that had, essentially, developed their own in-house web templating language and programming system. They'd started before PHP or any of the other server-side programming languages had caught on, and while a decision to use a homebrew system may have been justifiable in the '90s, when the only real alternative was Perl/Mason, by the time I joined (2009), it was long overdue for them to have moved on to an industry-standard solution. PHP. Python/Django. Ruby/Rails. Even classic ASP would have been preferable to the mess of C++ and XML they were using. Frankly, I think the article, like a lot of Joel Spolsky's writing, has aged like milk. For example: If you’re developing a computer game where the plot is your competitive advantage, it’s OK to use a third party 3D library. But if cool 3D effects are going to be your distinguishing feature, you had better roll your own. Except, if you look at modern games, even ones with very high performance effects, that's not what they do. They use one of a rather small number of 3D engines, like Unreal or Frostbite. It turns out that developing cool 3D effects is far easier if you have a battle-tested performance optimized framework helping you. CD Projeckt Red abandoned its own in-house engine (REDengine) in favor Unreal 5 for future development, in no small part due to the issues that they ran into trying to extend that engine for a massive open-world game like Cyberpunk 2077.
- Sebb767 4y agoWhat changed is that 3D effects are no longer a distinguishing feature for games. By now, all modern AAAs look stunning, super-realistic is not as much of a selling point. Instead, you point with art, content and game play, most of which is very much developed in house. The short version of the article is "don't outsource your core competency" and that very much holds true today.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- dgb23 4y agoCyberpunk 2077 seems to be a very standard AAA game in terms of both gameplay and looks. It makes sense to use an established, popular engine there. It's also a perfect example of yet another somewhat forgettable experience. Factorio or The Witness might be better examples of games that did/are doing novel, exceptional things and their engines were developed in-house. And it shows. The unique look and feel, the smoothness, depth, coherency etc. The comparison is maybe unfair though. We're basically comparing a product focus with an art focus. Artists _must_ do things their way. Risk and cost are secondary. Success is a bonus. In a more survival oriented world you have to weigh these things differently. What you describe above seems more like a problem with clinging to legacy and missing the world around them rather than developing things in-house. It should be obvious, but the thing you do in-house has to provide you unique advantages over the main-stream. That comes with costs and only works if you have the stomach to be honest with yourself.
- m463 4y agohe said - your core business - does infrastructure count?
- civilized 4y agoI've seen internal dependencies come to be so poorly understood that they might as well be external.
- Drive-by 4y ago> 5251 Westheimer (<-- if you know, you know) Is TeleCheck really all that mysterious?
- ubermonkey 4y agoNot to you. ;) When were you there?
- xmcqdpt2 4y ago> And the first place that this damage showed up was in personnel. To be productive there, you had to know a ton about the internal tools that existed ONLY at 5251 Westheimer (<-- if you know, you know), which meant those skills were useless in the marketplace that was rapidly moving towards open-standards based development, etc., or at least using commercial databases. The other side of the coin here is that a team with some NIH code (if it is well engineered, modern, maybe open sourced or on its way to open sourcing) can use it to attract and retain certain engineers who might want to eg work on building a database or a compiler. Now of course it's a pretty fine balance but I've worked at one non tech company that had basically no internal software projects whatsoever, and their engineering culture was abysmal. I think in that case they couldn't have made good software anyway but the fact that everything they did was pieced together from a handful of commercial vendors meant that there was no interesting code to write at all! For example, we were encouraged to report bugs to upstream paid support but never attempt to fix them, because they didn't want to deal with internal versions of software or open source licensing. I didn't stay for very long. It's a balancing act and the balance is different based on the size of the companies and the specific product.