4 ms·

Yes, instead of getting support hell for monkeypatching, we get support hell for using forked versions of the libs. Consider me skeptical that there will be an

by yxhuvud 16y ago

Yes, instead of getting support hell for monkeypatching, we get support hell for using forked versions of the libs. Consider me skeptical that there will be any real improvement from this. (I am not claiming forks are bad, only that it solves a different problem than support hell)

michaelfeathers 16y ago
Agreed. There should be a term for "takes problem from one place and puts it in another place yielding no net advantage."
- JonnieCache 16y ago
  "Shuffling the deckchairs on the titanic" comes to mind, but it isn't really a term.
  - IsaacL 16y ago
    I've heard that phrase a few times before, but I don't think it fits the context here. The context is a "solution" that creates more problems than it solves. "Shuffling the deckchairs/polishing the silverware on the Titanic" refers to busying oneself with small problems when there's a honking great problem that's being ignored.
- riffraff 16y ago
  parasolving? Though this is not really the case, I'd say it's more like "the problem is still there but we walked around it with a different route". Perisolving maybe? Especially if you consider that part of the problem is that something won't work but it may take hours to understand it's because the semantics of Enumerable#group_by in library X are not the same as the ones defined in library Y.
- goodside 16y ago
  Circumsolution.
- Confusion 16y ago
  The old saying Out of the frying pan, into the fire seems perfectly applicable. Although it originally implies that matters get worse, it's colloquially used to indicate things don't get any better.
- deleted 16y ago
  [deleted]
kls 16y ago
Right to me personally I think maintaining a version of an external project is the less ideal of the two. I personally think Monkey Patching is a very elegant solution to modifying 3rd party code that should be treated like a black box. It keeps third party code and internal code cleanly separated and if the maintainers then patch their code it becomes very easy to go in and pull your monkey patches out when the problem has been addressed. Managing the versioning dependencies for an entire project just to keep a patch set seems like overkill to me when generally you only need to modify a few lines of code in an entire project. For example, my company is working on a huge web project for IBM right now, it is a Javascript based front end, in which we use Dojo as the toolkit. It would be safe to say that there are more lines of Javascript code than Gmail has in this project and yet our Monkey Patch files probably consist of less than 20 lines of code. It would be overkill to maintain a branch of Dojo for those 20 lines of code, especially given the fact that most of the patches are to customize Dojo to do things the way we want it too and not true bugs. So they have no hope of making it back into Dojo proper. With Monkey Patching we just maintain our own Monkey Patch files along with our code base. We just upgraded the project from 1.5 to 1.6 which if we would have been maintaining our own version, it would not have been a 30 minute process. That being said, if a developer is Monkey Patching his own or internal code, it should serve as a red flag that they may be doing something wrong.
jherdman 16y ago
I've done this on a project I worked on recently, so I'll take a moment to explain why I think this is a valid, and safer strategy than the alternative. In said project we had a number of modifications to libraries to support some additional desired functionality. The developers at the time simply forked the library and wrote patches on top of the mainline branch. We found this significantly impeded our ability to upgrade, or take advantage of changes, down the line, as well as to track upstream's HEAD. When one forks, branches, and then patches on the branch, these problems are easily skirted. In addition, it's easy to submit your patches for integration into upstream. In the end the gain is flexibility. One cannot discount the value of flexibility.

by yxhuvud 16y ago

michaelfeathers 16y ago

Agreed. There should be a term for "takes problem from one place and puts it in another place yielding no net advantage."

JonnieCache 16y ago
"Shuffling the deckchairs on the titanic" comes to mind, but it isn't really a term.
- IsaacL 16y ago
  I've heard that phrase a few times before, but I don't think it fits the context here. The context is a "solution" that creates more problems than it solves. "Shuffling the deckchairs/polishing the silverware on the Titanic" refers to busying oneself with small problems when there's a honking great problem that's being ignored.
riffraff 16y ago
parasolving? Though this is not really the case, I'd say it's more like "the problem is still there but we walked around it with a different route". Perisolving maybe? Especially if you consider that part of the problem is that something won't work but it may take hours to understand it's because the semantics of Enumerable#group_by in library X are not the same as the ones defined in library Y.
goodside 16y ago
Circumsolution.
Confusion 16y ago
The old saying Out of the frying pan, into the fire seems perfectly applicable. Although it originally implies that matters get worse, it's colloquially used to indicate things don't get any better.
deleted 16y ago
[deleted]

kls 16y ago

Right to me personally I think maintaining a version of an external project is the less ideal of the two. I personally think Monkey Patching is a very elegant solution to modifying 3rd party code that should be treated like a black box. It keeps third party code and internal code cleanly separated and if the maintainers then patch their code it becomes very easy to go in and pull your monkey patches out when the problem has been addressed. Managing the versioning dependencies for an entire project just to keep a patch set seems like overkill to me when generally you only need to modify a few lines of code in an entire project. For example, my company is working on a huge web project for IBM right now, it is a Javascript based front end, in which we use Dojo as the toolkit. It would be safe to say that there are more lines of Javascript code than Gmail has in this project and yet our Monkey Patch files probably consist of less than 20 lines of code. It would be overkill to maintain a branch of Dojo for those 20 lines of code, especially given the fact that most of the patches are to customize Dojo to do things the way we want it too and not true bugs. So they have no hope of making it back into Dojo proper. With Monkey Patching we just maintain our own Monkey Patch files along with our code base. We just upgraded the project from 1.5 to 1.6 which if we would have been maintaining our own version, it would not have been a 30 minute process. That being said, if a developer is Monkey Patching his own or internal code, it should serve as a red flag that they may be doing something wrong.

jherdman 16y ago

I've done this on a project I worked on recently, so I'll take a moment to explain why I think this is a valid, and safer strategy than the alternative. In said project we had a number of modifications to libraries to support some additional desired functionality. The developers at the time simply forked the library and wrote patches on top of the mainline branch. We found this significantly impeded our ability to upgrade, or take advantage of changes, down the line, as well as to track upstream's HEAD. When one forks, branches, and then patches on the branch, these problems are easily skirted. In addition, it's easy to submit your patches for integration into upstream. In the end the gain is flexibility. One cannot discount the value of flexibility.