I assume that you are already sold on using Adobe Flex for developing the front end of your next rich Internet application. As of the end of 2007, it’s the best choice you can make, really. But after spending almost two years working on real-world projects that involve Flex, I can see a number of roadblocks that prevent Adobe Flex from being the only solution for RIA.

1.    Flex 2 is not a RAD tool – plan accordingly

If you made a decision to go with Flex after attending one of the sales presentations, you may get an impression that Flex is a magic wand and anyone can quickly create an application that will get the data from a remote computer and display the data using one of the nice looking components. Yes, Flex makes lots of things easier, but there is big difference between creating a quick prototype and delivering a production-quality well-performing application.  Next year, Flex 3 will offer some RAD features such as code generators for various tasks, which will really help.

Learn from the Ruby on Rails, which can get you started with a CRUD Web application in no time, but then it requires experience and hard work for turning a prototype into a product.  

You need to create a realistic project plan. Do not just accept the statement like “You can do things in Flex faster than in Java, so two months should be enough for this project. OK, let’s make it three to be on the safe side.” Sounds familiar?  It’s a pretty dangerous approach. Identify each screen and its components, try to assess the time and complexity of each of them, allocate resources, make the learning curve adjustments, and allocate ample time for  testing (dynamically typed programming languages require more time for testing as compiler are as not as helpful as in Java or C++).

Add up the times required for each of these components/processes and then add a 30% extra time to account for unexpected.

2.    The pool of Flex developers is still limited – re-train your own developers

Two years ago Adobe had announced that they expect to have one million of Flex developers by 2010.  I have my reservations.  I do not have any official statistics, but based on the number of Flex developers participating in various online forums, blog and book sales statistics, my guesstimate is  that there are under 100K Flex developers, and only a small number of them are IT professionals.

Adobe has achieved some good results in getting Flex into enterprises, but they are still facing resistance from Java developers. I know this firsthand as I work on the Flex/Java projects, mentor and train developers and a typical attitude of a senior Java developer is, “I can do all this in Java.” 

The other statement I hear is this: “I don't want to move away from Java.” People are not convinced that adding Flex to their skillset can improve their marketability.

I hope that Adobe can bring the number of developers to a mil, but at this point, you’d be better off retraining your Java, C++, PowerBuilder or other developers.

 Also, there are developers and there are developers. I mean that only a small number of developers in any programming language are IT professionals. Enterprises need  well-rounded Flex developers who understand Web applications and are not afraid of SQL.

So far, Adobe did not invest in engaging colleges and universities with Flex.  Computer science majors do not know about Flex. However, according to my sources,  the situation may soon change. Expect some major announcements regarding popularizing Flex in academia.
      
3.    Check the credentials of the vendors you hire

This is a tough one. By checking credentials I do not mean comparing the quality of PowePoint decks and skills of sales people of the vendors offering Flex professional services.  Ask them to do stuff before letting them work on your project.  I’ve seen six-month-old Flex projects in poor shape.

”Why did you select this vendor?”

”They gave us the best deal.”
 
There is a way to check if the prospective vendor can deliver. If several vendors bid on your project, allocate an extra money in the budget and hire each of the bidders for two weeks. Ask them to create a working prototype of your system. In two weeks a good Flex developer can create an application that may resemble your future system. Hire the vendor who does the best job. This will require some extra money upfront, but in the long run the savings can be huge.

4.    Be careful with frameworks – use components

Developers that come to Flex from Java start looking for an application framework. They are ready to be confined to a cage. Don't be. Even though Flex has several application frameworks, think twice before entering the cage. This may be overkill for your project and may slow down the development by introducing yet another tool to learn. Stick to small self-contained widgets. Use data-driven components. Apply code generators that minimize the amount of error-prone manual coding.

5.  Architect your applications properly. Avoid monolithic solutions

Recently, one of the project managers told me, “We’ve chosen Flex to avoid page refreshes, but our pilot application requires 10 seconds to load and another 10 seconds on each screen change.” After a quick analysis, it was clear that the application has been improperly architected. It was one large swf file, no libraries or modules had been used, session management was not properly done, and caching of the reusable data was not present.

Is this Flex’s fault? Of course not, but try to prove it to your architecture committee or, more important, to your business users.

What’s my message to you, the Flex aficionado? Your relationship with Flex will go through three main phases: falling in love, marriage and honeymoon, and daily hard work on making the marriage work. The last phase is the most important one.  And...I really like working with Flex.