Article felt more like "not buy", not "build vs buy".
I just spent an afternoon helping someone to get us to run on-prem. Phone calls! Installs! Vendor management! We didn't even setup TLS b/c gov stuff is complicated! Working with vendor software is so painful!
Except they were originally thinking they'd have to build what we've spent years not only building, but building as GPU / data / etc. specialists, and we've already adopted many best practices for stuff like TLS and navigated other gov systems for them. (It can still be way better, but imagine if you had none of that stuff, and then had to support it!). Even ignore how we're special -- GPUs are magical if you use them right -- just that we have basic stuff built in and with on-going support. That's so key and adds up over the years. We do it for our graph investigation niche, but same deal for almost everything.
As software has matured, and I see more and more orgs dealing with the reality that they're not Google nor Stripe with thousands of the best-paid software engineers, I'm convinced articles should be explaining from the default of "not build".
In my less charitable moods, I'm inclined to say that you're unlikely to find a whole lot of software developers saying you should build less software for the same reason I've never met a real estate agent who's really on board with my desire to stick to a more modest living situation.
Besides, building in house is inherently more fun. What would you rather do, write new software, or pore over manuals for software that someone else wrote? For my part, there's a reason I became a programmer and not a tech writer.
Yep! I find that working with management involves planning through outcomes and general resourcing, while working with developers and engineering managers involves planning through the cooler stuff they get to do. ("Instead of reimplmenting some JavaScript UI and Python backend thing for the nth+1 time, we'll zip ahead to the GPU era and focus more time on the data engineering and data science and visual analytics side...")
Folks don't get recognized as heroes for not doing anything, but when they drive the greater story, everyone wins. Understanding the individuals involved in successful software delivery is so important!
There is so much stuff to build that to pass up an opportunity to build something everyone is building is no big deal. As TFA says: focus on the business, build to its core competency, buy the rest if you can (you can't always).
I just spent an afternoon helping someone to get us to run on-prem. Phone calls! Installs! Vendor management! We didn't even setup TLS b/c gov stuff is complicated! Working with vendor software is so painful!
Except they were originally thinking they'd have to build what we've spent years not only building, but building as GPU / data / etc. specialists, and we've already adopted many best practices for stuff like TLS and navigated other gov systems for them. (It can still be way better, but imagine if you had none of that stuff, and then had to support it!). Even ignore how we're special -- GPUs are magical if you use them right -- just that we have basic stuff built in and with on-going support. That's so key and adds up over the years. We do it for our graph investigation niche, but same deal for almost everything.
As software has matured, and I see more and more orgs dealing with the reality that they're not Google nor Stripe with thousands of the best-paid software engineers, I'm convinced articles should be explaining from the default of "not build".