3 ms·

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

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

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

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