Ely Greenfield’s session at MAX was, in my opinion, the best session of the conference… although I didn’t really attend many sessions at the conference (with so many people walking around who has time to sit in sessions?). But Ely’s was frickin’ awesome. Video recordings of his presentation in Barcelona have been posted by Joao on his blog. If you missed Ely’s session at MAX or you missed MAX entirely, go watch these videos. Seriously, go watch them now. The session was called something like “Flex Roadmap”, which was basically Ely talking about experimental directions they’re going while thinking about Flex 4.
Praising Ely
If you use Flex you know Ely. He’s formerly the charting master on the Flex team. I heard he wrote most of the charting framework with his eyes closed in 3 days. He’s one of the smartest guys I’ve ever met. His blog was an amazing resource while I was learning Flex. If you’ve been dabbling in Flex chances are you’ve seen some example code that he posted on his blog. Maybe you’ve seen this, this, this, this, or this. Turns out he’s been busy and hasn’t been blogging, which I’ve thought was a horrible idea. I think Ely’s blog posts are some of the most inspiring code examples out there, and his blog alone has probably convinced more people of the value of Flex than any other single source (this is all very biased, I learn extremely well from reading good source code). But Ely hasn’t posted a blog entry since March 19. WTF? I’ve often wanted to write a letter to Adobe on behalf of the Flex community and say “I don’t know what you have Ely working on, but give him some time to blog cool shit again. Whatever he’s doing can’t possibly help Flex more than his blog.”
Ely’s session at MAX was the first time I got a look at what he’s been doing, and it was the first time I thought to myself, “Oh, THAT’S what he’s doing? OK, you win. Keep him doing that.”
Creative Thinking from a Blank Slate
I want to try to get to why I thought this session was so good. To get a little perspective: we’ve got the Flex framework, which is something close to 300,000 lines of Actionscript code. That’s a big code base. That includes some monster classes like ListBase and DataGrid. So with that in mind, Ely gets up there and basically says: Let’s start over and really think about these components. Boil them down to the core functionality. What IS a list? Who cares that we have this ListBase class of over 7,000 lines of code. Maybe it’s not right. Let’s make it the right way. Let’s really figure out what the core functionality of a list is (and it doesn’t involve laying out scrollbars or clipping content or laying out items vertically or horizontally). He goes over a dramatically different way of creating a core list component in the session (see the last couple video segments).
There’s a really important (and dangerous) thing happening here. Most people would look at the current state of Flex, which includes a proven, stable, large code base and they would take that as a given. What I mean by that is that most people would think about how to take the framework and tweak it slightly to make it better (kind of like the improvements from Flex 2 to Flex 3). It takes balls (and brains) to be able to look at such a code base and say “Let’s rethink this. Knowing what we have learned from the past few years of Flex’s life, is this the right way to make a framework?”
That’s a leap that I think is more difficult than it sounds, and it’s something that I think is important for all software development. Too often we can start taking existing ways of doing things as the only way of doing things. Say you’ve been working on a project for months (or years) and the product now does a bazillion more things than you ever thought it would. Maybe the actual core use for the software is now dramatically different. I think it’s hard to back up and really think about the project with a fresh perspective. Question the architecture, question the fundamental design. Maybe the way it worked was right for the time, but doesn’t make sense any more.
Danger
This is obviously dangerous, because you can’t simply rewrite your entire code base over and over again (well, you could, but you’d never ship a product). And Ely constantly restated his disclaimer throughout the session, which basically went like so: they’re committed to backwards compatibility, nothing he shows or talks about is decided on, and all your old code that uses the Flex 2 or 3 framework will not be useless. He has to say this over and over because people get freaked out when they see such fundamental changes (which has important implications for all Flex applications ever created). I’m sure that this discussion comes up a lot internally at Adobe, and I’d love to hear more about how that conversation goes.
I’m glad Adobe is keeping backwards compatibility in mind, but what makes me even more excited is to see that Ely’s able to think about the Flex framework with a fresh, innovative perspective. This was what I really took away from MAX: the concept of stripping your code down to core functionality, thinking about it in a fresh light, and not being afraid to change everything.
I hope I didn’t sound like too much of a kiss-ass in this post.
