/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Flash programming confidential, resolutions

Flash programming confidential, resolutions

I was recently hired to take care of things at a medium sized web production company while the regular staff was away. I reported my findings in a series called Flash programming confidential (monday, wednesday, weekend). This is a summary of the state of the Flash programming trade, and resolutions to what I see as the major problems and shortcommings.

Being a Flash developer today is a bit different from how it has been, with Flash being used more and more for complex websites which require more programming skills. Based on those two weeks I’ve put together a short guide for Flash developers on how to use the Flash plattform in a structured manner in order to create complex websites.

Background: I was hired for two weeks to take care of any Flash-related problems that might happen while most of the usual staff were on a “business trip” (quotes theirs). During that time I’ve had to deal with projects written by the three regular Flash developers, and it’s been like being back at programming 101. I’ve previously written about the experience in Flash programming confidential, monday, wednesday and weekend.

The series was not meant to point the finger at anyone, so I’ve deliberately not used any names or any other information that might identify the company or it’s employees. The purpose of my posts has been to report on the state of professional Flash development, and to show how bad developers can be a problem for a business. In this post I try to suggest what devlopers should learn in order for some of the problems to be alleviated. I also address the managers of web production companies, who should be more aware of these things.

The problem of collaboration

The main problem I have found is that in a project only the Flash developer knows how the Flash part of the website works, where the relevant files are and how to find things in the code. If that developer is ill, on leave or for some reason not at the office* there is no one who can take over without considerable effort.

Often development teams are composed of one designer, one Flash developer and one server side systems developer. Most from the latter category that I have talked with say that they would have no idea of how to even change a text or graphic on a Flash site because they don’t know how to find the relevant files, how to navigate a .fla, but also have no idea how the code in the .fla works. This can be a huge problem for an organization, a project should never depend so much on one person.

Much of the problem is because of the Flash development environment and how most Flash developers have learned to use it. Coding short snipplets on the time line i ok for banners and animations, but it makes a Flash site unmaintainable because no one but the original developer knows how it works.


There are a few things a Flash developer can do in order to make it easier for other Flash developers to take over a project, let other developers make simple changes, or for many developers to work together on the same project:

Code should be external

None of the Flash developers at the company I’ve been to had discovered the #include directive, nor that you can link a symbol to a class. Instead, they ranged from having code scattered all over, to having most of the code on the first frame and just some code deep down in symbols, to all the code (2300 lines!) on the first frame. None of these methods is particularly good. The last one is the best of the three because even for someone like me, who had no idea how the project worked, could scan through the code looking and find the thing I needed to change. However, it would still have been much better if the code was outside the .fla, with each logical part in its own file with descriptive names. It would also have helped if the code was better organized, but we’ll get to that later.

The lesson to learn is to have no code in the .fla, except for bootstrapping code if you have to. .fla’s should contain graphic assets, hand made animations, embedded fonts, etc. but not code. Instead have your code in separate .as files and use #include to link it in. Only include at one place, preferable one of the first frames depending on how you organize your main timeline.

If you know object oriented programming (more on that below) it’s even better to create movie clip subclasses and link those to your symbols. Instead of having code on the first frame that starts the site, create a symbol called Main or Site and a movie clip subclass (in an .as file) with the same name. Link that class to the symbol by opening the symbol linkage properties, check the “Export for ActionScript” checkbox and fill in the name of the class in the “Class” field. Then place an instance of the symbol on the stage at 0,0. Give symbols instances you place inside the “main” symbol instance names and add instance variables to your main class with the same names, you can now refer to any those instances in your main class.

Code on the timeline (except for perhaps stop() and other things that control animation) is a big no-no. It will make it more or less impossible to get an overview of how the code works.

By not having everything in the .fla, and especially not all over the time line, you will make it possible for other developers, even non-Flash developers, to make simple changes to your code without having to know the Flash development environment. It’s also a prequisite for many of the other suggestions below.

Version control

Use a version control system, for example Subversion. If you do you have to possibility to revert to an earlier version if your late-night-changes break things. You also share the project with other developers much easier.

