3 ms·

Regarding C), I think it actually gets tough. > but its cheaper and easier to use this existing, available, code to do the job. What often happens is that the

Regarding C), I think it actually gets tough. > but its cheaper and easier to use this existing, available, code to do the job. What often happens is that the existing, available, sometimes even popular and well regarded code has lots of issues that you may only find after you deploy the thing. Then, you need to decide what tack to take. Can you engage upstream? Do you end up maintaining third party code yourself to fix the issues? Working around quirky bugs? You may even find yourself so frustrated with all of the above that you wind up abandoning the dependency and writing something new in-house. But honestly, getting back to the topic, sqlite is not one of those things. Sqlite is a very solid library.

bruce511 4y ago
Yes, I agree not every bit of available code is perfect. A lot of it is crap. Choosing an existing library is worth taking dome time and research over. Inevitably some libraries will need replacing. In some cases we've ended up rolling our own. But in these cases the time spent with the discarded library is not wasted. Rather it gives us a chance to understand the domain better, to understand our needs better, and ultimately to have better criteria for making our choices. Things like documentation, support, bug fixing, source code, and so on have all become important parts of the evaluation process. Interestingly our internal libraries are often less-well documented (if at all) the author is sometimes no longer around, and it usually has all kinds of quirks we work around. This after taking longer, and costing more, written from an unclear spec by people not terribly familiar with the domain. And yes, we've hone the nuclear route of ripping out and rewriting, and that is expensive , but no more expensive than defaulting to "write ourselves ", and indeed usually cheaper because we have a better idea of what we want.
- fps_doug 4y ago
  I think one of the things you learn on your way to C) is when it makes sense to roll your own. It is difficult, and maybe something that actually happens after c. It seems to be very hard to make that call in time, and in the past I feel like every time we chose to implement something on our own, the existing solution would have been better in hindsight, and every time we said "ok, that existing solution looks fine" it turned out to be a dumpster fire a year down the line. But obviously the times where you made the right call just don't stick out that much because stuff "just worked", and also, in case you think you made the wrong decision, the alternative could've been ever worse. But still, I guess everybody knows that feeling? :-)

bruce511 4y ago

Yes, I agree not every bit of available code is perfect. A lot of it is crap. Choosing an existing library is worth taking dome time and research over. Inevitably some libraries will need replacing. In some cases we've ended up rolling our own. But in these cases the time spent with the discarded library is not wasted. Rather it gives us a chance to understand the domain better, to understand our needs better, and ultimately to have better criteria for making our choices. Things like documentation, support, bug fixing, source code, and so on have all become important parts of the evaluation process. Interestingly our internal libraries are often less-well documented (if at all) the author is sometimes no longer around, and it usually has all kinds of quirks we work around. This after taking longer, and costing more, written from an unclear spec by people not terribly familiar with the domain. And yes, we've hone the nuclear route of ripping out and rewriting, and that is expensive , but no more expensive than defaulting to "write ourselves ", and indeed usually cheaper because we have a better idea of what we want.

fps_doug 4y ago
I think one of the things you learn on your way to C) is when it makes sense to roll your own. It is difficult, and maybe something that actually happens after c. It seems to be very hard to make that call in time, and in the past I feel like every time we chose to implement something on our own, the existing solution would have been better in hindsight, and every time we said "ok, that existing solution looks fine" it turned out to be a dumpster fire a year down the line. But obviously the times where you made the right call just don't stick out that much because stuff "just worked", and also, in case you think you made the wrong decision, the alternative could've been ever worse. But still, I guess everybody knows that feeling? :-)