struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Piker" <spi...@twmi.rr.com>
Subject Struts productivity metrics?
Date Mon, 27 Jan 2003 16:02:37 GMT
I apologize in advance if this has been discussed before - I'm new to this
mailing list and relatively new to struts.

I am interested in obtaining some real-world productivity metrics for struts
usage.  For example, has moving to struts greatly improved your/your team's
overall productivity?  How much, and which specific areas have improved the
most?

I would assume using struts would have little or no effect on the back-end
object design and construction effort.  So we're really just talking about
improving the front-end/controller tiers of the application.  Correct?

So some specific questions:

1) What's the typical ramp-up time for an average developer?  How long until
they become fully productive vs. 'just capable'?  What's the most effective
way to bring someone up-to-speed?

2) What's the suggested team size / structure and experience mix?

3) On a per "page" or use case basis, how long does it take for an
easy/medium/complex module to be developed?  How does that compare with
other frameworks/approaches you've used in the past?

4) Assuming that struts provides a consistent framework that is easier to
maintain, is there perhaps a increase in initial development effort which is
offset by a decrease in the ongoing maintenance effort for the application?
Can that be quantified by testing metrics like # of issues reported/module
and avg. # hours required to resolve an issue?


Anecdotal comments are appreciated, but I'm mostly interested in hard
metrics (X hrs w/ struts vs. Y hrs w/ 'the old way') if possible.  Also - if
there are any books/sites which address these questions, please send them my
way.

Thanks in advance,
- Scott


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message