Multiple developers working on an application

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Sheri

    Multiple developers working on an application

    Our working environment traditionally has a new project
    (application) that has multiple developers within the
    development of that project. I need to know the best way
    to start development. Is it better to have an individual
    team members have one solutions with one project....whic h
    would be a certain screen and then combine them back
    somehow. Or what is the best way to handle this?

    Thanks for any help.
  • William Ryan  eMVP

    #2
    Re: Multiple developers working on an application

    Sheri:

    There's no absolute, but in general here are some considerations:

    -In a collaborative envirnoment , source control and configuration
    management aren't just things you 'should' do, they are a must. The ability
    to roll back changes and ensure that people don't overwrite each other's
    work unintentionally is probably the most important issue.
    - The main thing afterward is to keep things modular. Business Logic, UI
    etc should all be seperated and building things in a Lego fashion is
    critical (and to this end, this applies to individual developers as well as
    large teams). A car for example is made up of many small parts and by
    keeping things atomic, you minimize the chances that developer A will be
    working on something that developer B needs.
    - A solution supports multiple projects for a reason, and yes, I think you
    should bust the project into as many projects as their are logical units.
    Even if you bust things into Business Logic, UI etc, you can still break
    things down from there...for instance, a HRM app could have a Payroll
    Component and a HR component. Within those you could still further break
    things down. How you do this depends on the logical grouping...ie are these
    two functions fundamentally different from each other? If so, breaking them
    up would make sense, and you can still split UI , DataAcess and Business
    logic up from there. Some of this stuff will be global to the solution so
    keep that in mind and you may want to build that into a global Utility
    library.
    - Make sure that everyone gets the latest updates every time they open a
    project so they don't build things based on code that's changed or doesn't
    exist any more.
    - Do smoke tests frequently, daily if possible. That way you won't go too
    far down one path only to realize that there are code incompatibiltes .

    Obviously configuration management and project management is something
    people write Ph.D dissertations on but these are some general guidelines
    that I've certainly found helpful. you may want to check out some books
    like Code Complete or the like to get an in depth look at the process.

    HTH,

    Bill
    "Sheri" <anonymous@disc ussions.microso ft.com> wrote in message
    news:e97301c3f0 dc$b5ec4ee0$a00 1280a@phx.gbl.. .[color=blue]
    > Our working environment traditionally has a new project
    > (application) that has multiple developers within the
    > development of that project. I need to know the best way
    > to start development. Is it better to have an individual
    > team members have one solutions with one project....whic h
    > would be a certain screen and then combine them back
    > somehow. Or what is the best way to handle this?
    >
    > Thanks for any help.[/color]


    Comment

    Working...