I've worked with a medium size team directly. I've also worked with a large team, indirectly. For example, contributing code to a framework means you're part of a large team.

Four things I've learned in both of these cases and not from working alone, are 1 - make everything as encapsulated as possible. A small discrete function can be reused by all. Even a single line of code can be a function. Writing it once and making it reliable will benefit the whole team. I wrote an FPA article where I created a snippet factory object. This object took even a simple formula, put parameters into the formula and passed it back to the programmer for use in EVAL().

This performed almost as well as the original manually coded line, and better than if I'd put the formula in a UDF/PRG or a method of a class.

2 - Store files in the physically smallest units you can. Don't make a single object with a gazillion methods because multiple programmers can not work on this one class simultaneously. Same goes for procedure libraries etc. That also means source control doesn't have to attempt to knit code segments together. I don't trust a machine to do something that difficult.

3 - Everyone on the team must focus on the clients needs, not their own. That results in the team all pulling in the same direction and everything flows nicely.

Drew Speedie was the team lead on a large project I was on. He - I think - introduced the weasel award. If you write a UDF/method that someone else would use and your code causes the other programmer's code to break, you get the weasel award. This was all done in fun, but it motivated everybody to avoid getting the award, which resulted in increased communication and planning.

4 - Standards should not be too rigid.

Had I worked exclusively alone, these things would be not necessary.

>OK! Thanks to everyone for the answers. It’s very constructive for me.
>
>Maybe I wasn't clear enough. I want to share experience with people working in Big Teams using VFP and working in the same project.
>As a background I have 18 years of experiences and have used from FoxBase to VFP9 and .NET and ASP and another bunch of tools. I’ve worked in Big Teams but never so big and never in the same project.
>As you can read in the message from Jamie Osborn and Goran Zidar, this group is not new. The application has 15 years old, it’s started in VFP3 and Goran was there since it started, he is the architect.
>The team has a Framework developed by the team, there are lots of conventions, there is a methodology (almost 40% of our time is spent writing documentation), we use our own wiki and lot of other things.
>The system has a perfect Model-View-Controller better than any book I’ve ever read and will implement (because it is alive) a better data access tier.
>From my experience, this is the BEST TEAM I have ever been working with.
>But even all of that, there is some issues. For instance, like Jamie said, the source control and Goran answered we are writing our own tool.
>
>So, again, I think that work in a big team is completely different that work in a small team. 20/25 developers working in the same application is a really different and this is why I asked for that.
>
>I really like the idea of Goran writing something about this. I think it’ll be very good material.
>
>And again, thanks to everyone that answer my message.
>
>And re-reading my original message … it wasn’t clear at all :-)
>
>Regards,