> Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing

> Yes, there are those that would refuse to rub wool because it's a voodoo step. Those people will never turn silicon into iPhones because they let not knowing stand in the way of creating solutions. My own objection would be: does it really work? If we can determine that yes, in fact, it does, then I want to know why, but I'd continue doing it until we know why. When you know why, you can make it better. Until then, you're still just shotgun testing. Not that shotgun testing can't work, but if you can do better, and you can afford the resources to learn how to do better, you probably should. I would agree the best is the enemy of the good enough, but also of the better--if all you know are so-called "best practices" and never deviate you'll never improve. You have to answer the question for your particular case though of whether deviations are likely to result in an improvement any time soon. I don't really understand why, in this particular case, some people would stop the method without a replacement, just on principle of not understanding it. This isn't the first case I've heard of such things though--I've heard of some developers on a team deleting large swathes of code they didn't understand, replacing it with something they wrote that doesn't even work nearly as well. (One of my roommates says for a robot project one of his teammates took apart a working breadboarded controller but still hasn't replaced it with anything.) > Solve a problem first, make it elegant second. "If you nail simple and fast, elegant is usually forced to come along for the ride.." ( http://twitter.com/#!/1/statuses/122368755962621952 http://twitter.com/#!/1/statuses/122368755962621952 ) I don't think elegance is at odds with solving a problem, but in general I agree that getting something working that's good enough now beats something that would have been better later. But not always, and possibly not even most of the time, as the time spent in the programming world rewriting and reinventing things shows.