A very interesting question, or rather comment, was raised a few weeks ago in a LinkedIn discussion titled,
“Why Am I in Demand?” - Personal Branding for Mature Workers
The problem with this question, other than being a blatant grab for eyeballs, is that it’s not targeted in the least towards the Flash community. But it does underlie a perception I’ve noticed amongst some Flash designers & developers who may be just starting out, or are looking at stepping up their profile in the community and the job market.
I’ll save you the tedium of watching this video blog: according to the author, there are 5 questions you need to ask yourself:
1. What makes me tick?
2. What can I deliver?
3. How do I make my workplace better?
4. Why am I in demand?
5. Why should you hire me?
First, if you’re interested in becoming an office drone, with a job as exciting as the monotone delivery of the author’s video blog post, then by all means answer these questions. But if you want to have a kick ass job or a freelance business that you’ll love, ask yourself this:
1. How well do I communicate, verbally and on paper?
2. Do I have the chops to get the job I want, and if not how do I acquire them?
3. Do I care about sharing my discoveries and fostering a sense of community?
Second, the very idea that a person would be reading a blog dedicated to “Personal Branding for Mature Workers” is just wrong. I’ll tell you why:
It doesn’t matter how old you are in this industry. That’s a myth.
And it’s codenamed — are you ready for this? — Stratus.
Gosh that seems familiar… isn’t there already a product with that name? Why yes, it’s Status, Adobe’s RTMFP service.
You’d think that if someone were to introduce a product using Adobe’s tools, they could at least Google whether it had been taken.
Maybe next time they should use a codename generator ;)
There is no doubt: making it as a commercial component maker is a tricky business, what with open source competition on the one hand, and Adobe being possible competition on the other. Now that we’ve defined the kinds of commercial components in the previous post, with these roadblocks, how do you make it in the current commercial ecosystem?
While reviewing recent discussions over at Grant’s blog while writing my previous post, I was reminded of a few things about successful component companies, which I recently discussed in an email conversation with Jeffry Houser over at Flextras about the matter, who encouraged me to blog about some of the points I brought up.
Now keep in mind I’ve never built a business model around making money developing Flash components, so take this part for what it’s worth; however there are a few things I’ve observed over the last decade in the Macromedia/Adobe/Flash industry about successes and failures in this area.
Most commercial Flash component makers start in one of two places:
a) they begin offering mid-level components
b) they have a successful but related business, and offer commercial components to go with their existing proprietary SAAS or server technology.
We won’t even talk about throwaway commercial components, because as I mentioned in the previous post, they should be open sourced anyways.
Starting a commercial component business based solely on mid-level components, as some have done, offers the benefit of relatively little startup capital (basically sweat equity), which gets you up and running very quickly. However, mid-level components can be challenging to hang a business model on, for a few reasons:
a) If they are “extensions,” (i.e. AcmeEnhancedDataGrid) Adobe could, tomorrow if they feel like it, come along and incorporate those ideas into the next version of the framework. In other words, your components may at some point come into conflict with FOSS components of similar functionality.
b) Which means that someone else could also, if they put in the effort, rip off your ideas, at least functionally, and present unwanted, even “illicit” competition, depending on how much they copied you.
c) The lack of phone support and strict licensing means that IT departments, used to spending big bucks to have added functionality at a minimum of fuss, might not regard it/them as serious candidates for an enterprise app, and may not even bother to dig into the API to find out if it has green threading or loose binding functionality.
There has been some discussion recently as to whether FOSS competes with commercial component offerings, and whether Adobe is unfairly competing with its own developers. Well, the answer is maybe, and maybe. The confusion is partly due to a lack of definition as to what constitutes a commercial Flash component, which lies at the heart of the matter. In the case of Adobe unfairly competed with Grant Skinner, well… read on.
Whether FOSS constitutes competition with commercial components, it all depends on what type of commercial components we are talking about, which is the crux of the matter.
First, let’s define what is not a commercial component. Components developed under no license, or under a FOSS license is not commercial, whether they be pre-compiled SWC-type component, a component with sourcecode, or a component which is really just part of a larger open source library.
Types of Commercial Flash Platform Components
1. Amateur or ‘Throwaway’ Components:
A throwaway component is more of the “Monster Template” or what I derogatorily call “FlashKit”-style components. It’s more of a one-shot use component, often with an incomplete API, sometimes not very great encapsulation, little documentation, no support, and cheap. Great if you’re a beginner-to-intermediate developer and you need a quick fix, but not very useful otherwise. Most times these components should be released open source, if not due to their incompleteness, then because even if it is just a few bucks, often you’re just paying for some-dude’s-experiment. Commercial software needs to be up to certain standards IMO, or it should be free, and even then.
There is no question that FOSS and future Adobe framework offerings will compete with these kinds of components — but did you honestly think anyone would actually pay for them anyways? So they’re not really a factor.
Most of the controversy about competition, either from Adobe or from FOSS, is due to a confusion in the difference between what I call a “mid-level” and an “enterprise” component.
2. Mid-level Components:
A mid-level component, in my view, can be either a mashup widget, in that its innovation or rather uniqueness lies in doing something new in the realm of webservices or connectivity, like a Google Map widget. It is also common for mid-level components to be enhancements or extensions of existing Flex or Flash components, including some media players, because they enhance what an existing component architecture already does, or provides a better version of an existing Adobe or open source component.
There is a big difference between a throwaway and a mid-level component: mid-level components often have a well-crafted API, sound documentation with examples, sometimes even the source is included. And with some of the better companies, responsive help forums, and/or email support is present.
3. Enterprise-level Components
It seems to be a recurring trend amongst amateur or ill-informed tech pundits to take aim at misuses of Flash as an argument against using the technology as a whole. And once and a while this mis-aimed cannon of vapid sophistry also takes aim at Flex. And quite frankly, I’m tired of it.
I mean, as a Flash developer for over 10 years (now a Flex developer too ; ), I’m never shy to admit that Flash Platform applications have their limitations and misuses. There is definitely a place for XHTML applications, instead of or as a complement to a Flash-based presence, and skip intros are a no-no. And as I’ve stated before, if you’re going to publish a site in Flash with lots of text, make sure that that text is at least accessible. But if you’re going to provide an argument against using a particular technology, don’t do it as a transparent attempt at promoting your own product at the expense of another, or creating attention grabbing headlines just to get a few more eyeballs to your site. You’ll land up looking foolish, and it’s bad karma besides.
Just recently someone posted a comment on this blog in response to what he probably thought was an “anti-Flash” post. Big mistake. First, as I indicated in my response, while his initial arguments had validity, his conclusion was way off. And it seems to be common occurrence for some bloggers to post comments on other people’s blogs in an effort to garner support for their arguments without considering the point of view of the blog they’re posting on, so the argument falls flat. I’m not opposed to a little healthy debate and free speech, but this tactic is getting tiresome: I see it used so often that, aforementioned comment notwithstanding, I sometimes wonder if some of these posts are provoked by corporations as a “web 2.0″ anti-marketing smear tactic.
Recently I was asked for some advice from a developer on how to manage her first big client. Here’s what I told her:
- Take care of the business side of things before the work is done. Which means:
- No spec work, no freebies. If they like your portfolio and your references enough to hire you, you should get paid for all the work you do for them.
- Get something in writing about what your rate is, what you agree to do for them, and how much you charge, per hour or per project. That can mean a contract signed by both parties, or an email which both parties have confirmed.
- State in your contract/agreement when you expect to get paid, and in what format: 50% up front, the rest upon delivery, or 15, 30 days after? Billable weekly? (for longer projects, if charging an hourly rate) Bi-weekly? By cheque, credit card, interac email transfer? (my favourite)
- Charge more if the deadline is tight, which means high pressure, possibly requiring you to pull an allnighter or two. And if this is the case, tell them your rate is slightly higher for short deadlines. More stress for you means more money from them. As a rule of thumb.
- During the work, get their feedback a little more that you think you need to, but not so much that it encourages scope creep. Clients like to be involved in the process, but you need to know when enough communication has been had. Typically a check-in once per week if the project is a few months long, once every day or every few days if it’s got a crunch deadline attached to it.
- Try to never miss a deadline you’ve committed to.
- But shit happens. If you commit to a deadline, and you think you can miss it by a margin without breaking the project (or the client), advise the client well ahead of time, communicate. And offer them a discount on the final fee if it keeps them in your good graces. And then make your renegotiated deadline, no ifs ands or buts, or your word will mean nothing from then on.
- If you placed yourself in a corner, and you absolutely cannot end-of-the-freakin-world miss the deadline, and you don’t think you’ll make it, tough. Don’t sleep. Or you’ll never see that client again, and most likely your fee either. The trick is to never place yourself in that position in the first place.
- Don’t do it alone. If you encounter a problem, a technical issue you cannot solve, seek support from newsgroups, lists and friends. Because it will save your bacon one day, I guarantee you. But don’t expect a fast reply from lists and groups. And Google is your friend (like, duh.)
- Create a support group for yourself, composed of mentors, teachers, colleagues, people whom you have enrolled to help you with a quick email or IM now and then to save your bacon spur-of-the moment in a real tough spot.
- And when they do, thank them. Show gratitude. It’s all about relationships. Send them passes to a movie, or help them out in turn. Nobody likes a taker.
- Put together a deliverables document to be submitted when you hand over the project, or add these as line-items in your invoice (which should be simple but well-designed), which shows professionalism and attention to detail.
- If you’re required to put together documentation for the work, make sure you charge for the time it took to research and/or put it together.
- As a courtesy, only charge for phone calls or meetings if it’s a consultation type meeting, not a project briefing, and it goes longer than 1 hour.
- Develop lasting long-term relationships with your good clients. Send them a Christmas or Hanukkah card, and a thank you postcard (a real snail mail one!) after a successful project. It’s the little things that get you noticed, that get them to be return customers.
No, Steve Jobs Is not Lying About Flash Not Working on The iPhone (nor is he doing an f-you to Adobe)
a) Steve Jobs is Lying about Flash on the iPhone, and is keeping the info to himself as a negotiating tool.
b) Steve hates Adobe, and is doing an f-you to Adobe.
…and a kinder, more rational explanation,
c) that Flash is not ready for the iPhone.
Okay, let’s get a grip, and a reality check here people. I am not normally one to fall prey to idle speculation, but some of the conspiracy theories floating about lately border on the ridiculous.
Personally, I don’t see any of these explanations as holding water, including the third.
First, Steve Jobs does not need to lie to anyone. He simply keeps his mouth shut on stuff he doesn’t want anyone to know about (yet).
Second, this is business, it’s not personal. That Apple would pull this as a stunt to piss off Adobe or use it solely as a leveraging tool does a disrespect to both parties. (more on this below)
And let’s not turn speculation on whether the iPhone will run flash into yet another *\*yawn\** flash-bashing session. I am sooo bored of pathetically uninformed Flash bashing that does not stand up to a grain of truth. Fullscreen, hardware-accelerated H264 Video in Flex and AIR — ‘nuf said people.
As for Flash running slow on Macs versus PCs, it’s a problem that occurs mostly in Flash Player 8 and below (or AS2/VM1 apps in FP9+), as a difference in the frame rendering engine between the two OSes. Any Flash developer worth their salt will know that if you set the frame rate of the FLA to 21, 31, or 41, that “bug” will disappear, and mac SWFs will run just as fast as their PC counterparts. Don’t blame the technology, blame the developer for being too clueless to know how to code a decent Flash app. And apps designed for the VM2 (AS3) runtime in the Flash player run at the same speed on the PC as it does the Mac without the hack. So let’s put that one to rest already.
As for Jobs not willing to put Flash on the iPhone, as a Flash/Flex developer I can see that as a perfectly reasonable assertion. I think this guy has the right idea: it’s not that Flash is not ready for the iPhone, or that the iPhone is not ready for Flash (the full version), it’s both, depending on which Flash player we’re talking about. One reason I won’t currently touch Flash mobile development with a ten foot pole is that the Flash Lite player is a pathetically chopped down version of the Flash player which requires a mix of AS1 and AS2 coding techniques with a “hackiness” that almost makes Lingo programming look robust. And the full Flash Player is just too powerful for the iPhone processor, so one could also say that the iPhone “is not ready” for Flash. Truth is, Adobe needs to create a new version of the Flash player for this “mid-range” computational device.
CAUTION: PURE SPECULATION AHEAD :
Given the Flex 4 roadmap lecture at a recent Flex conference I attended regarding the up and coming modular nature of the next version of the Flex framework, my money is on the probability that Adobe is already in the process of making a Flash 10 Player for the iPhone.
I am sure there are a fair bit of politics involved, but none of the current discussions I’ve seen take into account the pink elephant in the room: Quicktime. The FLV standard is currently kicking Quicktime’s butt all over the net as the current de-facto standard for online video, so it’s unlikely Apple wants to invite that wolf into their home without some serious adjustments. Adobe and Apple may even be in talks to establish Quicktime player capability in the next version of the Flash Player, who knows (again pure speculation). If we take into account the iTunes licensing model, it’s quite possible Apple will also want some form of DRM for video and audio in Flash as well.
As for the other assertion that Microsoft’s Silverlight will be “first to market” on the iPhone, well I personally don’t think Apple cares if Silverlight or Flash, both or either get on the iPhone. Steve is holding all the keys to all the doors of the iPhone. If it enhances the Apple brand without losing too much control, he’ll do it. But I doubt Apple is weak enough to be bought, bullied or cajoled into doing anything it doesn’t want to do, from Microsoft, Adobe or the user base crying out for either. Apple has long since become a monopoly in its own right, and despite its PR, is far from being the “company for the people” that it once was. You worship at the iChurch of Apple or you go home, and you don’t tell the priesthood how to operate.
Having said that, everyone assumes there’s this incredibly aggressive war going on between Apple and Adobe. What if there is no such thing going on, and Apple and Adobe are merely taking their time to sort out the mutual licensing rights, as it is definitely in both parties’ interests to come to a satisfying solution? Quicktime, PDF, iTunes, DRM, FLV, SWF, Flash Player, iPhone OS — all these are proprietary technologies, on both sides, and getting them to legally play well together will take time for the suits and the engineers to work out.
Personally, I don’t give a toss if the iPhone has Flash or not right now. I’m having too much fun developing Flex and AIR apps. Flash on the iPhone will come. And when it does, it’ll be cool. But I’d rather have faith that these two goliaths will work out a decent solution rather than give in to all the fear and loathing going on. So please, let’s give the limp “Apple is doing an f-you to Adobe” rumours a rest, eh?
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. :)
Almost every time I speak with a new recruiter, I find myself explaining what a
“Flash Platform Developer” is, and what the skills listed on my resume mean in the overall context of RIA development. Or having conversations with project managers and HR personnel about why it may be necessary to hire two different kinds of Flex developers, unaware of the distinction.
Lurking in the background of such discussions was a subtext, an underlying question: “what do we call the person who builds SWF files for a living, and what exactly do they do?”
Following my previous post and ensuing discussions with fellow developers, I thought it might be useful to publish an article on the topic of (re-)defining these developers, given recent and upcoming changes in the technology, and in the employment marketplace.
This free Community MX article, entitled ‘So You Want To Hire a SWF Developer?‘ serves as a whitepaper for recruiters, HR personnel, managers and developers looking to get to grips with defining and hiring various people who “build SWF files for a living.” *
* Okay okay, so you got me, smarty pants: any one of these developers can publish for Flash, AIR or Flash Lite runtimes and not author a SWF file, I had to call them something…
Following my post the other day on reasons to use Flex for RIA development, I stumbled upon an excellent post by InfoQ regarding Top 10 Adobe Flex Misconceptions, as well as an excellent blog comment regarding why to use Flex (as opposed to certain supposed \*ahem\* competitors).