Until now I have worked on small teams (1-3 developers) and we've been able
to stay out of each others way. Now I'm about to start work on a project
that will have 5 developers. I would appreciate some guidance on how we can
proceed to develop without having to worry about "who is working on what
files".

We're developing with SQL Server 2005, VS 2005 Pro (no way management is
going to spring for the $10,000 team edition for everybody), and we'll have
Visual SourceSafe.

Of course these tools (even the Team edition if we had it) wouldn't prevent
us from getting into trouble... thus my inquiry (for articles, links, tips,
suggestions, etc).

Thanks!

My advice is this:

Use good tiered development. This will help keep people out of each others
way.

(if someone is workign on the mypage.aspx, they won't interfere with someone
writing up a new business logic rule)

Have a "at the end of the day... you need to check in your code in a
buildable format"

aka, don't check something in that makes it so you can't compile.

Be very anal/strick about checking out the .sln and/or the .csproj (.vbproj)
files.

(Solution and Projects) because that will screw others.



This will keep things in order most of the time.



The biggest gotcha is that..

UserA creates a new file

MyNewClass.cs

They edit an existing class/file (MyExistingClass.cs), and write code in it
which uses MyNewClass (.cs)

They check out the project. They add the file.

They check in the project. They check in MyNewClass.cs.

They FORGET to check in MyNewClass.cs. Now others can't build.



A good ole boy policy of something like "The developer who does this has to
buy sodas for everyone else in the group" if they screw up can solve that
issue.

No, Im' not joking. A few rounds of sodas from the machine by the one
numbnutt who keeps forgetting, will burn some memory into him/her.









http://sholliday.spaces.msn.com/PersonalSpace.aspx 5/24/2006
6/5/2006

has a start up tiered development example:





"Smithers" <(E-Mail Removed)> wrote in message
news:OWyx$(E-Mail Removed)...
> Until now I have worked on small teams (1-3 developers) and we've been
able
> to stay out of each others way. Now I'm about to start work on a project
> that will have 5 developers. I would appreciate some guidance on how we
can
> proceed to develop without having to worry about "who is working on what
> files".
>
> We're developing with SQL Server 2005, VS 2005 Pro (no way management is
> going to spring for the $10,000 team edition for everybody), and we'll
have
> Visual SourceSafe.
>
> Of course these tools (even the Team edition if we had it) wouldn't
prevent
> us from getting into trouble... thus my inquiry (for articles, links,
tips,
> suggestions, etc).
>
> Thanks!
>
>
>

First of all, set up Sourcesafe so that developers can NEVER edit the same
file at once. A checkout should lock the file. This should really be the
case for all projects because if a file is big enough to be worked on by
more than one person it's probably hard to understand and in line for
refactoring anyway.

Make sure that you keep a close eye on the physical structure of your
program. The John Lakos C++ book is a superb guide, even for C# / VB
programmers because it describes in detail how physical organisation can
affect performance and build-times.

Use NDepends to get a handle on the metrics for your application and make
sure that all your developers understand why it's important.

Choose an XP / SCRUM / Agile development method rather than a spec and
MS-Project type of system. The former is flexible, the latter always gives
false expectations. Craig Larman once said to me "You often hear of software
delivered with all the features but months late and over budget. No one
*ever* complains if an application is deliverd on time but with only 90% of
the features"

Ensure that your development team has a good proportion of dedicated test
engineers. Three developers need one test engineer to keep them on the
rails.

Document EVERYTHING!!! from the word go. Use XML inline documentation and
keep it current.

Document your install procedures, your architecture, your dev practices and
do not allow hero-programmers to take stuff home in their heads and then get
themselves killed in a motor accident on the weekend. Those super-hero
programmers must transfer their skills to at least one other team member by
pair programming.

When a team is bigger than about 6, break it into two sub-teams. The team
lead will be the one who everyone listens to and who has the best ideas.
Don't bother trying to appoint one.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.



