If you are talking core technology then I disagree. My example is Oauth. There are lots of libraries that make it easy to use Oauth, but then what you have learned is not Oauth, but some library and how to use it. Libraries can also add a layer of complexity because they are generalized. And finally, what if the service you buy and don't build needs to be modified for some use case that is particular to your application? While I agree that all of these points should be considered in the general case, core technology for your business presents a very different set of considerations.
Buy Don't Build
161–170 of 227 posts
Re: Buy Don't Build
#162Talk Don’t Do
So much effort is spent on hypotheticals. If you think about a problem for too long, it will seem like a worse problem than it is.
Re: Buy Don't Build
#163Earlier quoted context omitted.
We recently purchased an enterprise scheduling software that I will not name (you may have heard of it, but it's unlikely). Told numerous times throughout the sales cycle by their architects and engineers that their API could do all the things we needed "easily" and that they could finish off the last few features we needed within 2-3 minor releases. Fast forward almost a year, at least 7 releases, and probably $200k…
I have been in the boat of the company that ripped you off before. Sales will promise the world, product/engineering caves “just one last time” to help win the deal with the easiest shittiest thing. Years go by and things inexplicably break all the time. It’s such an easy trap to fall into, because I hear similar stories all the time. I guess the moral of the story is to assume sales is lying to you until proven othe…
> assume sales is lying to you until proven otherwise
Having dealt with enterprise sales countless times, yes they do and I yes I do presume so.
They lie in many ways, the most innocent one is by demoing unrealistic perfect scenarios without any corner cases, promising integrations that do not exist ("it's in the roadmap!") etc.
This is so standard it doesn't even deserve mentioning.
Re: Buy Don't Build
#164Earlier quoted context omitted.
Author here I actually think spreadsheets are great because they are so accessible. What isn’t great though is when there is a business processs that is a spreadsheet and knowledge that exists in one persons head.
It is a management failure when this is in only one person head. Outsourcing tools will not solve internal management problems.
The issue with excel is that there's no standard construction that anyone can query; most likely it's extremely hacked together since it's not a database, but made to look like one. Spreadsheets are great for doing stuff related to exports or before importing, but so, so often they lead to data islands built to either actively or passively protect someone's job.
Re: Buy Don't Build
#165I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about.
> The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about.
> Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure mode where you have a lost garden of internal tools.
I love maintaining stuff. I don't care that my boss doesn't care about something. I care about... what I care about :)
I don't mind the "boring" tasks like keeping library versions up to date, being on the latest runtime version, and using a recent version of the framework we've adopted (we're currently running on an ancient version of it). I like doing that stuff. I like keeping things tidy. If things are up to date, I can move on to making our CI better, or improving our test coverage, or really anything that improves the whole team's productivity. There's always something to update or polish or improve.
My dilemma is that as much as I'm willing to do all that stuff, I'm essentially not allowed to. My lead and their boss say my skills are too valuable to be spent on that, so instead I must do things like lead the new team they're forming to build a new service... which I'm not interested in at all. I'm not keen on the whole lead thing. Glad to be a follower. I'm also not thrilled about building new stuff. I like to say I'm more like a car mechanic rather than an engineer: I like tweaking and tuning and fixing existing stuff, not creating new stuff.
Does anyone else feel like this? I've tried bringing it up in chats with coworkers and everyone looks at me like I have two heads.
Re: Buy Don't Build
#166Like all things challenge absolutes. I agree you shouldn't always build, otherwise you'd build your own office suite!
But do you know how many times engineers started to build something and made a discovery that resulted in inventing something significant. Or created something that gave their company a significant advantage. A not small number of times.
Re: Buy Don't Build
#167Earlier quoted context omitted.
I love this comment because it articulates a dynamic that I think is often overlooked much better than I could. I might even go a step farther and suggest that anything that is core to your business flywheel should be built and not bought (in general). Mostly because you don't want pricing to act as a disincentive to exercising the flywheel.
Then time is the disincentive.
Ah, but if it is core to your business flywheel that is precisely where you should be spending the most time.
Re: Buy Don't Build
#168This misses the rather obvious issue of price. Building your own software is the cheaper option some of the time.
This is particularly true when you have to pay to add some missing feature you need. They will, naturally, try to ask for as much as possible to get what you want.
Re: Buy Don't Build
#169I hope this doesn't get buried, because there's something that I feel like I'm a bit of a unicorn about. > The problem then with that is everyone who is working on those services is usually trying to get off of them. After all, no one wants to work on something that their boss doesn’t care about. > Yes, your CI/CD system is absolutely critical, but it’s easy for executives to not think about. This leads to a failure…
I more or less feel that way - I don’t have a lot of interest in churning out yet another feature in the never ending treadmill of feature development.
Re: Buy Don't Build
#170One thing to pay close attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool. Take logging for example. If you buy a log aggregation platform like Splunk Cloud or Loggly the pricing is likely based on the quantity of data you ingest per day. This can set up a weird incentive. If you are already close to the limit of your plan, you'll find that engineers…
I've lived that life with Datadog. I was the dev who was the most into logging so I got voluntold to be in charge of the Datadog rollout. Told everyone it was not a good idea and presented cost estimates to why, we're better off just keeping our own logs and using one of many open source projects that let you pull in logs and analyze them. But all the cool kids were on Datadog, so onto it we went.
What killed us was the combo of the desire to really aggressive log on the staging-master and release-candidate environments (five envs total) and keep the logs for more than 7 days so the QA team could compare the logs from the current release candidate to the previous release candidates. Between the volume of having all the services set at the info level and the desire to keep it more than 7 days, Datadog was >30k a month.
Which at least finally got me permission to set up an open source log manager and switch everyone over to that. Once the initial panic over the Datadog bill died down.