views:

247

answers:

2

Sometimes someone has a great idea that solves a problem. But as time passes, people forget why it was a great idea and try to use it in ways that end up causing problems as bad (or worse) than what the idea was originally supposed to solve.

Example:

I'm sure that distributed source control is sufficiently counterintuitive that people try to establish conventions that defeat the point of distributed source control.

Example 2:

it's very natural to think that when you're writing some code, you should handle all errors that could possibly arrise. But a function doesn't always have enough information to handle the error properly, so all it can do is somehow tell whoever called it that the error occured. Passing errors up the call stack by hand is tedious, so exceptions were invented. With no extra typing on the part of the programmer, exceptions will bubble up the call stack until somebody can do something with them. It seems like checked exceptions, at least in practice, tarnish the awesomeness of exceptions. At best, the programmer has to tediously work her way up any possible call stack, specifying that every method throws a given exception up to the point where it can be handled (if it can be handled). Worse, she might swallow the exception to avoid the chore!

What are some other examples where an approach that seems like the common-sense thing to do is actually recreating a problem that had been solved in some way?

Point of this question: internalizing what is wrong with the common-sense "obvious" solution is a very good way of developing an intuition for how and why to use the initially counterintuitive elegant solution.

+2  A: 

Hmmm..... let me think... what's with the foundation on which the web works - stateless HTTP on which many stateful frameworks have been built (ASP.NET, JSF etc.) that completely discard the stateless nature of the protocol? Well, not discard it in their implementation but discard it for their users - developers, who not even knowing anything about basic web elements try to pack megabytes of serialized objects into pages which leads to performance loss and tremendous consumption of traffic and server resources.

Would it fall into you conception definition?

Developer Art
Sorry, I don't really understand this example. It sounds like you're saying that using stateful frameworks on a stateless protocol has a large performance cost, but you don't explain the better way to accomplish the same thing. I think what you're saying is that these stateful frameworks make it **easy** for developers to do something the wrong way. What is that something, and what is the right way to do it?
Anton Geraschenko
@Anton Geraschenko: I believe this will be a long and protracted discussion, a forum or a blog might be a better place for it.
Developer Art
A: 

You're right that there's many examples of this with DVCS. The most common one is to use DVCS like Subversion by always pushing on any commit or going days without even bothering to commit.

RightFullRudder
Could you expand this answer for those of us who are DVCS-illiterate? If I understand correctly, DVCS solves the following problem: in a (non-distributed) version control system, a developer only gets the benefit of version control if she commits her changes to the repository. But in a DVCS, she can manage local modifications just as easily without committing ("pushing"?) them to a repository. Pushing every change and/or failing to commit (locally) is a misunderstanding of this aspect of DVCS. Do I have that right, or is there more to it?
Anton Geraschenko
Also, I've heard that it is possible to pull only certain changes that others have pushed. It seems to me that I would normally want to pull *all* changes. Am I misunderstanding a good idea here, or am I right to think that refusing changes is a rare occurrence? I guess I can imagine refusing a patch from an untrusted source, but would I ever want to accept *half a patch* from somebody?
Anton Geraschenko
Well in git, it is easy to break up a change set into different patches (git-add -p). I might want to accept *half a commit* if the commit it more than one patch :)
Gregg Lind