Patrick Cauldwell is one of the architects on our Next Generation Banking System. A while back I asked him to write up our guiding principles for not only educating new developers but also for indoctrinating existing team members into our world view. He published it on his blog as This I Believe...The Developer Edition.
It's a great list. Here's a partial listing of the first two levels of his outline. Be sure to visit his post for the complete outline. It's bent towards .NET, because the stuff he's doing is .NET, but the general ideas are usable elsewhere.
What guiding principles do you follow at your development shop?
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
There are good reason not to use Window authentication...
In the end, you should see bunches of projects/dlls which go together, while between the bunches there is almost no dependence whatsoever. The boundaries between bunches will almost always be an interface project/dll.This will have the pleasant side-effect of enabling concurrent development of bunches with developers hardly ever stepping on each other’s toes. Actually, the number of projects in a given developer’s solution will probably decrease, since they no longer have to deal with all parts of the system.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.