15 August 2011
Given the time and the resources, building a stellar Flex team may seem an easy-enough task. The Flash platform, however, is an unusual beast—appealing to developers of very different backgrounds, ranging from old Flash Pro whizzes to grizzled Java veterans. Finding the unifying skills to put together an efficient and well-oiled team can be a daunting task.
This article is both for managers looking to assemble a team in the enterprise space, and for developers keen to refine their skills to suit large, complex projects. I'll cover some of the common strengths within the Flex community and show how these abilities can work together to forge a solid foundation for your new project. Following that, I'll focus on some of the key decisions your team will have to make—surrounding tooling, automation and best practices—as they get up and running.
Note: Projects of this size are bound to be influenced by many external factors. These include existing infrastructure within the organization, branding/style guides, supported tools and frameworks, current processes, and upstream systems, just to name a few. While the development team assembled will recommend the best tools for the job, many of the decisions will need to be advocated by a manager with the political will to champion what the team needs to build the best product possible. Indeed, even within the team, there needs to be constant access to the product owner who can provide decisiveness from the business if and when the team find themselves locked in a stalemate. Without these processes in place, the productivity of the team, and that the project itself, will suffer.
While every potential team member has unique specialties and interests, they all have inherent knowledge gaps as well. A great team should highlight all those strengths and improve on the weaknesses. Putting together the right elements to make the most of the platform involves aligning these strengths across the team and ensuring that the atmosphere is challenging, respectful and stimulating—thereby not only creating an effective product, but also improving the team's individual and collective abilities.
Here are a few of the key skill areas to focus on when building your team:
Note: These skills are by no means mutually exclusive; in fact, it's highly likely you'll have team members who exhibit many of these characteristics.
In addition to your all-star development team will be a solid User Experience (UX) component. I won't go into the specifics of UX here, as a thorough overview warrants its own article; however, there are two main players to highlight:
Note: A UX team coming from the web paradigm may not adapt directly to rich Internet applications (RIAs). Whereas a web site is typically static (with the exception of highly dynamic Ajax-enabled web-applications), Flex applications are stateful and do not require the reloading of a page to process an action. Some coaching may be required to transition an existing web team into RIA design.
Putting together your team is merely the first step. There will be many key decisions facing your newly formed team, and while everyone will have his or her own preferences and opinions, it's good to be prepared for some of the issues.
Here are some of the more significant decisions facing your team:
Aside from coding, standards may take the form of client/server APIs, XML schemas, build management, user experience, and documentation. These standards should be well defined and enforced across all practices and deliverables to ensure consistency across the project.
Another factor that may influence the decision is the variety of tools that integrate with source control. These include IDE integration (most major providers have Eclipse and IntelliJ plugins), code-reviewing software, and project management tools. The latter in particular are going to go a long way in placating those BAs who regularly pull hair trying to track project development.
While automated unit testing in Flex is well supported, integration testing is not. The fact remains that automated integration testing in Flex is still fairly fertile ground, and it's up to each team to determine if the benefits outweigh the costs. Often, manual integration tests—performed both by QA departments and the developers themselves—are sufficient.
One final aspect to consider is performance and load testing—that is, gauging both the responsiveness and capacity of the application, respectively. Depending on the business needs, this could be the purview of a single developer or, better yet, the responsibility of the entire team. Popular tools include HP's LoadRunner and WebORB's CloudPuncher.
There's bound to be some contention among your team over the system used for both build and dependency management (DM). Two of the main contenders are Ant (using Ivy for DM) and Maven (using Flexmojos, the de facto Maven plugin for building Flex and AIR applications), both of which come from the Java world, and both of which have their pros and cons. Keep in mind that the goal is to have a robust and flexible solution; whichever way you go, ensure everyone is on board and aware of the duties required.
That said, the more modern frameworks that support inversion of control (IOC), such as Robotlegs and Parsley, are both mature and battle-tested providers that add a lot of value managing client-side architecture. Regardless of the decision, it behooves the team to identify, outline and adhere to a consistent methodology.
Flex attracts both the modern and the adventurous developer. Putting together a well-balanced team of professionals for this burgeoning platform can take some work-backgrounds and experiences differ considerably among the community. Focus on covering the key areas of the platform and you'll create a solid product leveraging the best that Flex has to offer. Be mindful of the obstacles and hurdles early in the game, and you'll be securely placed to release, support, and maintain your application well into the foreseeable future.
For more information, check out Adobe's comprehensive list on Flex-related products.