OT (slightly): Coordinating Multiple Developers

Discussion in 'Microsoft Dot NET Framework Forms' started by Smithers, Jun 21, 2006.

  1. Smithers

    Smithers Guest

    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, Jun 21, 2006
    #1
    1. Advertisements

  2. Smithers

    sloan Guest

    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" <> wrote in message
    news:OWyx$...
    > 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!
    >
    >
    >
     
    sloan, Jun 21, 2006
    #2
    1. Advertisements

  3. 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" <> wrote in message
    news:OWyx$...
    > 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!
    >
    >
    >
     
    Bob Powell [MVP], Jun 21, 2006
    #3
  4. Chris Dunaway, Jun 21, 2006
    #4
  5. Smithers

    Mark Wilden Guest

    "sloan" <> wrote in message
    news:...

    > 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.
     
    Mark Wilden, Jun 21, 2006
    #5
  6. > 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:)
     
    Michael Brown, Jun 21, 2006
    #6
  7. Smithers

    Mark Wilden Guest

    "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
    news:...
    > 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, Jun 21, 2006
    #7
  8. Smithers

    Matt Guest

    Mark Wilden wrote:
    > "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
    > news:...
    > > 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
     
    Matt, Jun 21, 2006
    #8
  9. Smithers

    Smithers Guest

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

    -S




    "Chris Dunaway" <> wrote in message
    news:...
    > 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/default.asp?url=/library/en-us/dnbda/html/tdlg_rm.asp
    >
     
    Smithers, Jun 21, 2006
    #9
  10. Smithers

    Smithers Guest

    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:%...
    >> 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:)
    >
     
    Smithers, Jun 21, 2006
    #10
  11. Smithers

    Mark Wilden Guest

    "Matt" <> wrote in message
    news:...
    >
    > 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! :)
     
    Mark Wilden, Jun 21, 2006
    #11
  12. 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" <> wrote in message
    news:OWyx$...
    > 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!
    >
    >
    >
     
    Cowboy \(Gregory A. Beamer\), Jun 22, 2006
    #12
  13. Smithers

    Mark Wilden Guest

    "Cowboy (Gregory A. Beamer)" <> wrote in
    message news:...

    > 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.
     
    Mark Wilden, Jun 22, 2006
    #13
  14. Smithers

    Matt Guest

    Mark Wilden wrote:
    > "Matt" <> wrote in message
    > news:...
    > >
    > > 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
     
    Matt, Jun 22, 2006
    #14
  15. Smithers

    Mark Wilden Guest

    "Matt" <> wrote in message
    news:...
    >
    > 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. :)
     
    Mark Wilden, Jun 22, 2006
    #15
  16. 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" <> wrote in message
    news:...
    > "Cowboy (Gregory A. Beamer)" <> wrote in
    > message news:...
    >
    >> 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.
    >
    >
     
    Cowboy \(Gregory A. Beamer\), Jun 24, 2006
    #16
  17. 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" <> wrote in message
    news:%...
    > "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
    > news:...
    >> 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
    >
     
    Bob Powell [MVP], Jun 28, 2006
    #17
  18. > 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" <> wrote in message
    news:...
    > "Matt" <> wrote in message
    > news:...
    >>
    >> 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! :)
    >
     
    Bob Powell [MVP], Jun 28, 2006
    #18
  19. Smithers

    Mark Wilden Guest

    "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
    news:%...
    >> 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.
     
    Mark Wilden, Jun 28, 2006
    #19
  20. Smithers

    Mark Wilden Guest

    "Bob Powell [MVP]" <bob@_spamkiller_.bobpowell.net> wrote in message
    news:...

    >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?
     
    Mark Wilden, Jun 28, 2006
    #20
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Daniel Bello Urizarri

    question for MS developers

    Daniel Bello Urizarri, Nov 18, 2003, in forum: Microsoft Dot NET Framework Forms
    Replies:
    1
    Views:
    206
  2. infoTEAM, inc.
    Replies:
    0
    Views:
    141
    infoTEAM, inc.
    Dec 12, 2003
  3. Replies:
    3
    Views:
    361
    Jay B. Harlow [MVP - Outlook]
    Jan 12, 2005
  4. Replies:
    2
    Views:
    241
  5. Guest

    Coordinating MD5 Hash Values for Passwords

    Guest, Jan 14, 2005, in forum: Microsoft Dot NET Framework Forms
    Replies:
    7
    Views:
    296
    Guest
    Jan 16, 2005
Loading...

Share This Page