3 ms·

I'm on the other end of it with my current project. The "architect" managed to wire about a dozen third party libraries and frameworks together to create a Fra

by tsotha 12y ago

I'm on the other end of it with my current project. The "architect" managed to wire about a dozen third party libraries and frameworks together to create a Frankenstein monster that's quite literally unmaintainable. Every day is a new day of Jenga - touch anything and it all just collapses. The funny thing is it didn't save time at any point in the project. the learning curve to configure all that was so steep we could have written it ourselves in less time. And sure, with a few dozen scattered lines of code I can add a new feature that's almost exactly what the users are requesting. After three days of perusing stackoverflow for a few days and spending another three days trying to figure out where the new cryptic error message is coming from. "Socket timeout"??? Which socket? For what?

dilap 12y ago
I feel for ya. People often rail against reinventing the wheel, but 36 times out of 37, I'd rather have an in-house created wheel that rolls how we know it should with code we understand than some 3rd party bag of voodoo that supposedly roles in the desired ways, maybe.
- collyw 12y ago
  I would far rather have something put together with well known, documented, tested third party libraries than some undocumented in house crap that one "superstar" developer knows how to work and no one else.
  - tsotha 12y ago
    You think that, but in my experience the "well know, documented, tested third party libraries" try to be all things to all people. So when you just need something to cut your steak with what you get is a Swiss army knife with twenty different blades of which you can identify three without spending a week poring through documentation. Instead of just looking at fifty lines of code to see what the "undocumented in house crap" is doing, you'll be spending all your time on stackoverflow trying to figure out why these third party libraries don't play well together. "Has anyone had this problem with version 3.3.2 of JLSHE and version 8.7 of Loopdidoodle?" Oh, I think I need 3.3.4. But the developer of my GUI framework says only 3.3.2 is tested and I'm on my own if there are problems. Somebody has a workaround but it only runs on RedHat when I'm running Debian. Should work okay if I recompile it, though... except the kernel version I'm running is too far behind. And your assumption third party libraries are any better quality than a focused in-house solution is a bit naive. Finally, a few years down the road the mind share for half your third party libraries and frameworks will have dwindled as the people you were counting on to maintain them found something shinier.
    - collyw 12y ago
      Documented and well known is preferable to most of the in house stuff I have come across. Need a Django developer, then there will be a few out there. A new developer on your own in house framework is always going to need some time to get up to speed. Sure I may be on Stack Overflow for some answers, but you can guarantee that the in house equivalent won't have any Stack Overflow answers at all. My personal experience is that open sourced libraries in CPAN / PyPI are almost always of a higher quality than in house stuff. Maybe it depends on the language. When I go for Python / Perl libraries, I usually get something of a high quality. JavaScript stuff always seems a bit more like you describe. I would say that the developer of the in house stuff leaving is going to be at least as much of a problem as people abandoning open source projects (which are open source, so you can continue to maintain them yourself).

by tsotha 12y ago

dilap 12y ago

I feel for ya. People often rail against reinventing the wheel, but 36 times out of 37, I'd rather have an in-house created wheel that rolls how we know it should with code we understand than some 3rd party bag of voodoo that supposedly roles in the desired ways, maybe.

collyw 12y ago
I would far rather have something put together with well known, documented, tested third party libraries than some undocumented in house crap that one "superstar" developer knows how to work and no one else.
- tsotha 12y ago
  You think that, but in my experience the "well know, documented, tested third party libraries" try to be all things to all people. So when you just need something to cut your steak with what you get is a Swiss army knife with twenty different blades of which you can identify three without spending a week poring through documentation. Instead of just looking at fifty lines of code to see what the "undocumented in house crap" is doing, you'll be spending all your time on stackoverflow trying to figure out why these third party libraries don't play well together. "Has anyone had this problem with version 3.3.2 of JLSHE and version 8.7 of Loopdidoodle?" Oh, I think I need 3.3.4. But the developer of my GUI framework says only 3.3.2 is tested and I'm on my own if there are problems. Somebody has a workaround but it only runs on RedHat when I'm running Debian. Should work okay if I recompile it, though... except the kernel version I'm running is too far behind. And your assumption third party libraries are any better quality than a focused in-house solution is a bit naive. Finally, a few years down the road the mind share for half your third party libraries and frameworks will have dwindled as the people you were counting on to maintain them found something shinier.
  - collyw 12y ago
    Documented and well known is preferable to most of the in house stuff I have come across. Need a Django developer, then there will be a few out there. A new developer on your own in house framework is always going to need some time to get up to speed. Sure I may be on Stack Overflow for some answers, but you can guarantee that the in house equivalent won't have any Stack Overflow answers at all. My personal experience is that open sourced libraries in CPAN / PyPI are almost always of a higher quality than in house stuff. Maybe it depends on the language. When I go for Python / Perl libraries, I usually get something of a high quality. JavaScript stuff always seems a bit more like you describe. I would say that the developer of the in house stuff leaving is going to be at least as much of a problem as people abandoning open source projects (which are open source, so you can continue to maintain them yourself).