"Smithers" <(E-Mail Removed)> wrote in message
news:OWyx$(E-Mail Removed)...
> Until now I have worked on small teams (1-3 developers) and we've been
> able to stay out of each others way. Now I'm about to start work on a
> project that will have 5 developers. I would appreciate some guidance on
> how we can proceed to develop without having to worry about "who is
> working on what files".
>
> We're developing with SQL Server 2005, VS 2005 Pro (no way management is
> going to spring for the $10,000 team edition for everybody), and we'll
> have Visual SourceSafe.
>
> Of course these tools (even the Team edition if we had it) wouldn't
> prevent us from getting into trouble... thus my inquiry (for articles,
> links, tips, suggestions, etc).
>
> Thanks!
>
>
>

Smithers wrote:
> Of course these tools (even the Team edition if we had it) wouldn't prevent
> us from getting into trouble... thus my inquiry (for articles, links, tips,
> suggestions, etc).

This is an older article, but perhaps it will help:

http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp

"sloan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> Have a "at the end of the day... you need to check in your code in a
> buildable format"

That would be altogether unworkable on many of the projects I've worked on.

> aka, don't check something in that makes it so you can't compile.

That's a different matter, though, with which I agree.

Of course, an even better requirement is to not check in unless you've
refreshed your local copy and made all unit tests pass.

> Until now I have worked on small teams (1-3 developers) and we've been
> able to stay out of each others way. Now I'm about to start work on a
> project that will have 5 developers. I would appreciate some guidance on
> how we can proceed to develop without having to worry about "who is
> working on what files".
>
> We're developing with SQL Server 2005, VS 2005 Pro (no way management is
> going to spring for the $10,000 team edition for everybody), and we'll
> have Visual SourceSafe.

