Nic Wise [mailto:[EMAIL PROTECTED]] wrote:
> > we find the content horribly intermingled with the presentation
> > again. Two roles have to collaborate to produce this particular
> > JSP code - a programmer who can write correct scriptlets, and an
> > HTML designer who develops the HTML presentation code. Ugh!!!
> Well, no. this _can_ be done by one person - and in my case, it
> generally is, with the input of a graphic designer. If you are doing
> web stuff with a programmer who can't write basic HTML, get rid of
> him/her, ditto a HTML person who can't write around scripts.
I don't dispute that it _can_ be done by one person. I stated that
it is two _roles_. For small development teams, the roles are often
embodied in a single person. For larger teams, they generally are not,
and for good reason. Once you start having programmers write some HTML,
they are treading on the toes (and responsibilities) of those whose
specific professional responsibility is to produce HTML (note the
distinction
between _graphic designer_ and _HTML developer_ - they may or may not be
the same person). It also makes it harder for management to optimise their
resources, because they can no longer ensure that they spend $ on cheaper
HTML developer resources in order to meet HTML demand - they have to spend
some $ on Java developers for that purpose as well. That does NOT go down
well in budget creation meetings.
I suspect the reaction might be a bit different if the
HTML developers were writing Java code to be polished up by the software
developers.
> > Standard software development management practice
> > will tell you to reduce these sorts of interactions amongst team
> > members where possible rather than mandate them. It also mandates
> > that you break the entire development task up into units which can
> > be completed by people with differing skill sets and levels. The
> > code above does not enable that partition.
> ... and the standard method of software development doesn't
> really apply to web development, which is, IMO, about 90% of the
> problem that people have dealing with it - its NOT client/server, and
> its not inherrintly state-based, so you have to develop in a totally
> different way.
Frankly, I disagree. This sort of over-generalisation leads to conclusions
which are plausible on the surface, but which only apply to some subset of
situations. There is an important distinction between software
_development_
methods and _management_ methods. Sure, the _development_ method is
different,
if only because there are additional deliverables and additional development
roles!
That doesn't break the principles of good process management. Just as
quality
Engineering design strongly encourages reducing coupling between subsystems,
quality management encourages the reduction of dependencies between
different
roles, especially in different departments. This applies whether or not you
have a clients-server architecture, and whether or not there is state in the
system,
and so on.
> 2) The HTML should be written by whoever is writing the page,
> being they
> have
> the specific knowledge of the page. If a grafic design person
> is needed,
> bring
> them in as a 'consultant', but not to actually write the code.
That exactly illustrates my point. In large teams, the HTML designer
writes the page. The Java developer is providing _services_ to the
HTML designer, and has _no_ responsibility for the page. I think some
of this debate might do well to consider how programmer-centric the
expressed viewpoints are. A wider view of the system development
process is needed - and a realisation that as team size grows, the
distribution of roles gradually changes from one person handling many
(and not realising most of the roles they are performing) to one
person per role.
Cheers,
Richard.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
