At the end of 2006 I wrote in a blog that Flex programmers should sit tight, improve their skills and wait till 2008 – the year of their fame. The year of 2008 is here, and Flex people are in big demand. Two years ago, Flex community was more of a ghetto where most of the Flex programmers knew each other, but situation is different now. The number of Flex programmers is increasing, and this population evolves similarly to what I’ve seen in the Java camp in the past.
The main concern of any project manager is if there are enough people in the pool of Flex developers to staff the project. Yes, there is a pool of Flex developers, but let’s look at the creature called “Flex Developer” under the microscope.
Presently, I work for two clients from different industries; both projects are redesigns of existing Java applications. One project has a small number of Flex screens but very serious requirements for the communication layer. The other project has lots and lots of screens with LCDS on the back. Both projects require three types of Flex personnel:
1. Flex GUI developers
2. Flex component developers
3. Flex architects
The first group is people who can create the view portion of the application. This is the easiest group to get into if you already have some programming language behind your belt. The rumors about high consulting rates plus work of educators and technical evangelists create an impression that working with Flex is easy – just drag and drop components on the screen, align them nicely and write the functions to process button clicks or row selections in the data grid. Sort of a Visual Basic of the Web. These skills are easy to obtain, and you can expect a crowd of people there, but do not expect high pay rates in this segment. If something is easy to learn many people can master it, and savvy project managers either outsource this job to a third-part vendors or send their own developers to a one-week Flex training class.
GUI developers interact with Web Designers that come up with the look and feel of the screens, which can be presented as a wireframes created in Photoshop, some third-party tool or even in Flex itself. But even in the latter case, GUI developers should not start implementing screens until approved by a Flex component developer or an architect.
While this is a right way to start Flex career, you definitely should consider moving to the second group and become a Flex component developer. This title is awarded to people who know everything that GUI developers know plus object-oriented and event-driven programming. Knowledge of design patterns helps, but be careful here. Especially it applies to people coming from the Java world. Do not abuse MVC. Think out of the box. A screen created by a Web designer has to be scrutinized and redesigned into a set of components that communicate with each other. Applying the Mediator pattern to the initial wireframe is a good start as I’ve described in this blog .
Also, keep in mind that even though the syntax of ActionScript 3 looks very similar to Java, it has provisions for dynamic programming and you might not need to create tons of well defined objects as in Java.
The third group of people knows everything the first two groups plus they can see a big picture. They know how to build the entire application, how to communicate with the mid tier, how to structure your project, and how to make communication between reusable components, views and the persistence layer the most efficient. Flex architect are people who’d never suggest using a framework for creation a simple Video player as done in this blog. You do not gain these skills after a week of training, but you build them on top of your prior experience in other programming environments and by constant studying.
Not every Flex developer can be profiled as a member of one of these three groups. In smaller teams, one person may wear two hats: a component developer and an architect. If your team has decided to use one of the frameworks on top of Flex framework, you may wind up with a new type of team members that can be called framework coders. In this case it is assumed that this XYZ framework provides a structure that will take care of inter-communication between components, and coders just need to put their model, view or controller objects into the right directories, buy popcorn, press the button “Play” and watch the movie. This may or may not work as expected, but you may find out about it later in the game. If you are not lucky and the film got stuck in the projector and caught fire well into the movie, get ready to ask for an extra budget for a new project called “Removal of the XYZ framework”, which reminds me of a good old joke.
A poor man comes to the rabbi complaining that his family has only one small room, many kids, and almost no money. The rabbi says, “Take all your money, buy a goat, and keep the goat in your room. Come back in a month.”
“But, rabbi, we don’t have enough space even for us,” the man said
“Just do what I say,” the rabbi replied.
A month later the man comes back complaining that the goat smells and breaks everything.
“Sell the goat and come back in a month,” the rabbi tells him.
A month later the man comes back to the rabbi with flowers.
“Thank you, rabbi! We’re so happy the goat is out, now we have more room and some money from selling the goat!”
If you are considering adding Flex to your set of skills, it’s still early in the game and you can join the fast growing Flex community. Decide which group of the Flex developers looks most appealing to you. Set a goal and go for it. Be what you can be.
Yakov Fain
ksilz said,
January 13, 2008 @ 4:48 pm
When you said that “Web Designers [...] come up with the look and feel of the screens”, does that mean they really design all screens? Or do they just design the look and feel of some sample screens, and the Flex GUI developers decide the layout and content of all screens, based on the look and feel?
Karsten
Yakov Fain said,
January 13, 2008 @ 5:30 pm
Web designers actually design screens, and they will actually fight with you if you decide to change it.
The times when a developer just throws a couple of green buttons, a yellow datagrid on a window with a red background are over, hopefully.
Well thought of color schemes and gradients, CSS files enforcing the same look and feel of components and pixel-perfect positioning on the screen. Last week, the Web designer called me into his office complaining that I had a two-pixel space between components of one window instead of one. I said, “I’m sure I allocated just one pixel there”. Without thinking twice, he brought my screen to Photoshop or something, magnified that screen area 10 times and showed me a two-pixel gap there.
ksilz said,
January 13, 2008 @ 6:19 pm
Thank you for the clarification!
Bjorn said,
January 13, 2008 @ 7:10 pm
“Two years ago, Flex community was more of a ghetto where most of the Flex programmers knew each other”
That was funny : )
extra budget for a new project called “Removal of the XYZ framework”.
The good old XYZ framework eh..
It seems certain XYZ frameworks are getting a hammering from a lot of respected developers over the past few months.
We have yet to ask for that extra budget yet.
In defense of application frameworks I must say that it is easier to get developers up to speed on large projects that use well documented frameworks.
Yakov Fain said,
January 13, 2008 @ 10:43 pm
“it is easier to get developers up to speed on large projects that use well documented frameworks.”
Nice joke, Bjorn!
Let’s see…In Flex framework, to use HTTPService when the user clicks on a button, I just need to call send() on the button click and specify two functions to handle success and failure. Let’s call it difficult.
Here’s an easier way to do the same thing that’s offered by an XYZ framework: write a half dozen of ActionScript classes, re-route your click event through a couple of Singletons apply a command pattern – create commands and register command handlers, write a Delegate class and hide there that very same HTTPService. Do not forget to implement the proper interfaces, and if you did everything right, then XYZ will return you the result through a bound control . It’s sooooo easy to get developers up to speed.! And this is a simple case when everything is sitting in the same little application. No modules. Not more than one event handler per command.
This is what happens to people who are developing frameworks while intoxicated by Java Struts framework. But if I can kinda understand (not endorse) people who developed Struts – at least they built a framework on top of the raw language – it’s very hard for me to accept a framework built on top of another framework.
Bjorn said,
January 14, 2008 @ 12:39 am
“it’s very hard for me to accept a framework built on top of another framework.”
If the framework is intended for use with Flex then what’s wrong with making use of Flex features.
Modules was not difficult. Flex 3 helped alot.
We have an application at the moment using AMF0 remoting and we are looking at migrating to BlazeDS soon.
Due to the separation of concerns in our client side architecture replacing the AMF0 delegate library with a new AMF3 Delegate library is not very complicated.
For sure making and handling HTTPService calls in a mediator is quicker and easier to code, but it would require a more delicate handling of the situation if a change like the change I proposed above was required.
If I get a new guy to write a cairngorm app once, he knows the sequence.
It’s not rocket science and it’s a repeated process.
Introduce code gen and there’s your standards and convention in place.
For most of the new guys these frameworks seem intimidating the first day, by the end of the week, they’ve built the first simple app.
The week after they already feel comfortable to get their feet wet in the big pool.
Yakov Fain said,
January 14, 2008 @ 7:48 am
Bjorn,
1. Even if developers will grasp how to write code going through all these hurdles required to locate a hidden service, this process will litter your application code with lots of unnecessary objects. Becide, the code is being read a lot more often than written. No problem, a new hire will spend a week ($500*5=$2500) and will be comfortable too.
Oh, btw, you have to register one command per an event. What if I\’d like to have two handlers for the same event? I know, you can find a workaround pretty fast.
Last week, my client that uses modules ran into another issue – they\’ve noticed that re-visiting the same screen leads multiple firing of the same event, which substantially affects performance. Oops…You have to have only one controller per application…no controllers in modules.
Anyway, this blog is not the right place for discussions of the pros and cons of Flex framework. We (Farata) are planning to create and publish a couple of demo applications that will illustrate how to create the same app with and without frameworks.
joeflash said,
January 15, 2008 @ 12:35 am
Your conversation on the three types of Flex developers reminds me of a whitepaper I just write regarding clarifying the new roles of developers who work with the Flash runtime. Your three designations sounds remarkably analogous to the three categories of the Flex developers I’ve come up with, based on my own personal observations:
1. Flash Developer = Flex GUI developers
2. Visual Flex Developer = Flex component developers
3. Enterprise Flex Developer = Flex architects
Regarding the framework argument, well I’ve only just started messing with frameworks on a large enough scale to warrant using commands and delegates and that sort of thing, as I’m coming at Flex from an ActionScript 3.0 background, so take this for what it’s worth. But it seems to me that an architectural framework on top of the Flex framework is useful for abstracting Services from Commands from Views, in other words creating more abstracted MVC architectures so that a) you can compartmentalize your workflow in large teams, and b) if you need to change how the application is connected or how the model is updated, you don’t have to rewire your entire application. Trust me, I’ve done and seen enough procedural code in my day to know the value of coding to framework of some kind. Like someone said in a previous post, it’s the difference between an application framework and an architectural framework. From what I’ve experienced thus far, you need both to create an app of any scale, though I could be wrong.
Yakov Fain said,
January 15, 2008 @ 6:50 am
Joe, We’ll create and publish a mini demo application that will show how to separate things without using using overly complicated frameworks. When you’ll see it, you’ll believe it
joeflash said,
January 15, 2008 @ 11:32 pm
Aha! But you’re still using an architectural framework on top of the Flex component framework, right? (Not unless you want to re-invent the Flex components from low-level AS3, and what’s the point of that?) there’s frameworks and then there’s frameworks… but I’ll shut up now
Anatole Tartakovsky said,
January 17, 2008 @ 5:29 pm
Bjorn,
You might want to go back to the roots of OO for most of the cases. For example, in case of AMF0/AMF3 all we do is we use our own RemoteObject. It seamlessly switches between AMF0 and AMF3 implementations based on the settings coming from html wrapper. By placing simple factory layer and coding application code against IRemoteObject interface containing all the methods of the original one we solve migration and protocol issues. Instead of making them explicit for the application developer we have single Flex expert per projects that absolves APPLICATION developers from ALL system issues.
Regards,
Anatole Tartakovsky