No subject

argument, but to think that each group is going to placed in silos would
seem to me to only create a greater gap in communications and
understanding.  If nothing else, I would say that my technical knowledge
and abilities have helped me gain notice during the interview &/or sales
process.

> > The emphasis on the separation between "Designers" and
> > "Developers" will likely lead to less than optimal products.
> 
> Just the opposite: those who are actually trained/focused on 
> design will end
> up doing design and those who know how to write/manage code 
> will do so. The
> separation optimizes the expertise of the executors. I just 
> don't see the
> efficacy of asking developers to get involved in 
> design/usability/etc *when*
> there are designers to do just that.

Sorry, but I disagree, again.  Your line of thinking is stating that the
sum of the parts is greater than the whole.  That's nearly similar to
saying "QA shouldn't be involved until their phase of the project" when
the reality is that QA should be involved very, very early in the
process so they can grasp what's happening, understand better how to QA
from a variety of perspectives, educate the rest of the team members as
to what information they need, etc.

The reality of the situation is that there are very, very few positions
in the technology sector that are very focused these days.  There's a
desire to have well-rounded, much like those gen ed courses in college
were supposed to make us, developers, designers, etc.

> >> So my dream is to see the Design and Development sides to
> >> consolidate into two distinct entities bridged by the functional
> >> prototype.
> > 
> > And that prototype will probably become the "wall" that one group
> > throw things over to the other.
> 
> Why?

Because when work is done in a silo, communications channels break down,
knowledge becomes proprietary and the end result is a dissatisfied
client and potentially a fired vendor.  Certainly, not in every
situation.

Russ