4 ms·

Once upon a time there was a systems programmer who wanted to use a readymade 3rd party solution to an specific problem. He evaluated 3 options, then downloade

by jchook 7y ago

Once upon a time there was a systems programmer who wanted to use a readymade 3rd party solution to an specific problem. He evaluated 3 options, then downloaded, compiled, configured and integrated the best choice into the project over the course of a full day. Its limited database integration configuration necessitated some odd quirks like duplicating a db column, but oh well. When finally done, integration tests revealed that it didn't actually solve the entire problem. It only solved 90% of the problem. Not only that, it had a significant but elusive bug that only occurred in 5% of situations. He filed a bug report, but the project hadn't received any updates in over a year. Damn. When it became clear neither of the other two readymade libraries would solve 100% of the problem either, the programmer wrote his own solution. It took 3 days of work but he learned a LOT about exactly how it works, and the result solved 100% of the problem with no major bugs. All of the quirks disappeared. The solution fit the problem exactly, and remained flexible and maintainable. It eventually served as a solid foundation for future developments which had no readymade solution.

_bxg1 7y ago
This parable is heavily dependent on the quality of a given ecosystem. When I bring in a third-party solution for something that might be feasible for me to implement myself, it must 1) be actively maintained, 2) be decoupled from my code at the function-interface boundary, and 3) fully cover my use-case, at least as it's known at the time of introduction. In the ecosystems I work with, finding all of these qualities is not uncommon.
hinkley 7y ago
There’s a questionnaire out there for anyone writing a library and the first couple of questions are what ones did you try, why don’t they work, and why can’t they be fixed. Sounds like your coworker wrote a library the “right” way. We had our own snowflake wrapper around the saucelabs client. I eventually figured out how to file a PR to do the same. Now I get to use that solution on every other project I ever work on. I have similarly used my own Stack Overflow answer to solve a problem I also had three years prior. And I recently found my SO answer to another question verbatim in our own codebase. Ironically, from a guy who often ignores my advice. Get as many things out of your head and into the group memory as you can. Things get forgotten otherwise. Speaking of, did you guys ever consider open sourcing his solution?

by jchook 7y ago

_bxg1 7y ago

This parable is heavily dependent on the quality of a given ecosystem. When I bring in a third-party solution for something that might be feasible for me to implement myself, it must 1) be actively maintained, 2) be decoupled from my code at the function-interface boundary, and 3) fully cover my use-case, at least as it's known at the time of introduction. In the ecosystems I work with, finding all of these qualities is not uncommon.

hinkley 7y ago

There’s a questionnaire out there for anyone writing a library and the first couple of questions are what ones did you try, why don’t they work, and why can’t they be fixed. Sounds like your coworker wrote a library the “right” way. We had our own snowflake wrapper around the saucelabs client. I eventually figured out how to file a PR to do the same. Now I get to use that solution on every other project I ever work on. I have similarly used my own Stack Overflow answer to solve a problem I also had three years prior. And I recently found my SO answer to another question verbatim in our own codebase. Ironically, from a guy who often ignores my advice. Get as many things out of your head and into the group memory as you can. Things get forgotten otherwise. Speaking of, did you guys ever consider open sourcing his solution?