4 ms·
They're a potential indicator for NIH syndrome. Good, well developed internal tools which speed up company work in a way that something off the shelf cannot, c
by MaulingMonkey 13y ago
They're a potential indicator for NIH syndrome.
Good, well developed internal tools which speed up company work in a way that something off the shelf cannot, can be a good thing. Even the best internal tools, however, will require some ramp-up time for someone joining the company to understand and use them to their full potential. They require developing in the first place. The gains must be able to justify the costs, which even a good tool cannot always do due to the limited consumer base of an internal tool.
In less ideal circumstances, they can be unholy buggy unsustainable messes that actively sap resources for maintenance and are worse in many if not all respects than cheap off-the-shelf alternatives, even for the company's own specific needs. They may be kept alive by the difficulty of transitioning, other internal tools depending upon it, or misplaced attachments to the system ("we've invested too much into it to switch now!" etc.) or misguided approach to tools in general ("licenses are expensive, let's just build our own.")
- philwelch 13y agoFor larger companies, internal tools become absolutely essential.
- MaulingMonkey 13y agoEven in smaller companies, some custom internal tools can be essential. Even in my own personal use, some custom tools can be useful or essential. But a large company probably has at least one unessential tool meeting a need better filled by something off the shelf, just by a matter of statistics. There can be all sorts of legitimate reasons this happened other than NIH Syndrome (it predated the off-the-shelf solution, it couldn't be found despite research, regulatory requirements, etc.) but NIH Syndrome is one to watch out for.
- quanticle 13y agoIt depends. Internal tools that are specialized for the industry or a specific business process at that company are probably fine and necessary. But I've seen many instances where a developer or manager gunning for a promotion writes yet another build server, deployment system, content management system or what have you just to have a "trademark" project that they can take credit for. It's that sort of internal tool which one should be very wary of, since they tend to get deprioritized but not abandoned. That is to say, once the person who championed that tool has received their reward, their continuing priority is to ensure that the tool sticks around (so that they're not blamed later for writing a tool that was later abandoned) but not necessarily to improve the tool on an ongoing basis. You want to stay away from situations like that, because you'll be assigned with fixing issues and putting out fires as they arise, but you won't be given the resources to properly refactor the tool to ensure that issues never arise in the first place.
- philwelch 13y agoAbandonware is never fun to work with, but I've seen internal build and deployment tools that are (a) actively maintained and (b) so good that former employees pine for them when they leave the company.