Read on Twitter
1/ If you're a software or SaaS company (especially a startup!) that isn't Facebook, Apple, Amazon, Netflix or Google, it's very likely that the highest and best use of your engineering resources is working on the products customers are paying you for and not ops tools.
2/ When I worked there, Microsoft very much had a "not invented here" syndrome. You almost *had* to use Microsoft products. The hardest thing at the company to buy was software. People twisted themselves into knots to use Microsoft products. It's probably why PhotoDraw existed.
3/ So, all sorts of effort and energy--from objectively some of the best developers in the world--went into coding solutions for solved problems. Some of those turned into products. Others turned into critical internal infrastructure running on Joe Developer's side project.
4/ I get it. I really do. You're scaling really fast and there is a specialized thing you'd like to do that third party solutions don't support well and third party tools are expensive ("Just look at our Splunk bill!") and and and. That's STILL not a good reason to build it.
5/ The problem is that as good as writing the tool internally would solve the problem in front of you today, you're going to scale into different problems that require additional development effort to solve. And by then, you've created dependencies on your internal tooling.
6/ So as you scale up, you end up having to scale your internal tools teams. Joe Developer's side project is 3 full time developer heads plus a QA team and it touches PII so security reviews are required and--well, you get the point. It never ends. You just spend more and more.
7/ Or worse, some critical thing is running on the ancient server in the lab that the lab techs call "the coffee grinder" because of the noise the fans are making with a sticky note on it that says "DO NOT TURN OFF" and nobody knows what it's running or why until it dies one day.
8/ Oh, that machine was the code signing server whipped up by Bob as a side project except Bob had a heart attack and died last year. That's why you haven't seen him in the lab for awhile. Nobody knows how it works or where the code is. So the lab team somehow resurrects the box.
9/ Yes, paying Splunk 10 million dollars a year or whatever they charge is expensive and when you write the check, you should think "I can't believe that it's so cheap" because when your engineering team is focused on YOUR product, it's the highest leverage thing they can do.
10/ First principle, ask yourself "Does being in this business enhance the value of our core business? Is the highest impact code our team can write to delight our customers this piece of internal engineering?" If the answer is "no" to either of these, BUY IT. Don't build it!
