Hacker News Reader

The whole thing is a big ball of mud. If you commit to a vendor you risk vendor-lock in. If you commit to hand-roll you risk runaway deadlines, feature creep, and a slew of other threats. Once you pick one or the other and get it to a business functional level you lose all momentum and willpower to pivot to the best solution now that you have a "good enough" approach.

Software is always 'Pay me now, or pay me later'. In the end I believe you usually always end up paying pretty close to the same, it just depends on if you are happy with the solution in 18-36 months or hate it.

The tricky bit is when opportunity costs come in... "Pay me now" means sacrificing clear opportunities in the visible horizon, "pay me later" does the same thing at an less-controlled future point sacrificing presently unknown opportunities.

Personally I much prefer 'pay me now', because 9 times out of 10, IME, some form of technical debt underlies the reasoning about why a team can't do something. 'It always pays to take the pain up front', basically.

It's good to be conscious of vendor-lock-in as you implement a tool or library. If their product is good, at the worst you can borrow their API design and slowly reimplement portions of the back-end provided with your own implementations to liberate yourself. For a product/business that makes money, most often using a stable external tool is a better first-step.

If things flip around again and you find a new library that solves your needs better than your homegrown lib, you can drop it in forking your lib and turning it into a wrapper on the external lib.

At least this is what I have learned implementing high flexibility cross-platform mobile video playback solutions in our app over the last 5 years, where the landscape of libraries (and our own tools) has kept changing.

Sometimes "good enough" is, well, good enough. How accurate good is good enough? 80%? 95%? It's different for every business, and the needs change over time. 60% accurate for an eagerly stage bootstrapped company? Gold! 60% accuracy on a growth-stage business where you should know what to do? Terrible.

Be limber enough to eschew the tools that aren't working. But "good enough" is, well, good enough for most folks. Perfection the enemy of progress and all that.

We went for a vendor to replace one of our internal tools. It looked too costly to pay team of 4 engineers a year to support it.

Unfortunately, the part "implement a vendor and see how you like it" went only with the first half. Complaints of developers supposed to be using the tool were brushed aside as a simple resistance of change. In the end it was implemented by decree from higher management.

Only after all the paperwork was signed, we started to see that the vendor doesnt support our usecases, that their hardware is underpowered for the load we were expecting, e.t.c ...

In the end, I have heard at least 20 various senior and beyond senior engineers from various teams complaining that they spend 20 to 50 % of time working around the vendors bugs, around once a month bringing down vendors infrastructure, because our use-case mandated uploading more data than the infra could handle.

I definitely agree that clear requirement list and clearly scoped project and implementing a vendor to see how you like it is usually better than in-house

On the other hand in-house is usually better than implementing a random vendor because management feels like it ;)

> There's a reason MixPanel (and any other vendor) has so many engineers. You're paying them to have already made the mistakes that you're about to make.

The real reason Mixpanel (et al) have so many engineers is:

A) They need to scale their service to reliably provide to N corporations which is frequently non-trivial.

B) They need to implement the 80% of features that aren't critical path for Company A because some subset of them are for Company B,C,D,E,F,G,H,I,J,K,etc.

C) I've seen software vendors make some pretty terrible and painfully obvious mistakes.

Idk, maybe I'm crazy but I have very little faith in this idea that more engineers = better decisions were made. I've just never found quantity has an impact on quality of the end product, only the speed at which its produced.

The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built.

> The number of engineers they have is irrelevant to the point. The point is you pay someone to worry about a specific thing so you don't have to and (hopefully) their expertise leads to a better product than you could have built.

Yeah, and in my experience, that frequently fails to materialize which why I mentioned point C.

Now, that could be arrogance on my part but it doesn't change my experience on the quality of the vast majority of outside software vendors.