To be perfectly blunt, this really is the least of your worries (with all
due respect). You have SourceSafe so as long as everyone is checking out
their files there should be little conflict (assuming nobody needs to fight
over the same file all the time - parcel the files accordingly to avoid
this - it shouldn't be much trouble). The real problem you should focus on
is poorly written code (bad design, bad mechanics, lack of re-usability,
lack of error checking/recovery, etc). This is responsible for 99% of all
software problems and it's what everyone should be focusing most of their
time on

"Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
news:(E-Mail Removed)...
> First of all, set up Sourcesafe so that developers can NEVER edit the same
> file at once. A checkout should lock the file. This should really be the
> case for all projects because if a file is big enough to be worked on by
> more than one person it's probably hard to understand and in line for
> refactoring anyway.

I used to feel this way, too. And it's the default in VSS, so most people
have never even tried using optimistic locking (where files aren't locked).
But once I actually tried multiple checkouts, life became soooo much easier.
No more dealing with the developer who leaves the office (or the company)
early. No more haggling over who gets to edit a file. Essentially, no more
concern with source control -- it becomes a useful tool, rather than a
prison.

What do you lose with multiple checkouts? Surprisingly little (especially if
you have a good set of unit tests). It's remarkably rare for two developers
to be working on the same part of the same file (if they are, that may
indicate problems that source control was never designed to solve). If two
developers are working on different parts of the same file at the same time,
modern merge tools have a laughably easy time sorting things out. Try it!

> Document EVERYTHING!!! from the word go. Use XML inline documentation and
> keep it current.

This is really anti-Agile, IMHO. The code is the documentation. If it
doesn't explain itself well enough, then make it simpler. If you can't do
that, then add comments, but only then.

> Document your install procedures, your architecture, your dev practices
> and do not allow hero-programmers to take stuff home in their heads and
> then get themselves killed in a motor accident on the weekend. Those
> super-hero programmers must transfer their skills to at least one other
> team member by pair programming.

Again, I agree and disagree. Don't document install procedures -- automate
them. Make your documentation executable and it will never go out of date.
And if you pair-program, you don't need to document your dev practices.

I agree with most of your other points, however.

///ark

Mark Wilden wrote:
> "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
> news:(E-Mail Removed)...
> > First of all, set up Sourcesafe so that developers can NEVER edit the same
> > file at once. A checkout should lock the file. This should really be the
> > case for all projects because if a file is big enough to be worked on by
> > more than one person it's probably hard to understand and in line for
> > refactoring anyway.
>
> I used to feel this way, too. And it's the default in VSS, so most people
> have never even tried using optimistic locking (where files aren't locked).
> But once I actually tried multiple checkouts, life became soooo much easier.
> No more dealing with the developer who leaves the office (or the company)
> early. No more haggling over who gets to edit a file. Essentially, no more
> concern with source control -- it becomes a useful tool, rather than a
> prison.
>
> What do you lose with multiple checkouts? Surprisingly little (especially if
> you have a good set of unit tests). It's remarkably rare for two developers
> to be working on the same part of the same file (if they are, that may
> indicate problems that source control was never designed to solve). If two
> developers are working on different parts of the same file at the same time,
> modern merge tools have a laughably easy time sorting things out. Try it!

I happen to use Subversion, rather than SourceSafe, and prefer the
optimistic
locking approach. Just let multiple people work on things, merge them,
and fix
the resulting collisions. It doesn't happen all that often.

>
> > Document EVERYTHING!!! from the word go. Use XML inline documentation and
> > keep it current.
>
> This is really anti-Agile, IMHO. The code is the documentation. If it
> doesn't explain itself well enough, then make it simpler. If you can't do
> that, then add comments, but only then.

Ick ick ick, EW. The code is NOT the documentation. The code just tells
you
what it DOES. The code does NOT tell what it was intended to do. I've
been a
maintenance programmer too often to believe the code. If the code were
always
right, we'd never have bugs.


>
> > Document your install procedures, your architecture, your dev practices
> > and do not allow hero-programmers to take stuff home in their heads and
> > then get themselves killed in a motor accident on the weekend. Those
> > super-hero programmers must transfer their skills to at least one other
> > team member by pair programming.
>
> Again, I agree and disagree. Don't document install procedures -- automate
> them. Make your documentation executable and it will never go out of date.
> And if you pair-program, you don't need to document your dev practices.

Hm. I think you have to document all procedures to some point. I agree
that
automation is preferable, but bear in mind that these things will need
to be changed
at some point (in all likelihood). Having it documented makes it easier
to modify
things, especially if you didn't write it in the first place. There's
nothing bad about
documenting intent.

>
> I agree with most of your other points, however.

Me too.

Matt

Thanks Chris, the link is to a resource that presents *exactly* the sort of
guidance I was looking for.

-S




"Chris Dunaway" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Smithers wrote:
>> Of course these tools (even the Team edition if we had it) wouldn't
>> prevent
>> us from getting into trouble... thus my inquiry (for articles, links,
>> tips,
>> suggestions, etc).
>
> This is an older article, but perhaps it will help:
>
> http://msdn.microsoft.com/library/de...ml/tdlg_rm.asp
>

Thanks for jumping in, Michael:

RE:
<< To be perfectly blunt, this really is the least of your worries... >>

LOL!

<< (with all due respect) >>

ROTFLMAO!!!

<< The real problem you should focus on is poorly written code...>>

Well, as long as we're searching high and low for the *real* problem (which
I somehow missed), I'll have to say that I somehow need to figure out how to
articulate a good question to the NG without having to list all of the
assumptions my question makes... like "assuming a team of developers who
make it a huge priority to write tight code...."

-S

Oh, and : )


"Michael Brown" <no_spam@_nospam.com> wrote in message
news:%(E-Mail Removed)...
>> Until now I have worked on small teams (1-3 developers) and we've been
>> able to stay out of each others way. Now I'm about to start work on a
>> project that will have 5 developers. I would appreciate some guidance on
>> how we can proceed to develop without having to worry about "who is
>> working on what files".
>>
>> We're developing with SQL Server 2005, VS 2005 Pro (no way management is
>> going to spring for the $10,000 team edition for everybody), and we'll
>> have Visual SourceSafe.
>
> To be perfectly blunt, this really is the least of your worries (with all
> due respect). You have SourceSafe so as long as everyone is checking out
> their files there should be little conflict (assuming nobody needs to
> fight over the same file all the time - parcel the files accordingly to
> avoid this - it shouldn't be much trouble). The real problem you should
> focus on is poorly written code (bad design, bad mechanics, lack of
> re-usability, lack of error checking/recovery, etc). This is responsible
> for 99% of all software problems and it's what everyone should be focusing
> most of their time on
>