> This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours
This argument makes sense, but I worry that it’s a bit short-sighted. There are a lot of metrics that are hard to quantify where it might end up better: for one thing, I’ve found that integration costs and maintenance of integration of third-party systems are routinely underestimated: I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build. The cost of learning a proprietary toolset rather than developing experience with open tools. The cost to the industry as a whole when something like AWS or React becomes the unreflective default choice.
Its extremely short sighted. The cost is much more than (hourly wage x code hours).
There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.
There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.
Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.
When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.
Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.
> When you buy, the tools you buy are designed to be integrated with[...]
This makes me question if you're speaking theoretical, or actually have any practical experience.
I've been part of about a dozen "buy it" projects now, and so rarely they've been "designed to be integrated with. A lot of the time it's deeply legacy systems that have a half-hearted api slapped on top to check that box, but once you start using it you notice that everything you want to do somehow requires contacting the vendor first.
Which dovetails into an issue that, although vendors will give you the impression that their system is well tested and widely deployed, it all too often ends up being a lie. We've had quite a few instances where vendors have sold us what turned out to be something they were still building.
> the tools you buy are designed to be integrated with.
Until they change on a whim and force you to spend hours rebuilding your integration for negligible benefits. And then there’s the good old “change our vendors every five minutes because the last one wasn’t quite right”
If your company isn’t making money from the product then whoever owns the copyright is irrelevant.
Good engineering is building the stuff that adds commercial value to the business and buying the stuff that only adds support to the stuff that adds commercial value.
In this instance, monitoring falls into the latter category. It’s not a business differentiator.
Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.
The integration costs were part of the 40 hours. The trouble is you haven't avoided them by paying the money.
Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.
And the open tools often end up with more transferable skills down the road: e.g. learning to deploy to AWS only helps with AWS; learning to deploy to k8s lets you be productive in a lot more situations.
> I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build
I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.
Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.
Sure it’s shortsighted, but we’re all shortsighted, that’s the human condition. We can’t know all ends, which is why experience and judgement matter. The worst thing you could do is handwring over it though. Gather whatever data you can quickly leveraging the extent of your current expertise, make a call, implement and learn.
This argument makes sense, but I worry that it’s a bit short-sighted. There are a lot of metrics that are hard to quantify where it might end up better: for one thing, I’ve found that integration costs and maintenance of integration of third-party systems are routinely underestimated: I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build. The cost of learning a proprietary toolset rather than developing experience with open tools. The cost to the industry as a whole when something like AWS or React becomes the unreflective default choice.