PC Review


Reply
Thread Tools Rate Thread

OT (slightly): Coordinating Multiple Developers

 
 
Mark Wilden
Guest
Posts: n/a
 
      21st Jun 2006
"Matt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> 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.


I use Subversion, too, and I agree.

> 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.


If the code doesn't tell you what it's intended to do, then it's wrong.

> I've been a maintenance programmer too often to believe the code. If the
> code were
> always right, we'd never have bugs.


That's why unit tests are better documention than some Word file that gets
updated just about ... never. Instead of stopping coding to write
documentation, continue coding and write a test that a) shows what the code
is intended to do, and b) -proves- that this is the case.

> 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.


The problem with documentation is a) it doesn't ship the current product (it
only makes shipping the next product easier), hence b) no one has time to do
it, hence c) it's always out of date, and d) no one uses it.

If your experience is different, my hat's off to you and your teams!


 
Reply With Quote
 
 
 
 
Cowboy \(Gregory A. Beamer\)
Guest
Posts: n/a
 
      22nd Jun 2006
As long as you have exclusive checkouts, you should be fine. Just make sure
you have one person create the web projects and get them correctly into
source safe. Then, the others check out the source and right click web
project folders to make them virtual directories (web sharing under
properties).

The most difficult part is getting things into SourceSafe. If you use the
default method in Visual Studio it makes really crappy folders for web
projects, IMO. This is esp. true with websites.

The way I do it is create the project underneath the root where you are
having SourceSafe root working folder. You then create a folder for the new
project and check in the files. Even if this is an existing website, get it
checked in first, because working with multiple directories is a royal pain.
After you have it in, delete everything in the folder and get latest and
make sure you can still start up the web site. If so, get the other devs to
check out and create a virtual root for the web project. Make sure they can
connect. If everything is good, have one person open the project and put any
other web files in the project by add existing file(s). You can create
directories, etc. and then check the whole thing in. Now everyone should be
fine.

NOTE: For other types of projects, like class libs and smart clients, it is
not as hard.

If you want multiple people on the same file, you can aim for Vault, as
SourceSafe is not a good system for merging. Vault is not horribly expensive
and much faster at retrieve than SourceSafe.

As far as Team System goes, the MSDN subs with the Team SKUs (you do not
have to have Team Suite, any of the SKUs is able to connect (I would
recommend developer if you go this direction)). You also get Workgroup
edition of Team Foundation Server, which works with up to five people. If
you add more, you will have to upgrade to the full TFS, which is about $3k.
If you already have MSDN, you can do a free upgrade to the Team product of
your choice. I would consider one upgrade to Team Suite, if budget allows,
but it is not necessary.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"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!
>
>
>



 
Reply With Quote
 
 
 
 
Mark Wilden
Guest
Posts: n/a
 
      22nd Jun 2006
"Cowboy (Gregory A. Beamer)" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...

> If you want multiple people on the same file, you can aim for Vault, as
> SourceSafe is not a good system for merging. Vault is not horribly
> expensive and much faster at retrieve than SourceSafe.


I've worked with VSS and optimistic locking with a small team like
Smithers's, and it's fine. However, I do recommend Subversion, which is
free.


 
Reply With Quote
 
Matt
Guest
Posts: n/a
 
      22nd Jun 2006

Mark Wilden wrote:
> "Matt" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >
> > 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.

>
> I use Subversion, too, and I agree.
>
> > 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.

>
> If the code doesn't tell you what it's intended to do, then it's wrong.


The code is quite often wrong. The problem I find is that people THINK
the code
tells you what it is doing. Unfortunately, without some background in
what the
code was intended to do (the problem we are solving) it is difficult to
know if the
code is right or not.

>
> > I've been a maintenance programmer too often to believe the code. If the
> > code were
> > always right, we'd never have bugs.

>
> That's why unit tests are better documention than some Word file that gets
> updated just about ... never. Instead of stopping coding to write
> documentation, continue coding and write a test that a) shows what the code
> is intended to do, and b) -proves- that this is the case.


I've had this discussion with people before. You are right, in that
unit tests and
such are useful. For any large scale system, however, unit tests are
often more
optimistic than you would like to think. Simple test coverage doesn't
show up
problems that occur over periods of time in real-time systems, for
example. And
the chances of you covering all possible data irregularities is .. to
be kind.. unlikely.

You make a good case about the documentation not being updated. This is
a
serious problem and one that should be considered when writing the code
in the
first place. A change to the code that is not reflected in a change to
the documentation is a worthless change. That's why my groups usually
have documentation testing at both the user and programmer levels.

>
> > 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.

