In 2001, I was part of a team within Macromedia that introduced the ‘MX’ platform to the marketplace. A key advancement was that the Flash player, previously just a rich rendering and animation engine, could now be used to build creative and expressive applications. This began the current Web 2.0/RIA paradigm, in which application focus is on efficiency and effectiveness of the user through data visualization and usability. While this original platform was revolutionary, it required engineers to use Flash to develop applications, and many found using a visual drawing tool too radical to embrace. This led to limited adoption of the technology, despite a general understanding of the value of building engaging applications. It wasn’t until Adobe licensed an open source version of its Flex 2.0 product line in 2007 and introduced Flex Builder that we began to see wide spread adoption of the technology as the predominant tool for building Web 2.0 applications.

Even now, with the release of Flex 4, misconceptions abound regarding Flex, and there has been a general reluctance to build Flex development teams internally. This series of articles intends to debunk mistaken notions and help organizations realize the power and accessibility of this skill set. To begin though, we need to understand that we can, and why we should, build an effective team.

We live in an experience-driven economy and people now expect elegant data visualization and efficient, intuitive, usable interfaces online. The expectations are such that organizations that do not embrace the current paradigm risk alienating or losing consumers. However, companies still avoid building Flex teams because of some enduring myths. These are that Flex resources are scarce, and that teams need years of experience, must be large, expensive, and comprised of all-stars. However, I’ve found that, with a few exceptions, the opposite is generally true and that nearly any organization can afford to build an effective team.

Flex is still at a premium relative to other software development languages, but it is not as scarce as it used to be. In fact, 2008 saw a huge spike in Flex resource adoption and a key indicator is that major outsource firms such as Tata Systems and InfoSys began to offer this resource. The numbers of Flex developers with two or more years of experience are still relatively small, but this is due to the youth of the language and shouldn’t be seen as an indicator of overall resource availability.

Flex experience is important, but at Twin Technologies, we look for people who understand the big picture: building Rich Internet Applications is about creating the best user experience. Improved RIA and Web 2.0 development are both responses to users’ increased expectations. Usability and user interaction are how we measure and define application interaction. The application should come to meet me rather than requiring that I navigate through a series of browser hoops to find what I need, and I want to see this same proactive outlook in potential team members. Understanding the relevance and importance of why you’re building an application often trumps specific experience. We have found that a base knowledge of Flex coupled with an understanding of why to use it is more important then specialized experience.

Our experience has been that most teams can be relatively small, comprised of 3-5 people. Final team size is really based upon the number of things to do, divided by the output of given resources. In addition, although people want a team of all stars, we’ve found that a small team that mixes junior and senior levels of experience is most cost effective and efficient. Many mangers look at the output of a junior resource and compare it to senior or mid-level resource; we think this is the wrong perspective. Instead, we’ve discovered that junior members combined with senior members on our teams nearly double the productivity and effectiveness of our senior members. There’s a positive mentoring element at work here also. Junior and mid-level team members perform the tactical work, freeing your senior or expert to concentrate on strategic approaches to building the solution. This just makes good business sense. And there’s the obvious economic benefit: two seniors cost $200/hour, but if I have a junior/senior blend, that cost becomes $133/hour. Ideally, you have a situation where your mid-level and junior team members are doing most of the work, with seniors providing guidance. You'll also be growing your internal team of Flex resources by offering juniors the opportunity to work closely with seniors and experts.

There are times when experience does matter; for example, if you need profiling/scaling, custom visualization, or SDK modifications, then you need an all-star. But remember, an expert is unlikely to stay on a project the whole time, so it’s important to determine your requirements at the outset. Now that we know we can build a team, it’s critical to understand your needs so you can identify the right experience, which is what we’ll be discussing in our next post.

Read more from Ben Elmore.