I think others should share their view on this but I will add my two cents (not sure very web2py specific).
Most of the best projects I have seen in web2py are written by small teams (same goes for most open source web apps I have seen in my life). In web2py there is an order in which you do things. first you write the models, then you write the controllers, finally you apply the views. The fact that there is an oder and that very little repetition of code it means it is difficult for people to work in parallel on the same project during the initial phase. This means that going from 0 to a working prototype is better done by a small team (1-3 people). Things change after that. A small team does not make good testers and does not make good documentation. There are all things that can be parallelized and are best done by different people. Things are also different if a project is comprised of modules that are independent or if the project is designed from the beginning as a set of plugins and modules. For example if your project is comprised of many apps they can be worked on independently and in parallel. Of if the app is required to talk with third party services, it is reasonable to have different people work in parallel to create modules to interface with those services. I can say web2py itself is now being worked on in parallel. Different people are more or less in change of different modules and we work on them independently on fixing bugs and adding features. This is one under a global quality control enforced by Anthony and Jonathan. We have some unwritten rules by which we operate (good: decrease size, fix bugs, add features, portablity; bad: change of behavior, bloated code) and usually we do not even need much discussion on proposed changes when they affect a single module or fall clearly in one's domain of expertise. Many of our discussions are about adding new features that may affect multiple parts of the code, what the consequences may be for users, and whether the proposed approach is sufficiently general. Massimo On Thursday, 9 August 2012 11:25:08 UTC-5, Luc Chase wrote: > > Must admit that site is funny; I almost bought the t-shirt. > I don't mean to imply any particular methodology (even though I do tend to > favour evolutionary, functional prototyping methods hence my interest in > Web2py). > I'm more interested in how larger web dev projects are affected (or not) > by the integrated nature of web2py, regardless of the dev methology used. > Can larger teams work collaboratively just as easily with web2py as with > say very lightweight frameworks (or perhaps more easily)? My belief is > that they can, but it is only my belief. There are some who say that the > architecture of web2py is likely to make it more difficult to separate the > concerns of the various team members. > > -- > Luc > > On Wednesday, 8 August 2012 21:39:20 UTC+1, Luc Chase wrote: >> >> What particular constraints and advantages does using web2py tend to >> bring for larger project development teams as opposed to those working solo >> or in very small teams? >> >> I assume for example these roles benefit from rapid feedback and ability >> to adjust requirements more easily? >> >> - Project stakeholder (client or business owner) >> - Project manager >> - Producer >> - Editor/copywriter >> - Information architect >> - Business-systems analyst >> - Tech lead >> - Database administrator >> - Quality assurance engineer >> >> But are these roles less-able or more-able to work in parallel? >> >> - Graphic designer >> - HTML developer >> - Developer >> >> --
