4 ms·

I will say that avoiding "builder culture" probably saved my job. I joined a company that had migrated from an open source identity management solution to a ho

I will say that avoiding "builder culture" probably saved my job. I joined a company that had migrated from an open source identity management solution to a homegrown one and it had ran perfectly well in production for many years but was getting creaky and didn't offer the features that were needed for a SaaS offering. VPs gave me the option of determining whether we migrated to an identity vendor or built our own. I've contributed code to popular OIDC implementations on GitHub, I've written code in widely used open source JWT libraries and I felt extremely comfortable working in that space so my inclination was towards building. The problem was to staff a quality engineering team was going to cost 5x the yearly price of the most expensive service and hiring other people in that space was proving to be very difficult and we didn't have time to take a year to build it and then start migration In the end I chose to go with a vendor and a smaller team to support a migration. We migrated in less than 6 months and a year later we ended up getting contacted by law enforcement about some activity that was happening our system. The auditing system on the vendors side allowed us to quickly diagnose what exactly had happened and let us give data to folks who needed it. Had that been our homegrown system, it would've been 100% an unmitigated disaster that took days to unravel. Had we decided to build it ourselves, there's no way we could've hit production as quickly as we did.

jimktrains2 5y ago
It really depends on how well the offering matches the need. My personal experience is that outsourcing core bits where vendors don't match exactly the needs ends up causing more overhead that if we had written the service ourselves.
cloverich 5y ago
One unwritten trade off that's in addition, not a knock on your stance just an observation, is that teams that build one quality product can often build another. To some extent when you choose to build you are also choosing to build a culture that knows how to build. So you have to think about not just the next thing you need, but the five things after that. I've worked at companies that bought literally everything, and what I found is the engineers there knew a lot about how to plugin to these various systems, but when they needed to build something complex together they weren't able to do so very well, or at all. Which might be fine, but you should head in that direction with intention.

jimktrains2 5y ago

It really depends on how well the offering matches the need. My personal experience is that outsourcing core bits where vendors don't match exactly the needs ends up causing more overhead that if we had written the service ourselves.

cloverich 5y ago

One unwritten trade off that's in addition, not a knock on your stance just an observation, is that teams that build one quality product can often build another. To some extent when you choose to build you are also choosing to build a culture that knows how to build. So you have to think about not just the next thing you need, but the five things after that. I've worked at companies that bought literally everything, and what I found is the engineers there knew a lot about how to plugin to these various systems, but when they needed to build something complex together they weren't able to do so very well, or at all. Which might be fine, but you should head in that direction with intention.