I might be a novice/average developer, but I'll give you the benefit of my experiance.
I found that I could churn out good web applications using JSP and JDBC, but using scriptlets. When I discovered Struts, I realised the error of my ways, and started from scratch. However, I rapidly realised I didn't really know the basic principles of Java and that JSP had isolated me from this small omission. So my ramp-up time was increased. It took me a good 3 months to be proficient, and still learning of course. My colleague has had exactly the same experiance. Roadblocks were:- 1) configuring an IDE ( Jbuilder5 needed a lot of changes - switched to Netbeans). 2) understanding Strutsblank 3) lack of books/ easy documentation on struts 1 year ago ( not now) But the real key was a quantum leap in the need to properly understand Java. Iain Please respond to "Struts Users Mailing List" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> cc: Subject: Struts productivity metrics? 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
