I'm writing a game in JavaScript for fun (I'm almost done, it'll be out within a few days). I've written dozens of games in traditional desktop languages, and I've written a lot of JavaScript designed to make user interfaces prettier, and I've even written some useful JS tools -- but this is the first time I've written a full application in JS complete with complex hierarchical entities. That is to say that I've never had to care much about the fact that JS more or less supports OO architectures before. I could have made this an opportunity to learn about OOP in JS, but I didn't. Instead I wrote the game basically without using (custom) objects at all, resulting in some redundancy and confusion. I did this because it was fast and easy and I already knew how to do it. The code's a mess, but so what? It works. It's good enough. I had fun, and I'm about to ship.
But I have this little note at the top of main.js:
/** * TODO: * - Refactor to be prettier. */
It's almost the last TODO left before the game is complete. And I'm not going to do it. The game works already, so why should I spend precious hours rebuilding it all just in case one day a Haskell-loving purist* scoffs at my ineptitude? This is not the kind of thing I'm going to come back to in a few months unable to remember how to fix a mission-critical bug. Time to push it out the door.
I might write another, much more complicated game in JS+HTML5 after this. After all, there's at least one contest coming up. Having written a game in JS now, I'm sure the next one will be much better architecturally. But even the best programmers sometimes need to take a step back and just write something fast and dirty sometimes. It's hard not to get caught up in doing things right instead of just getting things done.
* Don't get me wrong -- I have nothing against Haskell-loving purists. I learned OCaml from Benjamin Pierce and later helped Stephanie Weirich teach it. In programming projects I usually insist on carefully following coding standards and writing thoughtful, intuitive APIs because I believe in laziness, impatience, and hubris. But over-engineering doesn't help anyone. Users don't care why or how it works, they only care that it works; and especially if your users are not developers, there comes a time when the effort of making code pretty is just not worth the reward.