Today I came across a very interesting post by Yakov Fain, who comments on staffing a team for your Flex project. In it he divides the different kinds of roles and skillsets necessary for a well-balanced team into three categories:
- Flex GUI developers
- Flex component developers
- Flex architects
- Flash Developer
- Visual Flex Developer
- Enterprise Flex Developer
The interesting thing is that Yacov comes from a background as seasoned Java programmer and project manager with substantial experience in forming teams of Flex developers, so you gotta know he’s eaten the dog food an drunk the cool-aid on this topic, to mix metaphors. Whereas my perspective is as a Visual Flex Developer/Flash Platform Developer, having been on a few such Flex development teams in my consulting work over the last few years, and seen them succeed or fail in part based on the presence of balanced skillsets as described by both Yacov and myself.
Yakov’s assessment nails the staffing situation on the head, and feels validating when I say to a prospective client (in different words), “Hey that’s great that you have a team of Java developers who have just picked up Flex, but don’t you think you might need a few Flex developers (like me) who have actually grown up with the technology and know how build a decent interface?” ;)
Of course the converse can be true, like when I’ve been asked to build a full-blown data enabled enterprise application, and I have to tell the client, “well, you might need a Java or ColdFusion developer on your team who knows a bit more about these things than I do”. I am not ashamed to admit it: (for the moment) I am not a server-side enterprise developer. Tools for the job.
I also occasionally meet Flash Developers or Visual Flex Developers who think that they need to learn Java and enterprise frameworks just to compete in today’s Flex development marketplace. I myself struggled with that question until quite recently, convinced I had to go out and get a Comp. Sci. degree just to get ahead. But in the past six months of consulting, the market has proved otherwise, as clients find my depth of experience with ActionScript 3.0 and the Flash Runtime (amongst others) to be an invaluable asset. I’ve even ventured into the realm of architectural planning on my last few projects. So there is hope yet for us “Flash boys” (and grrls ;)).
So now I tell some of my colleagues still struggling with the issue of “upgrade or die,” that in this rapidly expanding market for Flash and Flex Developers, there is a place for “Flash workers” of a wide range of skillsets. Thermo will open up that vista even more when it comes out.
It’s all good. :)
Actually it isn’t. But some people think it is. I’ve heard the argument a few times, mostly by developers who have a chip on their shoulder about designers, as demonstrated by this fictionalized conversation with a developer about Thermo. (I gather the names have been changed to protect the guilty ;) )
Normally I don’t bother commenting on fictionalized arguments, it reeks a little too much of he-said she-said flamewars one sees so often. But I’ve heard this argument before, and not just about Thermo threatening the livelihood (read: dominance of) developers over designers, so I felt compelled to add my 2c.
Personally I think the whole argument of whether UI is the exclusive domain of either the designer or the developer, is a waste of time. I used to be a designer, trained in design, went to art school, yada yada. Back in ‘97 no one doing web apps knew anything about UI design on the web. We were all doing it by the seat of our pants. How did most of us learn UI design? By observing what works, what we personally find usable, as well as reading about emerging standards, and emulating that.
Now that I’m a developer through and through, and see things from a more code-centric viewpoint, I notice that although a lot of designers are trained in the tools they use, and are generally very good at design, many of them aren’t any better trained or experienced at UI design than a visually-oriented developer. So there’s a misconception out there that a) all designers made good good UI design, and b) all developers make bad UI design. I’ve see absolutely horrid UI design by very experienced people on both sides of the fence.
As a developer trained in design, I am not shy at tackling a UI design, and do a pretty competent job at it most of the time, but I’m very clear that I’m not an expert in Interaction Design. If an enterprise level app were dependant on my UI design, I would definitely get an UI/Interaction designer on the case. Unfortunately this kind of approach seems to be lacking in both RIA designers and developers alike. And most of it, I think, is simply because traditionally, it has been left up to the “creative person” on the Flash project team to do any of the visual stuff, or to the “deseloper” to manage both UI design and development. For small to medium-scale Flash projects this generalist approach works well; but when you get into large scale Flex projects with dozens of people on a team, specialists will need to be brought in, if for no other reason than to guide certain aspects of the architecture, whether it be visual or data-oriented.
And really, so what if Thermo produces code that needs to be tweaked a little to integrate within a larger project framework? It’s not like we’re talking about designing an HTML site in Word or Front Page or anything: Adobe is well aware of this concern, and is addressing it. And would that not give more work for the developers to do, not less? Developers who feel threatened by Thermo need to get a clue. And clients (or designers) who expect to develop full-blown data-enabled applications in Thermo without a developer are also out to lunch. Tools don’t make good RIAs, no matter how sci-fi they get. Only a good team can do that.
But Thermo might, just might, enable the fledgling “one person web shop” to pump out a few decent applications for Acme Co., or a enterprise RIA project development team to shave the time required to skin and visually design a Flex/AIR app.
I guess the point I’m making is that neither the “designer” nor the “developer,” or even the architect or the interaction designer, should be in charge of the UI design to the exclusion of other people’s input, even though most large teams have a hierarchical structure. It’s got to be a team effort; the moment you start posturing and “excluding” specialities as this piece demonstrates, your project is doomed to failure.
This is such an obvious axiom of RIA development, I wonder if the entire piece was intended as satire, to illuminate just how ridiculous the designer/developer divide really is.