I believe those early successes helped me become very pragmatic, agile, and optimized. While I to this day still question a lot of what is considered “good programming” practices, I believe my pragmatism allowed me to judge what OOP, design patterns, and frameworks were appropriate, and how much of each were used based on a projects need. As my projects increased in scope, I learned to love strict-typing. Design patterns helped organize my code enough to be able to quickly change the design for whatever reason and still have my code work. I learned to love frameworks such as ARP & Cairngorm as I started getting more development help on projects ( I used to be the only developer).
…things have changed. With the release of Flex 2, 2006 opened the door for traditional programmers, both server-side an client side, to now contribute and benefit from the SWF format. Now they can create RIA’s, and really enjoy doing so. New blogs from talented developers you may not of known in the if you were strictly in the Flash Dev community are popping up daily, all with great code & development techniques to contribute to the greater community. Some were sleepers, others are just now getting around to getting a blog because other traditional developers are doing it too, and some are just coming into the echo chamber that is the Flash / Flex development blogosphere . All bring with them their style of development. More often than not, these are real developers that don’t have the learned expectations of a lot of the early pioneers and frontiersmen that were those early brave programmers like Branden Hall, Colin Moock, etc.. They are the ones who use Test Driven development, Inversion of Control, and some even care about your CMM level. Some are all about the Flex Component & FDS API’s where others are swimming around the boilerplate, low-level Flash Player AS3 API’s such as ByteArray & Socket as if they were nothing foreign and new.
One things is abundantly clear, though. These are programmers, and they mean business. Business in the sense that they have lingo, processes, and development setups that only used to trickle into the Flash Development community. Granted, there are plenty of prior art to showcase all of these things in some shape, form, or fashion in our community, but never has it been on such a paradigm changing scale as this.
Why does this matter?
For one thing, these guys n’ gals don’t know the Flash Player, they just know they like what it can do. Most don’t know, nor care to know, about what an 8 bit alpha channel is, and how it revolutionized what we can do with design on the web. …but they know we do, and they want us on their teams because they need to focus on getting their J2EE back-ends to work wonders with our Flex front ends. If you know Flash and/or have a minuscule amount of Flex experience with a design background, you are in high demand.
The common theme I keep seeing is that Flex is being used more and more in a lot of traditional enterprise development setups. This means having an actual Quality Assurance team, maybe even user testing, all with the assumption you’ll use the tools and processes that traditional Java developers on large teams use. I feel a lot of Flash Developers have spent their entire careers learning more and more about traditional software development to augment their ability to be more successful in their traditional multimedia & agency work. That is, of course, unless they truly have crossed over to full application development and are just waiting for Flash Player 9 to hit the magic 80% penetration mark before they make the dive to AS3 or event Flex. Either way, I feel we’ve all had this open mind about learning new things since our industry in particular has changed so fast. While I may be extremely suspicious of using test cases, or appear quite unconvinced about having Spring lend some of its concepts to the client, I’m actually very open. Again, while we’ve had a lot of great traditional developers contribute their learning to our industry to help move us forward, never had we had an entire industry merge in like this, and on such scale. So, I’m still learning every day about how a myriad of development teams do their work based on their varied backgrounds ( C, C++, Java ) and what tools and processes they use to make better software.
It’s just really really hard to match those lessons they’ve learned with my own pragmatic ones. They don’t complement each other at all. They come to a harsh clashing in the old consulting adage of “fast, cheap, and good… choose 2”. If you want me to develop a widget for a client in 1 week (which is definitely more than reasonable), I see little value in creating test cases and implementing ARP . I’ve been burned too many times not to use source control, but what if I had 2 months… would those tools, and those who corroborate their joy of being converted be now justified? I’m sure the traditional software devs are nodding their heads saying, “Obviously”. Of course, if you asked them if they blindly accepted new frameworks and processes, I bet you most wouldn’t say “No”; they’d look at them logically, and want to see proof on ROI of their time invested before learning them.
But is there any return? Do I have anything to give? What about all the accelerated development talents, tricks, and skills I’ve learned over the years to hit impossible deadlines with design and code… how do I convey value to them that a traditional software dev would understand? Obviously the Ruby guys “get” what the advantages of loosely typed languages, and the agency non-coders love when we have good attitudes to make their designs do awesome dyanmic things, but how do you translate that to AS3, when you are rewarded twice for strong-typing: speed & maintainability? I could not strongly type and turn off compiler warnings, type far less code, and get things done a lot faster. But to what gain? We are no longer suffering the agency problem under-bidding on both price & time forcing designers & programmers to slave away at immense hours of time (well… some of us). Yes, clients in the Enterprise sphere are as demanding as well, but we’re talking months or years here, not days & weeks.
I guess what I’m saying is, the software developers coming to Flex already have preset ways they develop; Flex is just a technology in their repertoire where I think for a lot of us from the Flash background, it’s a way of life. And that way of life has drastically changed. And I think it’ll continue to change as swaths of more and more traditional software devs, both enterprise and small, get on board in such numbers we’ve never seen before. For them, it’s a nice, new opportunity to create more rich GUI’s that are easier to deploy, easier to develop for, and more enjoyable for all involved. For us old skoolerz? Our life is changing. What I’m having problems accepting is that it’s “supposed” to fit into traditional development molds. It seems just obvious now that the CompSci’s have their true IDE, command line compiler, and strongly-typed runtime. To me, it just seems one of the many ways to utilize the SWF platform, and therefore, nothing is implied or inferred.
I feel like I have a lot to offer. I know how the Flash Player works. I know how to get a variety of designs to work. I know how to talk any back-end there is. I know how to get complementary technologies and tools to help make my development & design implementations efficient. I remove headaches from server-side developers, and they remove mine. I have client development experience that translates to both web application development and desktop development. I can get things done, and if need be, get them done quickly. The J2EE guys like this. What they don’t understand is us Flash and early Flex devs weren’t around for the EJB wars, or all of the other battles fought over blogs, email lists, and conferences about how Spring & Hibernate revolutionized server-side Java development, and that industry as a whole. When we ask questions, it’s because we didn’t participate in that. We had our own battles dealing with the maturation of a fledgling language moving from a dynamic environment to a more traditional programming one. Those are growing pains, yes, but they do not necessarily translate to process ones. This doesn’t mean we have the proper context to appreciate what you all have to offer. Just something to keep in mind when you explain something that’s wonderful in your work flow, and you’re greeted with a blank stare. Something to think about. We’re not dumb, we love new toys, and love this stuff as much as you do. An ActionScript developers’ life is fraught with learning new things all the time. That’s what makes it fun. It’s just there are wayyyyyy more opinions & options now than 5 years ago.
I know that insane deadlines, hastily written ActionScript 1, and non-source controlled projects will still exist for some time. This could even be for me via side contract jobs I take to supplement my full-time income. To me, those development decisions exist because you can thrive on them in such fast-paced environments. It’s just been really hard to reconcile the lessons I learned from those areas into traditional software development, specifically in interview conversations. You can really sound like a buffoon to those people even if you’ve had a long history of proven successes & notes of merit. So far, I’ve had a few instances of tension with the bigger companies, and none with the startups. Basically, those who use more Enterprise development technologies struggle to understand why I wouldn’t WANT to use their uber-involved processes whereas the startups and I really have synergy in “getting things done”. When I bring this up to the Enterprise potential employers, they are definitely in agreement that they too like to get things done.
…but it’s not the FIRST thing they said.
Anyway, just wanted to point out it’s something that’s been challenging for me to reconcile: past learned lessons on “how to survive as an engineer in a fast-paced environment” coupled with “how to develop maintainable, long-lived software”. Different worlds, man, different worlds.