Rich Rodecker’s blog on flash, flex, actionscript, javascript, and php, with a dash of randomness
Finding OOP business balance
or, “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.
| Print article | This entry was posted by rich on December 19, 2006 at 11:44 am, and is filed under flash. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 6 years ago
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.
about 6 years ago
While I’m sure some folks believe that you should always use proper OOP and design patterns, you should actually decide if they’re needed on a case-by-case basis. As you said, if you’re just building a one-off Flash experience site, hack it together, make sure it works, and move on. However, if the project is a larger application, or if you know you’ll need to come back to maintain it later, then you should probably spend a bit more time on planning and architecting. It’s always important to consider things like deadlines, budget, and any other factors that might affect your abilities to do things the way you want.
By the way, your font choice looks a little strange on my screen. It’s almost as if pixels are missing. It’s probably a weird combination of my resolution, my lcd monitor, and my font smoothing properties, though.
about 6 years ago
josh – hmm…looks ok on all the browsers i’ve checked it on, which one are you using? you’re the first to note anything like that.
about 6 years ago
As a designer using Flash, I totally agree with this post. Coming from a background of using Flash just to make things look cool its hard for me to appreciation the true power of OOP. I understand it in theory, but you’re right trying to implement it is something else. If it takes you more time trying to figure out how you are going to maintain/re-use code in the future than solving the problem at hand, I say its not worth it. Especially if you have not been promised the opportunity to implement a version 2 or future work that will re-use your code.
about 6 years ago
I agree to some extent. Clients don’t care at all about the code. If it works, and it works well (in regards to what they expect it to do), then they are happy. However that mindset doesn’t benefit us at all. Especially if we ever have to re-open a project for updates, or even worse, give our FLA files to the next development team.
I feel the thought of anything smaller then a flash application then “don’t worry about the code” is the wrong way of approaching development. I completely understand that OPP can severely over complicate simple tasks, but well organized classes that follow interfaces that you are familiar with will speed up repeat development in the future. This is especially so with small flash websites. Think about what most small flash websites contain: main loader/sub loaders, navigation, products/photos/items and news/content. Approaching a site with a OOP in mind allows you to re-use the code you wrote for the last site. Using proper getters/setters/encapsulation allows you to not even have to see the inner workings of the classes to implement them into a different site.
about 6 years ago
I’m probably as close to an OO/Design Patterns groupie as you’ll find anywhere. I love what they allow me to do. But when I’m hacking a simple project I just stick an if statement at the top of the screen for processing the form and have my queries in my views (I’m on the ColdFusion side, but the principle is the same).
OO/DP increases maintainability. If you need more maintainability, use it. If not, get the project done and move onto the next billable task!
about 6 years ago
yeah, i’m certainly not saying to avoid OOP, or frameworks. Normally they can drastically improve site development (i generally always develop with ARP myself). My point is know when to say when. I think if you’ve abstracted to such a point where someone else can’t follow your code without some documentation, that’s too far, even if it is conceptually “better OOP”.
about 6 years ago
that’s what I’m talkin ’bout!
about 6 years ago
“I think if you’ve abstracted to such a point where someone else can’t follow your code without some documentation, that’s too far, even if it is conceptually “better OOPâ€Â.”
Agreed. This goes even deeper then OOP. Coding habits like shorthand IF statements, although they save you a few lines, there is no benefit aside from the 2 seconds it takes you to write them.
I think programming is a perfect example of the age old “time is money”.
Do you sit down upfront and plan everything as much as possible, possibly saving time in the long run. Or, do you start coding and have the “we will think about it when we get to it” mentality.