Finding OOP business balanceor, “This over-abstraction has got to stop”.
Over the past few years of being a flash developer, I’ve ridden most of the major waves as far as flash/actionscript goes. Went from tweening on the timeline, to tweening using code, to gathering up all (or as much as I could) of my code on one frame, to using classes, to using OOP, to using design patterns, to using frameworks.
On the business side, I’ve gone from a place of being an employee and collecting a paycheck, to freelancing and trying to parlay that freelance career into a business. One of the things I have become acutely aware of in that time is the time-to-money ratio for projects. Now, that doesn’t just mean that my time equals money, but also that means how I could make the most money in the least amount of time.
Design patterns, and to some extent, frameworks, well, they are the double edged sword of the programmers world. The can provide an elegant solution to a problem, but there’s also a clear cost to implementing them. They add a layer of abstraction to your code, which means more time spent adding it in there, and more time spent trying to follow the abstraction when reading the code.
Is all that extra abstraction worth the time spent on it? That’s up to you decide. There have been times when implementing a particular design pattern has saved the day. However, I have found in many of the flash sites I have worked on, it’s not. Does the client care that you used ‘awesome’ OOP skills? No. Does he care that you delivered the project on time? Yes.
Again, I’m speaking of flash websites here, not flash applications. Yes, I know that most flash websites nowadays can almost be viewed as mini-applications, but I have the point of view that pretty much all flash sites are one-offs. When application goes from v1 to v2, you’re pretty much extending the core app. When a flash website goes from v1 to v2, it’s usually a complete rewrite.
With that being said, it’s in my best interest to complete the project as fast as possible, get paid, move onto the next one. Jesse Warden Has a great post here, in which he makes a similar to the point I’m trying to make. In that post, he refers to a set of priorities in his projects, listed in order of importance :
- Deadline
- Creative
- Bandwidth
- Maintainability
I totally agree with that. It’s easy for programmers to get too carried away tweaking and re-tweaking, abstracting until you can hardly follow what’s going on anymore, much in the same way that designers can easily lose themselves shifting thing around a few pixels in a psd. The difference is, tweaks to a psd can take lace relatively painlessly. Tweaks to an over-abstacted web site might require taking time to figure out and trace out the logic, and it may involve possible editing multiple classes, which may in turn effect other classes.
To wrap it up, I guess I’m just trying to say is, don’t make it harder than it needs to be. Keep things in perspective, because like I already mentioned, there’s no bonus points for style to client that has no idea what a class actually is. And _root != evil, i don’t care what anyone says.
I completely agree. My first rule is, “go with what you know.” If you see a clear path to the completion of the project then take it. I’ve also found that I favor composition over inheritance. After each project I’ll have a larger core of generic utilities that will help make the next project that much easier.
And you’re right. Most Flash sites are one-offs. The project specific classes will probably never be used again. Not even in a version 2.