undefined | Better HN

0 pointsjrockway14y ago0 comments

While true, this can hardly be considered good engineering. The more complexity in your system, the more likely it is to break. The question is: do you want to take the productivity hit today and fix the socket libraries, or do you want to fix it at some time in the future when you finally realize your code/test/release cycle is twice as slow as your competitors'?

(I've worked on a lot of code that took the second trade-off. The result is almost always a full rewrite. Maintain your codebase or it goes out of control really fast.)

0 comments

1 comments · 1 top-level

colinmarc14y ago

I agree that before monkeypatching, a team should weigh their options. But for many projects, "fixing the socket libraries" could be a lot of work, or not an option at all.

In the example I gave, you'd have to rewrite whatever database drivers you're using, or at least hack them to work in a non-blocking fashion. That could have just as much development cost as monkeypatching.

zodiac is an attempt to address the problems that make monkeypatching such a risky, unpredictable option, by making patches smaller and therefore using more system code. Hopefully, for situations where monkeypatching is necessary, I can make it cleaner and more maintainable.

j / k navigate · click thread line to collapse