To use a version control system requires that your code is in separate .as files, however. The reason for this is that otherwise you will have to check in the whole .fla each time, and you can’t see the difference between two versions. Version control systems don’t play well with binary file formats.

Object oriented programming

Learn how to program object oriented. Learn ActionScript 2.0, or perferably 3.0 if you can target Flash Player 9.

This is the most important point of them all. The object oriented programming methodology was invented to make it easier to program and model complex systems and websites are fairly complex systems. Learn it and use it, because it will help you.

I recommend reading Essential Actionscript by Colin Moock, it’s a good introduction to object oriented programming, one of the best I’ve read.

Code reuse

Maintain a library of reusable code. This library can be shared between all the Flash developers at the company making everyone’s life easier and simpler.

Try to make things as contained and reusable as possible. By this I mean that if you are making a scrollable panel with text, try to make it so that you could use it in your next project too, and try to make the scroll mechanism work with other things besides text. This gives you two things: you don’t have to invent the wheel for every project, and when the requirements change (and they will change) you can change the scoller, or the text panel, but you won’t necessarily have to change both, depending on the change, of course.


Try to make time to look at new things, tutorials, programming articles, books. Flash developers seem to have a lot to do these days so it might be hard to get the time over to read up on new things, but it is really, really important. Try to make your project managers and bosses understand that it’s a necessary investment. If you don’t get the time at work, spend half your lunch break reading blogs about Flash programming, or read a programming book on your way to work.

The reverse problem

I once wrote a fairly large website in Flash where it was known beforehand that another production company would take over the maintenance of the site, and a part of the requirements was that it was made in such a way that they could. At that time I wasn’t aware of the state of programming experience of Flash developers in general so I created something I though was well crafted, modularized and easy to maintain. I made it so that if no major changes were needed, the core wouldn’t have to be touched, all that was needed was to change the modules, or write a new module.

Some time later, when the other company had taken over I was asked to come to introduce their developer to the code base so that he could do some changes. I expected to be able to show how the site worked and how to modify the modules, or write a new one. It turned out that I had to start with explaining what a class was. The time I spent creating something that would have been simple for someone with programming experience to work with was completely wasted because the person who was going to work with it hadn’t the first clue how to read it.

Needless to say there were never any updates to the site, and a year after it went live it was replaced by a new site, developed by the company that maintained it. The rationale behind scrapping the old site was that they needed something that was “more dynamic”. To this day I’m still not sure whether they blame me for writing something that their developers thought incomprehensible, or that they realized that they just didn’t have anyone competent enough to work with it.

My point here is that the reverse of the problem can also be true. One company delivering something that another can’t maintain because there isn’t anyone skilled enough. How do you explain that to the client? How do you rationalize the need for a complete rewrite?


My suggestions may sound obvious, but from how I’ve seen Flash developers work, they are often not. If you think they are, you are likely not the kind of Flash developer I’m talking about (good for you!).

I think it’s really important that Flash developers start thinking about themselves as programmers and not designers, because they are not. The level of complexity in current Flash websites demands programmers that can design and implement systems, not hack together something that works.

My message is also in part directed at the managers: make sure your Flash developers know what they are doing, give them the opportunity to learn new things, make sure that websites are created in such a way that another developer can take over the maintenance.

* you have no idea how many times I’ve heard of programmers just disappearing just before a deadline. I think it might be the third most common reason why new clients call me.

3 Responses to “Flash programming confidential, resolutions”

  1. Sean Moore Says:

    Good read.

    One thing I wanted to mention is that Flash Developers should seriously consider learning Flex. IMO it’s a lot quicker to build ‘site’ sized applications (or RIA’s) with Flex vs. Flash. The Flash animations can be loaded into Flex to keep the ‘flashyness’ but the main application logic can be better managed from Flex Builder, especially when you put something like Cairngorm or PureMVC in place.



  2. Theo Says:


    Flex enforces structure and good coding habits, something very good for developers not experienced in writing larger applications or complex websites. Flash is very loose, not more than a language and a class library. It doesn’t give much support to the inexperienced.

    I’m happy you found this post, it got backdated almost two months, partly because most of it was written back then.

  3. Hannes Says:

    Good Posting. Can only agree.

Leave a Reply