4 ms·

This is our stance too. Even within the "batteries included" aspects of the .NET6 framework, we insist on doing certain things our way. Some of the biggest ex

This is our stance too. Even within the "batteries included" aspects of the .NET6 framework, we insist on doing certain things our way. Some of the biggest examples being AspNetCore logging and the JSON-style configuration abstractions. We completely rip this out and do it in code-time our way. I cannot account for the exact number of hours we wasted trying to do [x] the 'official' way only to be burned at deployment & framework upgrade time. It took at least 100 hours just to realize json-based runtime config is definitely not for us. Separately, it took me fewer than 30 minutes to write a dumbass static logger that fills a sqlite database with entries and have it wired up throughout the application. I don't think you could even read & understand that AspNetCore logging article in 30 minutes, much less have functional code in place that you can hang your hat on for years to come. If not reinventing the wheel is about saving time, then perhaps we need to iterate the aphorism. Maybe we flip it around: Only reuse other people's code when it's for something that you don't really care about or doesn't frustrate your project's long-term ambitions.

AlotOfReading 4y ago
Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality. However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the sort of commoditization I think we should strive for, but they haven't been very useful so far.
- ChrisMarshallNY 4y ago
  > However, as an industry we don't have a great way to know what is or isn't reliable. That's the rub. Your zlib example is one of the "Platonic Ideal of Quality Open Source" libraries. Using that is a no-brainer. Any suggestion of rating/licensing/qualifying open-source projects, is met with ... resistance ...
  - GoblinSlayer 4y ago
    It's still a full plate of old good C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/zlib/commit/eff308af425b67093bab25...
- randomdata 4y ago
  > However, as an industry we don't have a great way to know what is or isn't reliable. I'm not sure it matters. You can assume it will be as reliable as your own buggy code that you wrote yourself. The more important question is how maintainable or replaceable is it. Once you include a dependency it becomes your code to maintain, so it had better be something that you're comfortable jumping in and getting your hands dirty with if need be.

AlotOfReading 4y ago

Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality. However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the sort of commoditization I think we should strive for, but they haven't been very useful so far.

ChrisMarshallNY 4y ago
> However, as an industry we don't have a great way to know what is or isn't reliable. That's the rub. Your zlib example is one of the "Platonic Ideal of Quality Open Source" libraries. Using that is a no-brainer. Any suggestion of rating/licensing/qualifying open-source projects, is met with ... resistance ...
- GoblinSlayer 4y ago
  It's still a full plate of old good C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/zlib/commit/eff308af425b67093bab25...
randomdata 4y ago
> However, as an industry we don't have a great way to know what is or isn't reliable. I'm not sure it matters. You can assume it will be as reliable as your own buggy code that you wrote yourself. The more important question is how maintainable or replaceable is it. Once you include a dependency it becomes your code to maintain, so it had better be something that you're comfortable jumping in and getting your hands dirty with if need be.