Finding Value in Bogosity «

Code: , , ,

I found this post on design constraints to be great food for thought. The restrictions look like they’ll make for great exercises that I wouldn’t have otherwise thought to do. They remind me of poetic forms, in that they’re difficult but perhaps ultimately liberating..

Then I saw a blog post saying:

This strikes me as so bogus, I can’t even begin to describe it.

A little poking around turned up plenty more people echoing the sentiment: that the exercises were unrealistic, needlessly restrictive, unproductive, etc. They’re right for the wrong reasons: these are all reasons that this is exercise. You’re cross-training, learning to swim with one hand behind your back. I’m going to stop belaboring the value of practice because Steve Yegge already belabored it quite well, but you’ll stagnate if you don’t struggle to improve.

(And hopefully we’ll all start practicing often enough to start figuring out what does and doesn’t work.)


  1. I understand that these are supposed to be *exercises*, and not guidelines for writing production code. But an exercise should only be done if it is known to improve performance in some way.

    Your analogy of “learning to swim with one hand behind your back” is a good one, and that’s exactly the problem I had with this article. I don’t think a swimmer would ever train with one hand behind their back, because it would ruin their form, and ultimately there are much better and efficient ways to perform strength training. I think the same is true of these constraints.

  2. I disagree because programming is an abstract mental activity, so it’s easy to fall into the same patterns of thought and design. The constraints are designed to make you uncomfortable, to force you to think differently and try new things. You’re right that swimmers don’t need that, they’re trying to perfect form. I haven’t yet seen a programming form worth perfecting (if it even has such a concept). I also haven’t seen programming exercises known to improve performance — even tracking programmer performance is a known problem.

  3. Peter, you’re right that with programming patterns and style, we don’t know for sure what is good. But you still shouldn’t do exercises like this unless you at least believe there is a good reason for it.

    I can think of many different kinds of arbitrary constraints that you could adopt, but nobody would suggest an exercise like “start all of your methods with the letter R” or “keep all lines shorter than 10 characters” because there is no obvious value in those constraints. For the 9 constraints that Bay suggested, although he might not advocate following them to a T, he is still implying that they will lead to better code in some way.

  4. You make a good point that they’re of unproven value. I guess they just tickled me in the right places and I think they could be useful — or at least fun to try.

Leave a Reply

Your email address will not be published.