>
> The problem with documentation is a) it doesn't ship the current product (it
> only makes shipping the next product easier), hence b) no one has time to do
> it, hence c) it's always out of date, and d) no one uses it.


Yeah, I know. But that's not the documentation's fault. That's the
fault of whoever
didn't update it, or his/her manager. The fact that documentation is
rarely done right
doesn't make it less valuable. That's like saying code is worthless
because every non-trivial application has bugs.

>
> If your experience is different, my hat's off to you and your teams!


I've had good and bad experiences with docs. I'm not really disagreeing
with you,
there's never time allocated to do documentation right. Maybe we can
change that,
however.

Thanks for the discussion, its been valuable.

Matt

 
Reply With Quote
 
Mark Wilden
Guest
Posts: n/a
 
      22nd Jun 2006
"Matt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> The code is quite often wrong.


Of course, "quite often" is not an exact quantification, but I have not
worked anywhere where the code was what I'd call "often wrong," nor would I.

> The problem I find is that people THINK
> the code tells you what it is doing. Unfortunately, without some
> background in
> what the code was intended to do (the problem we are solving) it is
> difficult to
> know if the code is right or not.


Again, that's where tests come in.

> I've had this discussion with people before. You are right, in that
> unit tests and such are useful.


For me, they're essential. I do Test-Driven Development (TDD), where I write
no new code without a failing test. In other words, I don't fix a bug until
I have an automated test that exposes the bug. And I don't write a new
feature until I have a test that proves that feature is missing.

> For any large scale system, however, unit tests are
> often more optimistic than you would like to think. Simple test coverage
> doesn't
> show up problems that occur over periods of time in real-time systems, for
> example. And the chances of you covering all possible data irregularities
> is .. to
> be kind.. unlikely.


You're talking about a different kind of testing than I am. TDD, it is often
said, isn't about testing. I think that's somewhat overboard, but it has a
kernel of truth. You're not pretending to be a QAer, whereby you verify that
the code is 100% bug-free. Rather, you're expressing in tests what the code
is supposed to do. It's a way of designing and documenting. It does have the
benefit of reducing bugs, but that's not its purpose, until you start
refactoring (improving the design without changing its functionality).

> You make a good case about the documentation not being updated. This is
> a serious problem and one that should be considered when writing the code
> in the first place. A change to the code that is not reflected in a change
> to
> the documentation is a worthless change.


I almost agree, except that I replace "documentation" with "test." Code that
doesn't have tests is worthless, IMO.

> Yeah, I know. But that's not the documentation's fault. That's the
> fault of whoever didn't update it, or his/her manager. The fact that
> documentation is
> rarely done right doesn't make it less valuable. That's like saying code
> is worthless
> because every non-trivial application has bugs.


But coding is not "rarely done right," whereas documentation is. In a
perfect world, documentation might be the answer to improving the quality of
code. In this world, TDD (IMO) is the best way to achieve this.

>> If your experience is different, my hat's off to you and your teams!

>
> I've had good and bad experiences with docs. I'm not really disagreeing
> with you, there's never time allocated to do documentation right. Maybe we
> can
> change that, however.


The trouble is that documentation quality has been bemoaned since Day 1, and
nothing seems to be able to improve it. The reason (I feel) tests are better
is that you can automatically prove whether or not they document the code.

> Thanks for the discussion, its been valuable.


Same here, Matt. You can probably tell I'm a bit of a fanatic about TDD. In
fact, I just got back from a Bay Area XP meeting, where we spent four hours
talking about this stuff.


 
Reply With Quote
 
Cowboy \(Gregory A. Beamer\)
Guest
Posts: n/a
 
      24th Jun 2006
With a small team, that is probably true. I would personally use anything
but SourceSafe.

Subversion is not a bad system, so I can certainly concur with the choice. I
am rather partial to Team System now, but it can get pricey for small
companies.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"Mark Wilden" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Cowboy (Gregory A. Beamer)" <(E-Mail Removed)> wrote in
> message news:(E-Mail Removed)...
>
>> If you want multiple people on the same file, you can aim for Vault, as
>> SourceSafe is not a good system for merging. Vault is not horribly
>> expensive and much faster at retrieve than SourceSafe.

>
> I've worked with VSS and optimistic locking with a small team like
> Smithers's, and it's fine. However, I do recommend Subversion, which is
> free.
>
>



 
Reply With Quote
 
Bob Powell [MVP]
Guest
Posts: n/a
 
      28th Jun 2006
I can assure you that when you see four teams with over 30 developers think
that they can share a file and modify method signatures at-will you will
beleive absolutely in no multiple checkouts.

