3 ms·

> willingness to fearlessly dig into someone else's code. That's kinda illusion. If you start digging into some really complex code, like distributed processin

by bitL 9y ago

> willingness to fearlessly dig into someone else's code. That's kinda illusion. If you start digging into some really complex code, like distributed processing core, meta-programming framework, low-level optimizations, it can take you years to understand all that is going on. Often it's more economical just to rewrite it, even if the previous system was far better than what you'll produce. Whether companies like it or not, projects live with original team members and once they move on, it's getting complicated to maintain or extend them.

nevir 9y ago
The inherent danger in rewriting dependencies always seems to be greatly underestimated, though. Especially when this is your first time tackling the problem space in earnest. * Getting the solution 80% of the way there is often pretty fast (which ends up deceiving everyone depending on it "it's almost done!") * You are nearly guaranteed to encounter a bunch of bugs that were already solved in the original dependency. * Due to the previous points, there's a big chance that your initial design had a few fatal flaws, and requires significant refactoring to address (making the project take longer, and if not careful making it much harder to understand & maintain) Rewriting dependencies can definitely be worth it from a code ownership/maintenance point of view; but more often than not, you'll end up creating a cycle where the new version of the dependency is just as obtuse as the previous—and once you leave, the same problem all over again. If a dependency is well documented, has a clear architecture, and follows consistent coding practices, it will stand the test of time (including loss of authors/maintainers). Most people/companies aren't willing to put the time/effort into that level of polish.

3 ms·

> willingness to fearlessly dig into someone else's code. That's kinda illusion. If you start digging into some really complex code, like distributed processin

by bitL 9y ago

nevir 9y ago
The inherent danger in rewriting dependencies always seems to be greatly underestimated, though. Especially when this is your first time tackling the problem space in earnest. * Getting the solution 80% of the way there is often pretty fast (which ends up deceiving everyone depending on it "it's almost done!") * You are nearly guaranteed to encounter a bunch of bugs that were already solved in the original dependency. * Due to the previous points, there's a big chance that your initial design had a few fatal flaws, and requires significant refactoring to address (making the project take longer, and if not careful making it much harder to understand & maintain) Rewriting dependencies can definitely be worth it from a code ownership/maintenance point of view; but more often than not, you'll end up creating a cycle where the new version of the dependency is just as obtuse as the previous—and once you leave, the same problem all over again. If a dependency is well documented, has a clear architecture, and follows consistent coding practices, it will stand the test of time (including loss of authors/maintainers). Most people/companies aren't willing to put the time/effort into that level of polish.