> 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 5

> 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.