111–120 of 227 posts
Good article, I am definitely filing away to pull out in some future team discussions. This paragraph is confusing me, either it's missing a 'not' or something, or I'm just confused. Is anyone following? > The question you should be asking is what else could be done instead of tuning your own stuff or building a new internal system. The answer is usually spending more time coming up with the correct architecture inst…
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
Fast forward almost a year, at least 7 releases, and probably $200k of payroll on our end and their product barely runs, and doesn't handle all of our standard workflow, let alone edge cases. Best we can assume is they were writing the API from scratch because we needed it and didn't have the skill to do so. Documentation was offensively bad when it was correct, which most of the time it was not, to the point where there were several instances of the endpoints in the docs being wrong, causing us to call support to ask what the real endpoints were we were supposed to be calling.
All this to say yeah, buying is great if the company is professional and has a well-documented product, and the sales and technical pre-sales folks know what they're talking about. But that isn't necessarily the case, even for six-figure purchases. And when it's not the case you can easily burn a non-trivial amount of money before you ever realize it.
All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.
I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point: > My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet. The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want pr…
Earlier quoted context omitted.
> frankly I do not see any advantage of hosting on say Azure over hosting myself. In my opinion, cloud hosting only makes sense if your systems are architectured around being hosted on the cloud. If you can build your application in such a way that it runs in the free tier of serverless, then it's going to be considerably more cost effective than renting a dedicated server - but if you can't, then it absolutely won't…
>"If you can build your application in such a way that it runs in the free tier of serverless" Serverless - that would be vendor/architectural trap. Besides free tier does not come anywhere close to be able to serve my applications. They serve real medium/big size businesses.
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 are discouraged from logging new things.
This can have a subtle effect on your culture. Engineers who don't want to get into a budgeting conversation will end up avoiding using key tools, and this can cost you a lot of money in terms of invisible lost productivity.
Tools that charge per-head have a similar problem: if your analytics tool charges per head, your junior engineers won't have access to this. This means you won't build a culture where engineers use analytics to help make decisions.
This is a very tricky dynamic. On the one hand it's clearly completely crazy to invest in building your own logging or analytics solutions - you should be spending engineering effort solving the problems that are unique to your company!
But on the other hand, there are significant, hard-to-measure hidden costs of vendors with billing mechanisms that affect your culture in negative ways.
I don't have a solution to this. It's just something I've encountered that makes the "build v.s. buy" decision a lot more subtle than it can first appear.
One 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…
Another option we've found works is buy, to just get started, and invest moving forward in our own project. Getting something off the ground quickly tends to help us understand better the requirements.
One 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…
Earlier quoted context omitted.
Excel has a subscription fee as well.
Yeah unfortunately. We still have a 2016 Excel license and will continue to use it.
https://www.microsoft.com/en-us/microsoft-365/p/office-home-...