Is your development process "Broken"?
Recently I was asked to add something to an internal web project that has gone through a number of iterations and also a number of developers. I spent the better part of an afternoon, and part of the next morning just getting everything out of Sourcesafe to build. I complained, because most of this was due to either developer lack of knowledge, lack of professional standards, or just plain "don't care". This is a list of some of the initial recommendations I made when asked:
List of items that should be fixed with development process:
1) Developers should always arrange their projects, solutions, and the way they are source controlled with a view toward making it easy for new developers to be able to begin work on the solution with the minimum amount of hassle. This includes:
a. Put 3rd party assemblies in the solution as Solution Items and have them checked in with the solution so that people don't need to set mapped drives to shares containing libraries. These can be easily updated and developers can Get Latest to stay in sync.
b. Make all references PROJECT references. If the developer already has this project from Sourcesafe on his hard drive, it will synchronize automatically from Sourcesafe, they will not need to get a separate copy. Keep all the PROJECTS that are used WITHIN THE VISUAL STUDIO SOLUTION whenever possible. Project references allow you to debug through different projects in the solution, and they also enable you to keep changes made by members of your team synched-up.
c. Name your solutions appropriately in Sourcesafe so that new developers will not mistakenly get the wrong version or one that is not being used.
d. Name your Projects and the namespaces of your classes in a project consistently. don't have namespace Foo.Bar in project named Blat.Bork, and then have another project in the solution that looks like "Foo.Bar"!
e. Do not alter the default build outputs of a project. Project output is normally directed to the /bin/debug or /bin/release folder.
f. Correct any and all compiler errors and warnings, even if they do not prevent successful compilation. If the compiler says Not all code paths return a value then FIX IT before checking in your code. If the compiler has a warning about an ambiguous cast, FIX IT. If the compiler says a variable was declared but never used, then FIX IT. There is NO REASON why a professional developer cannot have a Solution that has NO WARNINGS after it is built.
g. Check in all code but only if it builds and has been tested first. Use comments so other developers can see what changes you did. Did you test to see if OTHER PARTS of the Solution haven't been broken by your changes? You'd better!
h. Set all Assembly versions to 1.0.0.0 in the assemblyinfo.cs file, not 1.0.*.*. This prevents overwrite errors because of automatic build number incrementation. If you really have a New Version then hard code it in.
2) A new developer should be able to tell Visual Studio to open Solution from source control, download all the projects, compile and build the project within 20 minutes. If this cannot be done, either your source control arrangement is not acceptable, or your developer team has not been educated in the above concepts, or both.
3) Whenever possible ambiguities and misunderstandings about projects, naming conventions and other similar items can cause problem, it is incumbent on each developer to think about the other people who may need to work with their code and take appropriate steps to ensure that their development experience goes smoothly. Usually this is simple common sense, and asking the question. "What does this affect?"
There is nothing that PISSES ME OFF more than a shoddy development team effort that reflects a lack of planning, discipline and basic rules of the road. If I were the boss and you did this stuff on my team, YOU WOULD BE GONE.
List of items that should be fixed with development process:
1) Developers should always arrange their projects, solutions, and the way they are source controlled with a view toward making it easy for new developers to be able to begin work on the solution with the minimum amount of hassle. This includes:
a. Put 3rd party assemblies in the solution as Solution Items and have them checked in with the solution so that people don't need to set mapped drives to shares containing libraries. These can be easily updated and developers can Get Latest to stay in sync.
b. Make all references PROJECT references. If the developer already has this project from Sourcesafe on his hard drive, it will synchronize automatically from Sourcesafe, they will not need to get a separate copy. Keep all the PROJECTS that are used WITHIN THE VISUAL STUDIO SOLUTION whenever possible. Project references allow you to debug through different projects in the solution, and they also enable you to keep changes made by members of your team synched-up.
c. Name your solutions appropriately in Sourcesafe so that new developers will not mistakenly get the wrong version or one that is not being used.
d. Name your Projects and the namespaces of your classes in a project consistently. don't have namespace Foo.Bar in project named Blat.Bork, and then have another project in the solution that looks like "Foo.Bar"!
e. Do not alter the default build outputs of a project. Project output is normally directed to the /bin/debug or /bin/release folder.
f. Correct any and all compiler errors and warnings, even if they do not prevent successful compilation. If the compiler says Not all code paths return a value then FIX IT before checking in your code. If the compiler has a warning about an ambiguous cast, FIX IT. If the compiler says a variable was declared but never used, then FIX IT. There is NO REASON why a professional developer cannot have a Solution that has NO WARNINGS after it is built.
g. Check in all code but only if it builds and has been tested first. Use comments so other developers can see what changes you did. Did you test to see if OTHER PARTS of the Solution haven't been broken by your changes? You'd better!
h. Set all Assembly versions to 1.0.0.0 in the assemblyinfo.cs file, not 1.0.*.*. This prevents overwrite errors because of automatic build number incrementation. If you really have a New Version then hard code it in.
2) A new developer should be able to tell Visual Studio to open Solution from source control, download all the projects, compile and build the project within 20 minutes. If this cannot be done, either your source control arrangement is not acceptable, or your developer team has not been educated in the above concepts, or both.
3) Whenever possible ambiguities and misunderstandings about projects, naming conventions and other similar items can cause problem, it is incumbent on each developer to think about the other people who may need to work with their code and take appropriate steps to ensure that their development experience goes smoothly. Usually this is simple common sense, and asking the question. "What does this affect?"
There is nothing that PISSES ME OFF more than a shoddy development team effort that reflects a lack of planning, discipline and basic rules of the road. If I were the boss and you did this stuff on my team, YOU WOULD BE GONE.
I wish management understood that.
ReplyDelete