6 ms·

The Rails commit that spurred this post, apparently: https://github.com/rails/rails/pull/5329 https://github.com/rails/rails/pull/5329

lucisferre 15y ago
Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match. Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request? The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction. It's debatable who's actually bikeshedding here.
- dhh 15y ago
  Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!
  - lucisferre 15y ago
    Fair enough, I wont argue with your elastic defence ;).
  - CodeMage 15y ago
    Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.
    - lucisferre 15y ago
      Did I? Perhaps you could elaborate for my benefit then.
- bradleyland 15y ago
  This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not. An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint. Ah, but if real life were only so black & white. In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.
  - nirvdrum 15y ago
    Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.
- deleted 15y ago
  [deleted]
- lucisferre 15y ago
  Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.html http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one. So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie. However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.
zumda 15y ago
To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0. @fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.) Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again. And so the bike shedding continued...
- fxn 15y ago
  Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.
  - zumda 15y ago
    Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)
  - kelnos 15y ago
    I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.
protomyth 15y ago
I found this comment https://github.com/rails/rails/pull/5329#issuecomment-4669686 https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.
bguthrie 15y ago
Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding. If you read the original source for the term at http://bikeshed.com/ http://bikeshed.com/, Kamp shows his respect for the submitter of the change: I bow my head in respect to the original proposer because he stuck to his guns through this carpet blanking from the peanut gallery, and the change is in our tree today. I would have turned my back and walked away after less than a handful of messages in that thread. This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me. (Edit: formatting.)
stiff 15y ago
To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.
- stock_toaster 15y ago
  Maybe they are just trying to optimize for pedantry.
- Cushman 15y ago
  That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons. It's not bikeshedding, but there ought to be a name for that.
  - aeturnum 15y ago
    My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort. The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.
    - Cushman 15y ago
      I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.) Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.
bluesnowmonkey 15y ago
It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.

lucisferre 15y ago

Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match. Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request? The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction. It's debatable who's actually bikeshedding here.

dhh 15y ago
Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!
- lucisferre 15y ago
  Fair enough, I wont argue with your elastic defence ;).
- CodeMage 15y ago
  Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.
  - lucisferre 15y ago
    Did I? Perhaps you could elaborate for my benefit then.
bradleyland 15y ago
This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not. An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint. Ah, but if real life were only so black & white. In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.
- nirvdrum 15y ago
  Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.
deleted 15y ago
[deleted]
lucisferre 15y ago
Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.html http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one. So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie. However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.

zumda 15y ago

To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0. @fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.) Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again. And so the bike shedding continued...

fxn 15y ago
Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.
- zumda 15y ago
  Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)
- kelnos 15y ago
  I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.

protomyth 15y ago

I found this comment https://github.com/rails/rails/pull/5329#issuecomment-4669686 https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.

bguthrie 15y ago

Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding. If you read the original source for the term at http://bikeshed.com/ http://bikeshed.com/, Kamp shows his respect for the submitter of the change: I bow my head in respect to the original proposer because he stuck to his guns through this carpet blanking from the peanut gallery, and the change is in our tree today. I would have turned my back and walked away after less than a handful of messages in that thread. This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me. (Edit: formatting.)

stiff 15y ago

To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.

stock_toaster 15y ago
Maybe they are just trying to optimize for pedantry.
Cushman 15y ago
That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons. It's not bikeshedding, but there ought to be a name for that.
- aeturnum 15y ago
  My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort. The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.
  - Cushman 15y ago
    I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.) Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.

bluesnowmonkey 15y ago

It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.