Just wanted to say, well put Richard.
I think you hit the nail on the head, some of the contributors to this
list, while technically brilliant and unusually literate, seem to have a
fairly narrow view of the software development process and the realities
of the business and management model. They see a good solution to their
specific implementation requirements and think that is the end of the
story.
The flexibily of JSP is one of it's strongest points. Scriptlets, HTML
tags, servlets, EJB should all be able to be used if and when necessary
or practical. 1.0 has broken this to some extent. I think the
"compatibility" thread also running on the list proposes a good interim
solution while waiting for 1.1 (which should have been 1.0 !)
Regards
Drew
> -----Original Message-----
> From: Richard Mazzaferri [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, 8 May 1999 6:48
> To: [EMAIL PROTECTED]
> Subject: Re: The horror of moving from 0.92 to 1.0
>
> 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".
===========================================================================
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".
