5 ms·

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, a

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.

ProAm 9y ago
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.
- bonesss 9y ago
  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.
keerthiko 9y ago
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.
erichurkman 9y ago
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.

ProAm 9y ago

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.

bonesss 9y ago
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.

keerthiko 9y ago

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.

erichurkman 9y ago

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.