Believe it or not, this isn't another slam on Adobe. Ars Technica saw fit to publish something that smells awfully like a press release today: Adobe to unify ColdFusion, Flex, Flash with FlashBuilder4. (My inglorious 13-month "career" as a journalist saw me cleaning up any number of these things--enough to flatter myself that I know one when I see it.)
Anyhoo, one sentence in particular darned near drove me up the half-wall of my cubicle:
Flash Builder 4 includes support for Adobe's still beta Flash Catalyst rapid UI design tool, which, along with Flex 4, will enable designers to work on the front-end independently of back-end development.
When will managers stop buying this snake oil?! Not the product itself, but the notion that you can put the Berlin Wall between designers and developers. Ever. In fact, I posit to my gentle reader that management not only robs its own pocket in paying for such "solutions," but does its end-product incalculable harm by believing that it can structure its process around this alleged "independence" of function.
Understand two things: Firstly, I barely need both hands to count number of graphic artist/designers with whom I've collaborated as a developer--i.e. the-plural-of-anecdote-is-not-data. Secondly, I'm painting with a double-wide brush in characterizing visual designers as right-brain and programmers as left-brain. That being said, fantasizing that UI people and backend people speak the same language (even when working side-by-side) is twenty-four-caret folly--as it is when you mix any pair of complimentary disciplines. Now, the skeptic could make the case, "Eh, so you're gonna lose some nuance. Big deal. That's what review meetings are for--to patch that up." Except that, even in the best-case scenario, a minimum of two review meetings are guaranteed for every "chunk"--however that's defined--of work to be done. How many meetings have you attended where everyone's come out on exactly the same page? Yeah. Me, I'm thinkin' that two is ridiculously optimistic.
The bottom line is that the front-end--meaning the part that users see--has to know what the back-end (the database and the server-side code) is expecting at all times. And vice-versa. Bad juju happens otherwise. Moreover, it greatly streamlines the communication between front-end and back-end when the front-end proofreads/validates data before pitching it over a network connection. Meaning that the UI requires "invisible" code that checks things as such as:
- Have all the required fields been filled out?
- Does this credit card number have the right number of digits?
- Does the expiration date of the credit card fall on or after today's date?
- Did someone try to enter a bogus date like February 29, 2010?
- Does the email address contain an "@" and a dot-something-or-other?
- Are the dollar amounts positive or negative?
- Does the new password have at least six characters and a combination of letters (upper- and lower-case) and numbers/symbols?
- Is a malicious user attempting a SQL injection hack that could be nipped in the proverbial bud?
And that's not even accounting for more esoteric logic specific to the application/organization itself. Generally speaking, you need a programmer's hands in the front-end code to enforce whatever "rules" are dictated by the nature of the data being collected/processed. For that reason (even more than the realities of human interaction), I think that companies peddling the notion of "independent" design and development sorely need to be laughed out of business. And programmers & designers who work for the idiots who buy into the false designer-developer dichotomy should brush up their resumes and find a sane organization to work for.
