The double-edged sword of code reuse [LWN.net]

The double-edged sword of code reuse

Posted May 19, 2011 13:58 UTC (Thu) by mcoleman (guest, #70990)
Parent article: The platform problem

This seems related to the general problem of decide when to reuse existing code (as opposed to rewriting from scratch). Although we learned in school that we should reuse whenever possible, long experience suggests that this is very much a mixed blessing. It can be a serious problem if the reused code isn't entirely under your control, may mutate, may be encountered in multiple incompatible versions, may be missing, there are IP issues, etc.

If you discover a bug in your own code, you can usually correct it in a punctual and coherent way. If the bug is in code that's been reused from elsewhere, it may take years for fixes to become widely available, if you are even able to convince upstream to accept them at all.

In this particular case, it sounds like you personally had the option of making changes "upstream" instead of "downstream", which greatly simplifies the decision. For ordinary coders, though, often the least-bad alternative is to go ahead and implement locally, then dash off a note to the upstream, and watch (possibly over a period of years) to see whether it's incorporated in a stable and usable way at some point.

to post comments

The double-edged sword of code reuse

Posted May 21, 2016 1:42 UTC (Sat) by jsbarnes (guest, #4096) [Link]

God yes. Generally working on your own code or project proceeds much more quickly and predictably than working on something "upstream". But it really depends on your upstream. In some cases even moderate changes can be incorporated quickly (i.e. at a similar pace to your own project), but in other cases one is forced to perform major rewrites or take on only tangentially related work, which can be both frustrating and counterproductive to the end users of your own project.

It's really tough to strike a balance between the two; generally I think developers want to improve the projects they participate in, it just needs to be made as frictionless as possible without compromise long term goals for the project so that everyone gets something from the effort.