5 ms·

I feel like on the contrary there's an enormous cost attached to using prefab components that only kinda do what you need them to do. Shops that have embrace t

I feel like on the contrary there's an enormous cost attached to using prefab components that only kinda do what you need them to do. Shops that have embrace this philosophy have been some of the most inefficient ones I've ever encountered. Screens of yaml code was written to implement tasks that could have been performed with lines of programming code; and many man-years were spent implementing functions that copied fields from one object to another nearly but not quite identical object. It's a big driver of both complex and slow software. Often the adaptation layer necessary to get it to actually satisfy your needs rivals the size and complexity of the piece of existing solution code you're trying to leverage. Software that is built from the ground-up to your exact needs is often both faster and slimmer and more maintainable and suffers from far less dependency churn.

wmfiv 3y ago
Yeah. This works both ways. At small scale or early stage you should try like hell to work backwards from pre-existing components so that everything does exactly what you need them to do by definition. Eventually you outgrow that and it makes sense to build things that do exactly what you want because the incremental value is worth it.
ecshafer 3y ago
There is a balance to Not In House syndrome where you build everything yourself, and the opposite: everything should be vendored in. I am inclined to think that a healthy NIH syndrome is the better place to be. Companies which vendor everything move along at a snails pace, and often getting your outside product to work with internal needs is a huge years long endeavor, to the point just writing a decent version yourself that is exactly what you need is really useful.
- marginalia_nu 3y ago
  NIH has shifted in meaning over time. It used to literally mean Not Invented Here. In the original sense, the NIH approach would be to invent a rivalling technique to the message broker. That is indeed a questionable idea.
  - ecshafer 3y ago
    I think I just got it wrong. Not invented here sounds better and more right. I just typically think of only the acronym, and decided to write it out in case someone hadn’t heard it (and thus made a mistake). Good catch.
    - marginalia_nu 3y ago
      There's a bunch of alternative meanings that have cropped up to suit the new and wider meaning (which is definitely common). Seen Not Implemented Here too.
- throwaway2037 3y ago
  In my experience, the problem with vendor: What if a feature is missing? I see this often when I am forced to use a vendor product. And, on day one, no one (hands on) usually knows anything about the vendor product, so there is a huge learning curve. If you follow NIH, then you organically build knowledge in the org. And features can be added with time+money. (Sure, some vendor products will add features, but usually for an insane price tag.) You cannot win either way: They hardest part is knowing which one to choose.

wmfiv 3y ago

Yeah. This works both ways. At small scale or early stage you should try like hell to work backwards from pre-existing components so that everything does exactly what you need them to do by definition. Eventually you outgrow that and it makes sense to build things that do exactly what you want because the incremental value is worth it.

ecshafer 3y ago

There is a balance to Not In House syndrome where you build everything yourself, and the opposite: everything should be vendored in. I am inclined to think that a healthy NIH syndrome is the better place to be. Companies which vendor everything move along at a snails pace, and often getting your outside product to work with internal needs is a huge years long endeavor, to the point just writing a decent version yourself that is exactly what you need is really useful.

marginalia_nu 3y ago
NIH has shifted in meaning over time. It used to literally mean Not Invented Here. In the original sense, the NIH approach would be to invent a rivalling technique to the message broker. That is indeed a questionable idea.
- ecshafer 3y ago
  I think I just got it wrong. Not invented here sounds better and more right. I just typically think of only the acronym, and decided to write it out in case someone hadn’t heard it (and thus made a mistake). Good catch.
  - marginalia_nu 3y ago
    There's a bunch of alternative meanings that have cropped up to suit the new and wider meaning (which is definitely common). Seen Not Implemented Here too.
throwaway2037 3y ago
In my experience, the problem with vendor: What if a feature is missing? I see this often when I am forced to use a vendor product. And, on day one, no one (hands on) usually knows anything about the vendor product, so there is a huge learning curve. If you follow NIH, then you organically build knowledge in the org. And features can be added with time+money. (Sure, some vendor products will add features, but usually for an insane price tag.) You cannot win either way: They hardest part is knowing which one to choose.