Multiple developers working on an application

  • Thread starter Thread starter Sheri
  • Start date Start date
S

Sheri

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....which
would be a certain screen and then combine them back
somehow. Or what is the best way to handle this?

Thanks for any help.
 
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
 
Back
Top