If you're an engineer in a larger software organization, you probably don't have that spending authority. Which means you have to spend time convincing the people with that authority to spend that money.
That's enough of a friction point that many engineers won't bother - which is why I talk about the invisible cultural damage that this problem causes.
You and I know that it will be cheaper. The challenge is getting organizational buy-in.
Certainly a problem, but the time you’d need to spend convincing higher ups is still trivial compared to the time you’d need to spend to build, maintain, and update the tool.
>the time you’d need to spend convincing higher ups is still trivial
From this sentence alone I'm not sure how much time you spent working for a large company.
It's not just that you have to convince your manager, depending on how much is to be spent they have to convince theirs. Often creating very long decision paths.
And it's not only the time you spent but sometimes also the delay incurred that messes with this approach. Often enough even with buy in you get the answer that it can be planned for next year's budget.
One year delay later, you might get the approval, but it may be too late.
And if the company is large enough often they've already built a subpar internal solution that everyone is convinced you should use. Since it's "already working".
> Certainly a problem, but the time you’d need to spend convincing higher ups is still trivial compared to the time you’d need to spend to build, maintain, and update the tool.
The amount of bureaucracy at large companies cannot be overstated, especially when technology is a cost or auxiliary to the core business.
I’ve run into this twice in my 24 year (!! good god, am I that old??) career.
The worst was during a several month consulting gig for an investment bank, and it was extremely painful.
Every change to the dev and uat environments required sign-off and approval, from sys admins who were in a different timezone.
If the changes had cost implications, it would have been far worse.
In larger organizations budgets are complicated things. Your higher up with spending authority may agree with you, but they've hit the budget for their group and so your request for more logging is competing with a request to pay for a new compliance auditing tools or upgraded server capacity for machine learning models.
I'm certainly not arguing build over buy here - but this challenge is a genuine issue which I don't think gets enough consideration.
If you're an engineer in a larger software organization, you probably don't have that spending authority. Which means you have to spend time convincing the people with that authority to spend that money.
That's enough of a friction point that many engineers won't bother - which is why I talk about the invisible cultural damage that this problem causes.
You and I know that it will be cheaper. The challenge is getting organizational buy-in.