In a past life, I used to teach cooking classes and as a class exercise at the end of the first class I would ask my students to cook a particular dish, using a collective set of ingredients, and bring it to the next class. Each student approached the problem differently, using their own techniques and tools, and they all mixed in their own "secret sauce" to improve on the collective ingredients. 
It was interesting that despite starting with the same ingredients, the students ended up in wildly different places and with different quality. The difference came from the little things - the tools, the techniques, and each chef's secret sauce.
Drupal development, in a lot of ways, is like cooking. For the most part, it starts with the same basic ingredients (Drupal core + contributed modules) and often follows common recipes (make content types, create views, write custom modules), but where you end up as a final product matters a lot on the tools, techniques, and secret sauce you work with. At Chapter Three we have been doing Drupal development as a team for over three years and have chosen our tools, refined our techniques, and perfected our secret sauce in making great Drupal websites. Over the next three blog posts, we will talk how we do the work we do.
The Tools
SVN for Version Control
The ability to selectively save and revert your work is something I often wish for when cooking and find extremely useful when coding. At Chapter Three we use SVN version control for all of our projects, big and small. This allows us to effectively manage projects with multiple developers and allows us to integrate external developers into our client process. While we recognize there are other version control systems out there with more features (Bazaar, Git), we choose SVN because of its relative simplicity and familiarity to our developers, themers, and clients.
Trac for Code History and Bug Tracking
To complement SVN with each site we roll out we also include a separate installation of Trac. 
This open source package allows us to see a timeline of our SVN commits and get visual diffs between revisions. This is helpful in auditing specific pieces of code (what happened and when) and provides a lot of assisstance in tracking down problems that might arise (if the module was broken on Friday, what changes were made to it on Wednesday and Thursday?) To manage our credentials between Trac instances we use our project management Drupal instance to control the HTTP authentication for Trac.
Drush
I whole heartedly agree with @ronald_istos that "drupal without drush is like life without mobile phones .. you know you managed just fine but now you just can't imagine how". Although our average site containing roughly 30 modules, installing and updating all of the modules is made really easy with Drush. With each site rollout we also deploy a symlinked wrapper around Drush that identifies the project that needs updating, switches context to the developers sandbox, and pushes up any changes to SVN. This makes updating modules on a Drupal site as easy as drush updatecode. To quickly turn on and off modules the commands drush enable module and drush disable module does wonders to increase productivity.
Beyond the module management, Drush is a venerable swiss army knife of Drupal functionality allowing a developer to log directly into the MySQL database with the credentials the Drupal installation uses (drush sql cli), runs cron (drush cron), run any pending database updates (drush updatedb) and much much more. It is really easy to extend Drush's functionality and we have found this very helpful when doing extensive data imports and exports. All in all, the centeralization of all of this functionality to the command line (now not even a module!) is very powerful and indespensible to our development process.
2May 09, 2011
As I mentioned previously, we use SVN version control for all our projects and to take full advantage of this we give every developer their own sandbox copy of the code located at projectname.chapterthree.com/ ~username. This allows the developer to work in isolation and only commit up changes when they are ready to have them reviewed. We have an automatic SVN post-commit hook that fires on each commit to update our general development instance (project.chapterthree.com) with the latest and greatest code. There are occasionally SVN conflicts that need to be resolved, but its much safer than trying to work off the same general copy of the code - in fact, our SVN post-commit hook explicitly forbids commits from any non-sandboxed copy of the code.
