I assume that you are already sold on using Adobe Flex for developing the front end of your next rich Internet application. As of 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 access 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 has 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 guestimate is that there is 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 first hand, because 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 do not want to move away from Java”. People are not convinced that adding Flex to their skill set can improve their marketability.
I hope that Adobe can bring the number of developers to a mil, but at this point in time, you’d be better off re-training your Java, C++, PowerBuilder or other developers.
Also, there are developers and developers. I mean that only a small number of developers in any programming language are professionals. Enterprises need well rounded Flex developers who understand Web application and are not afraid of SQL.
So far, Adobe did not invest in engaging colleges and universities with Flex. Students of computer science majors do not know about Flex. But according to my sources, the situation may change soon. 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 working on your project. I’ve seen six months old Flex projects in a poor shape.
”Why did you select this vendor?”
”They gave us the best deal.”
There is a way to check if the perspective vendor can deliver. If several vendors bid on your project, allocate an extra 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 in a cage. Do not be. Even though Flex has several application frameworks, think twice before entering the cage. This may be an 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 code you need to write manually.
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 second 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 have 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 importantly, to your business users.
So what’s my message to you, the Flex aficionado? Your relations with Flex will go through three main phases: falling in love, marriage and honeymoon, and daily hard work on making marriage work. The last phase is the most important one.
And…I really like working with Flex.
Thanks,
Yakov Fain