4 ms·

1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for

1. In house designed and built custom RTOS 2. In house designed and built custom hardware platform 3. Our entire UI framework was highly customized by us, for our specific needs It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible! That's an interesting set of observations there. I've been wondering for a while whether we -- as a field -- have been systematically underestimating the cost of using libraries. To my eye, the anecdata definitely seem to be on the side of projects going more smoothly when the dependencies are few and well understood. Does anyone know of anyone doing research into this kind of thing?

com2kid 8y ago
I'd personally say libraries save time in net, but they add unpredictability. Especially for experienced devs who have written framework code before. "How long will it take you to write a graphics rendering routine that you've previously written on another project" is easier to estimate than "does this feature in the graphics library we are using work?" The library probably works, sure, but when it doesn't the problem can become an almost unbounded time sink.
- dasmoth 8y ago
  Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it). I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.

com2kid 8y ago

I'd personally say libraries save time in net, but they add unpredictability. Especially for experienced devs who have written framework code before. "How long will it take you to write a graphics rendering routine that you've previously written on another project" is easier to estimate than "does this feature in the graphics library we are using work?" The library probably works, sure, but when it doesn't the problem can become an almost unbounded time sink.

dasmoth 8y ago
Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it). I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.