There is a great article posted by a developer of the open source FreeMarker project on a proposed “third” role for web development teams — something between a backend application developer and a frontend web designer.
I have to say, so much of this article rang true for me. I just finished a web application in which we had four developers but two main rules: backend developer and frontend designer/developer. Due to the type of project it was (and the skillsets of the people involved), backend work was done by 3 of the 4 team members, and frontend work was done by a sole designer.
The issues we had were that:
- The backend developers could only make guarantees about what kind of object to pass to the view. But often, in order to get access to other “global” objects, the frontend designer would have to hack controller code as well. (Luckily, data services were tiered off out of the controllers, so at least the designer didn’t have to muck about with SQL.)
- The designer hated the idea of pushing some logic “back” into application code. So, though we as backend developers proposed a layer for configuring things like which menus to display on each page, etc., the frontend designer preferred to engage in the copy-paste-modify antipattern instead, so that it could just “get done.” I can see why: it’s a pain to context switch from JSPs, HTML and CSS to Java POJOs that then will have to be checked using JSTL anyway!
If, early on, we had decided to use FreeMarker instead of JSTL, perhaps the frontend designer could have had access to more powerful macros, and wouldn’t have done the copy/pasting. But I think overall, the two tiers are too few; I agree that you need someone to sit in between and think about how to cleanly integrate backend logic and frontend design.