As developers, we like to put our heads in the sand. We’d be much more successful if we didn’t. Let me explain. When I first learned about basic object oriented programming, I was suddenly disgusted with functions and code that wasn’t an object. I got over it. When I learned about composition over inheritance, that became the standard by which I judged

all code, mine included. It became my fixation. I got over it. When I learned about design patterns, I wanted to apply them to every situation, and I wanted to do it right and apply them exactly the way prescribed in the pattern. I got over it. When I learned about optimizing code, I spat on for loops that didn’t initialize the length first, I kicked dirt around static methods which are shown to be slower (in the language I was using) than instance methods, and I generally despised any type of code which I read on a blog was slower than an optimized alternative. I got over it. I could go on with dependency injection, abstraction, database normalization, and on, and on, and on. I hope I continue to get over over-applying new knowledge. I’ve always wanted to iterate over and rewrite again and again pieces of code, reusable libraries, and other gleaming nuggets I’ve done in the past which could be more perfect. Even faster. Even better. I’m getting over it. In the last few months I’ve been working with some very bright and pragmatic developers. They’ve been teaching me, unbeknownst to themselves, to look at the big picture and to get my freaking head out of the sand. Just because instance methods are slower than statics doesn’t mean you shouldn’t use them. Creating an object is slower than calling a method, but should we throw OOP out the window and stick with functional programming? Messing up the Flyweight pattern (or even heaven forbid, our blessed MVC pattern) by altering it from the original and all knowing gang-of-four specification doesn’t end-of-life your product before it’s out the door. What keeps your product from releasing is rewriting it, or pieces of it, over and over again. If it works, DON’T FIX IT. Only optimize if your application is too slow for your users. And then only optimize the slowest parts. Next application you write you can do it better, but freaking finish! Clean up and refactor as you add new features for your users. Don’t waste time redoing anything from scratch unless its complete junk. And if you wrote it, figure out why you’re writing complete junk in the first place and fix the root of the problem. I’m writing a library in Javascript for HTML5 applications that I know will make many Javascript developer weep. It flys in the face of all the wisdom and standards that they’ve read about on their favorite blogs. But it will make developing applications easier and more maintainable. I know the rules, and thus I know how and when to break them because I know why they were established. I’m still watching the development of Reflex, the Flash component library my brother is involved in (I’m not actively participating anymore). They’re fighting against head-sand-itis both externally and internally. Project supporters may disagree with things proposed because it’s not right, or it’s not as fast as machine code. Internally with themselves they’re disgusted at breaking precious programming rules. Finally they’re starting to let ideals slide because progression is so slow. Eventually, I hope, they’ll raise their sites to the end goal and do what is necessary to reach it. Even if it means using brains instead of rules. (no offense to any individual person or the general group, we all struggle with it, we’re developers) The rules are generalities, guidelines to help us until we understand the principle behind the rule well enough to make our own decisions. Understand your natural tendency to over-apply and work against your nature to be more pragmatic. May we all work on seeing the big picture, understanding the principle behind the rule, and creating great experiences for those who will use our applications. I’m certainly the pot calling the kettle black on this.