3 ms·

> companies may stop naively believing engineers who say they can build what a vendor is offering in 2 weeks I love to build tools out rather than buy tools, b

> companies may stop naively believing engineers who say they can build what a vendor is offering in 2 weeks I love to build tools out rather than buy tools, but it's not for the resume line item, and it's not for the love of development (I'm not actually a software dev, I'm infosec). I prefer to implement tools internally, when feasible, because it makes them more likely to be understood and utilized. 80% of the functionality in 90% of the tools we buy is un-utilized or under-utilized. We are constantly having vendors or tool owners offering training credits for us to learn the unnecessary bells and whistles of the tool they spent too much money on. In contrast, the tools we build have no unnecessary features. No key functions that are *future roadmap items* for a vendor. No black-box processes that we can only shrug when asked what it's doing or how, because it's 'proprietary' secret sauce for the vendor. Now, do most of those tools merit their own business? Not at all, and we don't try to sell them, but many of them would make great open-source projects. Just because something would not generate money, does not mean it's not a good and worthwhile project.

rcxdude 3y ago
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.
- convolvatron 3y ago
  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?
  - jamesfinlayson 3y ago
    Or the inevitable migration to another tool because the current off-the-shelf solution is now too expensive/has been relicensed/whatever.
- kageiit 3y ago
  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.
- bostik 3y ago
  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.
mdorazio 3y ago
Do you also love to maintain the tools you build? That's at least half the reason you buy instead of build.
- ang_cire 3y ago
  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.
- unlikelytomato 3y ago
  As long as someone also accounts for the cost to maintain a business relationship with the vendor. This has not been my experience.
- jpgvm 3y ago
  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.
clwg 3y ago
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.
nitwit005 3y ago
> 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.
englishspot 3y ago
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.
mrweasel 3y ago
> 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.
- PH95VuimJjqBqy 3y ago
  > 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.
- ang_cire 3y ago

rcxdude 3y ago

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.

convolvatron 3y ago
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?
- jamesfinlayson 3y ago
  Or the inevitable migration to another tool because the current off-the-shelf solution is now too expensive/has been relicensed/whatever.
kageiit 3y ago
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.
bostik 3y ago
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.

mdorazio 3y ago

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

ang_cire 3y ago
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.
unlikelytomato 3y ago
As long as someone also accounts for the cost to maintain a business relationship with the vendor. This has not been my experience.
jpgvm 3y ago
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.

clwg 3y ago

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.

nitwit005 3y ago

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

englishspot 3y ago

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.

mrweasel 3y ago

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

PH95VuimJjqBqy 3y ago
> 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.
ang_cire 3y ago