3 ms·

My current job is mostly about eliminating code. We've got a massive code base that suffered severely from "not invented here" syndrome where nearly everything

by orclev 9y ago

My current job is mostly about eliminating code. We've got a massive code base that suffered severely from "not invented here" syndrome where nearly everything was implemented as a custom wrapper around some other library to avoid "vendor lock in", nevermind that the wrapper exposed essentially the exact same API which was so library specific that any attempt to replace it would basically amount to a total rewrite. I and my fellow devs have spent the last few months ripping out all the unnecessary wrappers all over the code base, updating library versions, and in many case eliminating entire trees of dependencies that are simply no longer needed. We're still in the middle of the effort, but by the time we're done I'm estimating we'll have cut our startup times to 1/10th what they are now as well as eliminated 75% of the dependencies across our projects.

Jach 9y ago
That's not exactly the same as NIH, which is where you would have reimplemented the other library instead of using it. Wrapping a dependency can make sense, because it gives you a stable thing to test against (and depending on the language may make unit testing actually possible), or to handle some version updates (especially if you're testing multiple versions -- e.g. we have a wrapper for Jetty because we needed to transition from Jetty 8 to Jetty 9 but had a lot of code to gradually update) though yeah there's less value when it's just a 1-1 and no one ever updates the underlying library...
- orclev 9y ago
  Well, it's kind of a mix of NIH and this weird cargo-cultish idea that every API needs some kind of wrapper around it. In the past if anyone wanted to use basically any library it was a major battle to get permission to do so, so a lot of code ended up being written to do things that were already provided in fairly standard libraries which is where the NIH comes in. On top of that, they then insisted on using wrapper libraries that exposed essentially the same API as the libraries they did bring in (and then never updated ever again before finally cutting support for their wrappers). The infuriating thing is that the wrappers were both tightly coupled to the underlying library in a way that makes them useless from abstracting from the underlying library, but also differed ever so slightly so that ripping them out and using the underlying library is still a major refactoring. The major impetus for the refactoring we're currently doing is that all these wrappers formed an interlocked set of dependencies on very specific versions of the underlying libraries and all of it was starting to suffer from bit-rot, with many of the libraries being stuck on versions that had been EOLed or were otherwise many years behind in updates. The worst one I can think of off the top of my head was one library that was pinned to a version from 2006 (and was still actively maintained with current releases from this year, so this wasn't even a deprecated library, just the wrapper was preventing it from being updated).

by orclev 9y ago

Jach 9y ago

That's not exactly the same as NIH, which is where you would have reimplemented the other library instead of using it. Wrapping a dependency can make sense, because it gives you a stable thing to test against (and depending on the language may make unit testing actually possible), or to handle some version updates (especially if you're testing multiple versions -- e.g. we have a wrapper for Jetty because we needed to transition from Jetty 8 to Jetty 9 but had a lot of code to gradually update) though yeah there's less value when it's just a 1-1 and no one ever updates the underlying library...

orclev 9y ago
Well, it's kind of a mix of NIH and this weird cargo-cultish idea that every API needs some kind of wrapper around it. In the past if anyone wanted to use basically any library it was a major battle to get permission to do so, so a lot of code ended up being written to do things that were already provided in fairly standard libraries which is where the NIH comes in. On top of that, they then insisted on using wrapper libraries that exposed essentially the same API as the libraries they did bring in (and then never updated ever again before finally cutting support for their wrappers). The infuriating thing is that the wrappers were both tightly coupled to the underlying library in a way that makes them useless from abstracting from the underlying library, but also differed ever so slightly so that ripping them out and using the underlying library is still a major refactoring. The major impetus for the refactoring we're currently doing is that all these wrappers formed an interlocked set of dependencies on very specific versions of the underlying libraries and all of it was starting to suffer from bit-rot, with many of the libraries being stuck on versions that had been EOLed or were otherwise many years behind in updates. The worst one I can think of off the top of my head was one library that was pinned to a version from 2006 (and was still actively maintained with current releases from this year, so this wasn't even a deprecated library, just the wrapper was preventing it from being updated).