Development is treated as being different from maintenance, somehow more special and elite. Maintenance programmers, however, have solved problems that developers tend to keep reinventing.
If your team uses modern development processes, consider that each module gets created only once, but will be reviewed, and then maintained until its development release. If your team uses XP or a spiral lifecycle method, this is even more evident: you keep maintaining and promoting modules continuously. Unless you are a miraculous coder, I think you'll edit each module after its initial creation. I usually like to< em> create my modules incrementally with stubbed-out member functions and later fill-in the blanks.
Once you accept that development is maintenance, its easier to justify the team working within a source control manager [SCM] from the start. You use SCM to safeguard your checkpoints as you go to minimize the risk of loss or regression.
If your team use the daily build and smoke-test, you notice the pattern of maintenance. In this pattern, a developer acquires a [somewhat] stable version of some code products from the shared repository, destabilizes them to make a change, restabilizes them and delivers them back into the shared repository. Any change has to break correctness until it is completed or is backed-out.
A classic problem for a team of developers is that one person needs to change the modules that another person needs stable. Even worse: the second person may also want to change some of the same modules. [Have you ever tried to share the Resource files for a single VC++ executable? or the base class object of a polymorphic set of classes?] A decent SCM should make visible "that's checked-out to Fred", so dynamic work balancing can be done by members of the team without begging the team lead to intervene. This is the price we pay be able to divide the work between the multiple developers working concurrently. Without this parallelism, large projects would be impossible.
A second problem appears in maintenance whenever the initial release has been promoted: what components in the messy test environment need to be promoted with the next release? This gets even chancier if there is ongoing work in the development stage that is not intended for promotion until the next release cycle. It's all too easy to lose and revert a change to a supporting source module, especially if you weren't sure it changed. Your refactoring may change the directory locations of files in the build so now the project .MAK has changed since last release and thus needs to be promoted. What if a trial refactoring that didn't work out? Your team deserves all the change bookkeeping assistance that your SCM tools can give you.
My experience is that the current tools and integrated development environments do support these situations pretty well, but only if you take the time to configure them for these maintenance cycle processes before you start cutting code. Retrofitting SCM and compiler options across all the teams' PCs is not fun, and is just plain disruptive.