Anti-agile or no, when one is at the wrong end of a 1.5 million line project
that has no documentation whatsoever and a maintenance cost of over 80% of
budget one begins to believe strongly in the power of documentation and the
futility of adopting agile methodologies in legacy code.

Good development is all about communication and maintaining intellectual
property. This implies documentation and sharing of knowledge. Remember,
only primitive societies maintain an oral history, then they grow up and
learn to make documents.

--
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.



"Mark Wilden" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> "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
>



 
Reply With Quote
 
Bob Powell [MVP]
Guest
Posts: n/a
 
      28th Jun 2006
> If the code doesn't tell you what it's intended to do, then it's wrong.

That'll get you through loads of job interviews with people who actually
know their elbows from less apparent parts of their anatomies.

How many man-days would you loose on a team if you had to tell every new
developer "Go read the code and come back when you understand" ?

Why do you think MS provide MSDN?. It's not a benevolent method to keep
document writers in work you know.

--
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.



"Mark Wilden" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Matt" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>
>> 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.

>
> I use Subversion, too, and I agree.
>
>> 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.

>
> If the code doesn't tell you what it's intended to do, then it's wrong.
>
>> I've been a maintenance programmer too often to believe the code. If the
>> code were
>> always right, we'd never have bugs.

>
> That's why unit tests are better documention than some Word file that gets
> updated just about ... never. Instead of stopping coding to write
> documentation, continue coding and write a test that a) shows what the
> code is intended to do, and b) -proves- that this is the case.
>
>> 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.

>
> The problem with documentation is a) it doesn't ship the current product
> (it only makes shipping the next product easier), hence b) no one has time
> to do it, hence c) it's always out of date, and d) no one uses it.
>
> If your experience is different, my hat's off to you and your teams!
>



 
Reply With Quote
 
Mark Wilden
Guest
Posts: n/a
 
      28th Jun 2006
"Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
news:%(E-Mail Removed)...
>> If the code doesn't tell you what it's intended to do, then it's wrong.

>
> That'll get you through loads of job interviews with people who actually
> know their elbows from less apparent parts of their anatomies.


Actually, I've decided never again to interview with companies that aren't
agile, and who don't understand the views I've expressed in these posts.

> How many man-days would you loose on a team if you had to tell every new
> developer "Go read the code and come back when you understand" ?


They're going to have to read the code anyway. Far better for them to read
it than to think they'll actually understand the codebase after reading the
(typical) documentation.

(Mind you, I'm not saying there aren't very large shops where documentation
is kept up-to-date. I've never worked for one, and I don't think most
developers have, either, judging from the help-wanted ads.)

> Why do you think MS provide MSDN?. It's not a benevolent method to keep
> document writers in work you know.


MSDN is library documentation.


 
Reply With Quote
 
Mark Wilden
Guest
Posts: n/a
 
      28th Jun 2006
"Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
news:(E-Mail Removed)...

>I can assure you that when you see four teams with over 30 developers think
>that they can share a file and modify method signatures at-will you will
>beleive absolutely in no multiple checkouts.


I don't credit "assurances" from people who have such an emotional
attachment to their viewpoints. Instead, I tend to learn from folks like
Mike Mason, the author of "Pragmatic Version Control."

Anway, I'm sorry you work with such lousy teams. If you worked with better
people, you might respect the agile viewpoint more.

> Anti-agile or no, when one is at the wrong end of a 1.5 million line
> project that has no documentation whatsoever and a maintenance cost of
> over 80% of budget one begins to believe strongly in the power of
> documentation and the futility of adopting agile methodologies in legacy
> code.


See above.

> Good development is all about communication and maintaining intellectual
> property. This implies documentation and sharing of knowledge. Remember,
> only primitive societies maintain an oral history, then they grow up and
> learn to make documents.


I'm saying the code is the documentation. What does that have to do with
oral history?


 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Dear Stevie "Developers, Developers, Developers!" Ballmer..... Scott Windows Vista General Discussion 0 21st Feb 2007 05:29 AM
OT (slightly): Coordinating Multiple Developers Smithers Microsoft C# .NET 27 29th Jun 2006 09:36 PM
OT (slightly): Coordinating Multiple Developers Smithers Microsoft Dot NET 27 29th Jun 2006 09:36 PM
why Microsoft Developers not like others developers (Java Dev, Linux Dev, etc)? Neo Microsoft VC .NET 2 8th Jun 2006 09:02 AM
Google/Yahoo is an Operating System ( or Why Web Developers Are Developers ) Sheldon 'Bailo' Leonard Microsoft Dot NET 0 22nd Mar 2004 08:10 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 04:47 AM.