Hacker News Reader

I do feel that often the cost of integration in the 'buy' solution is often overlooked: there are many fantastically expensive products you can buy which will do almost anything you can imagine, if you spend the time and effort to figure out the platform and 'configure it how you want ' (where configuring requires a software engineer because it's varying degrees of disguised programming) . It's very easy to spend more time and money doing this than an in-house solution would.

don't forget maintenance. that's often a point made against internal tooling, but when was the last forced upgrade you had to do because an internal tool just doesn't support the old environment anymore?

Or the inevitable migration to another tool because the current off-the-shelf solution is now too expensive/has been relicensed/whatever.

I was leading such a team at previous employer focused on building integrating various tools to turn this tool soup into something palatable.

The main challenge is the increasing complexity of software and processes that necessitate such tools as the engineering team grows. Usually teams building internal tools are seen as cost centers and don't get the same funding as product teams which eventually leads to teams buying more than build to save on future maintenance.

I've been saying this for more than TWO DECADES: the entire "build vs. buy" is a false premise. There is no such thing as "buy".

There is "build", and then there is "buy and build". Without the proper integrations and customisations, any tool you have bought is just one more (possibly worse than) useless line item in your budget.

> because it makes them more likely to be understood and utilized

So my take is that this is mostly wrong, unless your organization is really good at maintenance, documentation and training.

Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood. Relying on internally developed tools put you at risk, because what frequently happens is that only a few people know how to maintain and develop for your internal thing. Maybe that's their job, but mostly it's not, it's something that happens on the side.

We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution, saving us from having 10 small home grown and distinct solutions. Sure, there would be features we didn't need, but we'd get security updates and be able to throw out tons of boiler plate code. Some people just love coding and will see any problem as an excuse to write a new tool, only to abandon it once some new problem catches their eye and then the rest of us are stuck with their abomination.

Another tools of ours was developed to avoid providing training on a open source tool. So now we have a wrapper the ensures that "the process" is always done safely. No new features are added, so people spend unnecessary time fighting a tool, trying to make it do things it doesn't want to do. All because nobody wanted to create the required training material. Actual documentation on the wrapper is so severely limited that new hires have zero chance of actually using it to do anything remotely complex.

There can be really good reasons for developing an internal tool, but those better be damn good reasons and the organization must be able to bear the cost, most aren't.

> Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood.

Not been my experience at all. The business people absolutely know that tool inside and out, just because your development teams have high turnover doesn't mean that tool hasn't been taught to everyone who uses the software.

In fact, my experience is that when a bug is introduced unknowingly the business side can describe you very concretely what it used to do and what they want it to do.

> We have a series of home grown tools and most are terrible. Some of them could easily be written as plugins for an open source solution

I would also consider self-hosted FOSS tools under the "build" category rather than "buy", so I would have no objection to using those versus re-building an available FOSS tool yourself. It's OSS, so you have the code, so you know what it's doing and how. It's self-hosted, so you aren't reliant on a vendor. It's (hopefully) free, so no vendor is trying to sell you on a module you don't need.

> Internal tools are terrible in the sense that there's no knowledge base to pull from, beyond internal. This limits the chance of the tools actually being use or even understood.

I think the key question here is, "who is using the internal tool?" To my mind, this is about teams building the tools THEY need, so it is nigh impossible to develop the tool but not understand it. You're not handing it off to another team, you built it because YOU need it. There can absolutely be abysmal documentation, but not having documentation and not looking at extant and extensive documentation is functionally equal, and the latter is by far the default state of tool use.

Your comment sounds as though in your mind some team is being mandated to build a tool for another team, against that other team's wishes. Is that internal to the company? Sure. Is it self-rolled? Not if the people using it didn't make it them*selves*. In that case it's really just a vendor tool, but the vendor is much less invested in the tool.

Being able to contextualize your security tooling to the code level is such an underrated capability of an effective security program/team.

It also allows you to leverage open-source tooling much more effectively.

The biggest problem is your setting a bar for capabilities that allot of infosec people don't have, so you need to consider the ability to manage a custom security code base into the future, which can cause issues if it's not considered properly for the environment your doing it in.

Do you also love to maintain the tools you build? That's at least half the reason you buy instead of build.

As long as someone also accounts for the cost to maintain a business relationship with the vendor. This has not been my experience.

Maintenance is easy if you don't suck at retention. As much as engineers like to build they also really enjoy gardening.

The only compelling argument I have heard for buy over build is "well, our engineers keep leaving". Yeah, because you are terrible at managing them - so no shit they leave.

A competently managed technical team has some natural attrition but the rates of turnover I see in a lot of companies that push this ethos is far beyond normal or healthy.

All software becomes "legacy" in short order if you are constantly hemorrhaging tribal knowledge and skills.

Yes, of course. I know some people want to build something and then hand it off, but personally I love to actually use and improve the tools I make.

Even with my personal projects, I find myself going back to my old projects and adding stuff to them, much more often than I find myself starting brand new ones.

> 80% of the functionality in 90% of the tools we buy is un-utilized or under-utilized.

And they want you to pay for the unused parts. It's frequent that products seem brutally expensive as a result.

in addition, vendors tend to build things for a large variety of environments, and not just your specific use case. so new features would require more thought and consideration than an internal implementation for your company's specific environment.

that said, I think if what a vendor provides checks every box for your use case, buy is probably better than build.