RIA

I had a serious epiphany with OOP, when i was first learning it, where i realized that the real power of object oriented programming is the ability to build your own language dialect. No longer are you forced to use abstract constructs to make up your application. When i start a project, i throw down the idea as physically relatable as possible on paper, and the next step is to do the same in stub classes in the project. This translates to boxes and arrows first, and then classes with names like Image and UserInputField. There is obviously already a Bitmap class and a TextField with an input type, but when i work, to keep myself in check and not lose track of the process, it helps me mentally to think of a specific input-field type rather than an input-field variant of another type. Long story short, this boils down to taking the tools i have available and labeling them for what use i have intended, both practically and mentally.

This ability to “bend the dictionary” is the #1 reason i am in love with programming, and probably why i can stomach doing it for a living at all. Design patterns are Good Things, but overuse and attitudes bordering on religion take this flexibility and bashes it with rocks until you’re back to square one;  Speaking another people’s language.

There has been a lot of discussion in the Flash community recently about fundamental choices Adobe have made when developing ActionScript 3 and the Flash platform. Joa Ebert has essentially torn the Flash compiler a new one over its lack of efficient compile-time optimizations, and Robert Penner has been advocating a change in how Flash handles events, driving him to create his own alternative to the native event model, dubbed Signals.

The compound effect of these two figureheads of the Flash community openly questioning Adobe’s wisdom has had a wonderful effect; Adobe have become noticeably better at responding to the community in recent years, but the questions raised by Penner and Ebert dig deep. When these guys ask what’s going on, their followers start asking the same questions. Twitter has been buzzing with this new found skepticism of the Flash platform and the design of the ActionScript language It’s forcing Adobe to question themselves. Only good things can come from that, and Adobe commentary at this year’s Flash on the beach indicate that the arguments have not gone unheard.

I am, however, worried that all this discussion of development fundamentals is taking the focus somewhat off the ball within the community. The vibe I’m getting is that getting the ball in the net isn’t as important as the flair with which you do it. I didn’t get any such vibe during the AS1/2 days, where the end product on display was what was being judged. Now, developers may feel like they are not doing a good job unless they are doing so while executing triple backflips.

My favorite boogieman example today is the notion that listening to enter-frame is bad because it generates a new event object on every frame update. As we “all know”, generating objects is the slowest thing you can do in Flash. This is, to me, a sign of a complete lack of focus. This is developers looking for a problem in the wrong place. A particular tweet i read went along the lines of “With all this talk about Events and enter-frames, i don’t know what to program anymore”. What a nightmare! To have your fundamental technique be thrown into question; It’s almost as though you are LAZY if you don’t change your way of thinking! This is not the good kind of skepticism. This is the kind that destroys productivity.

To attack this example in particular, the notion that enter-frame is slow is a reflective question; Perhaps you shouldn’t be relying on dozens of enter-frame events? Enter-frame events are used for real-time applications, and a game loop model and a has-a relationship gets around this quickly and elegantly with only one enter-frame in a single spot, as they have in game development for ages. A single enter-frame dispatch is enough to drive your entire application. That a single object creation 60 times a second is somehow a noticeable impediment to performance is flat out absurd.

To say that differently, you can safely ignore this whole discussion and get on with your work. The community is *riddled* with examples like this, from the broadest strokes (what design pattern to use, and if you don’t use design pattern X you are failing at life), to the most granular details (use –i, because i– is slower). When all you want to do is create something amazing, why should you have to wade through this minefield of needless exposition? I’ve seen the most fundamental advertising campaign sites with little more than a few video players and some transitions built in overwrought MVC-a-likes. It’s absolutely absurd!

This is something that has bugged me for a while, i felt like i need to get this out, and I’m hoping for some discussion. All this granular dissection of the most fundamental building blocks of our application is, in 99% of cases, a case of premature optimization and a complete waste of time. Our goal should be to develop quickly, efficiently and create good experiences for our users, not over-engineer.

I strongly urge developers to not let the multitude of senior developer prophets out there confuse you and take your focus off what actually teaches you real world lessons; getting the job done. I’m as guilty as anyone of this, and I’m struggling with it on a day by day basis. A recent example is an origami folding engine i spent 2 days over-engineering to cope with any and all possibilities, and Anders just sits down and does exactly what the job requires and delivers on time.

I hope this doesn’t read as some sort of attack on the science of programming and the brilliant people out there sciencing it up, but I’m starting to feel like we need more duct tape, scissors and cardboard.