Hacker News new | comments | ask | show | jobs | submit login

I don't quite get why internal tools are listed as "beware of". Internal tools are products too. At game companies they have teams dedicated to building just them. I'm sure most larger companies do too.

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

For larger companies, internal tools become absolutely essential.

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

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

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

Because you will end up investing a lot of time learning skills that don't transfer anywhere else.

Two of the last three companies I've worked at had their own internal version control systems. I'm sick of having to learn how to check code in all over again every time I start a new job.

Yeah. This is one place where startups have a distinct advantage over established firms. Established firms tend to have home-grown build and deployment systems, either because they started writing code before open source versions of those systems became available or because of straight up NIH. Startups, on the other hand, aren't big enough to tolerate that kind of wastefulness. They use as much open-source and standardized software as possible, simply because they don't have the time or manpower to write non-business code.

The last company I worked at had one. How bad of a sign this is depends on when it was developed and why. Theirs was developed in the early days of VCS, when none of the off-the-shelf systems had the feature set that they needed. Probably they kept using it longer than they should have, I suppose out of inertia, but they were in the process of moving away when I left. In that situation, it isn't too bad of a sign.

On the other hand, if you ever find a company that wrote their own VCS 3 years ago that has half the features of Git, then run far and run fast!

Indeed; according to this author, the guys at Naughty Dog were "awful" (writing their own compiler) during a period where I would have killed to work with them.

Well, there really is a difference between people who are reinventing wheels for good (because they really know their shit) and people who are doing it out of ignorance.

I think it's usually fairly easy to tell which person is which. (Person is either a bullshitter you can quickly catch out, or is smart and inspiring to talk to).

Yes, that point definitely should have been qualified better. If the new tool is much better than preexisting ones in important ways, it probably isn't a waste of time, and it could very well be a key asset.

But he does have a point in that the majority of rewrites are not significant improvements; you have to look more closely to evaluate this.

Their answer should be combined with the size of their organistion. Pretend, someone like google has their own internally developed web server. It makes sense, they have the manpower and the need. But when a 10 person tech team has their own internally developed bug tracker for no real reason, that's something to worry about.

I think they're definitely "beware of" if it's the answer to "what's the coolest thing you've produced?" Unless, like you said, it's an interview for a position in a large company that's dedicated to building internal tools.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact