Unless you are a micro-ISV or are developing on your own for fun, I doubt you are working in isolation.  You are probably working as part of a team of developers (and possibly testers, designers, etc) who are all working in parallel on the project.  I’ve been on the same team since my employer first started developing software, and I’ve been fortunate enough to watch our development process mature from a chaotic mess of E-mailed files and constant meetings to a saner, more automated process.  Here are the key tools that I think every development team needs to have (note that I have absolutely no ties what-so-ever to any of the products or projects listed below, I just happen to use and like them):

A Version Control System

Any development project needs a version control system (I even keep my hobby projects in a revision control system), but once you have more than one person working on a code base, version control is required.  You cannot get by without it.  E-mailing files around or hosting them on FTP does not work; I know because I’ve tried.  No, you need a version control system that will track who-did-what-and-when and allow you to quickly go back to any version of any file at any time. 

There are too many version control systems to list, some commercial, some free, some open-source, some not.  I’ve used Visual SourceSafe, Team Foundation Server, CVS, and Subversion, and my favorite is definitely the free and open-source Subversion project.  You can get a repository up and running in no time flat with the VisualSVN Server package.  From there, I recommend using the (also free and open-source) TortiseSVN client for interacting with the repository.

A Defect and Issue Tracking System

You need a way to track bugs that have been found, features that have been requested, and any other work that needs to be performed related to your software project.  It should be web-based so that everyone on the team can access it.  It should be lightweight enough to not interfere with people trying to do work, but it should be powerful enough to track what people are actually doing. 

For me, FogBUGZ is the way to go.  Joel pioneered the idea of simple defect tracking, and though FogBUGZ has grown more and more powerful with each release, it remains surprisingly simple to use.  The latest version includes time tracking, "evidence-based scheduling" to show you when you are really going to be ready to release that new version, a wiki, and of course, bug and feature tracking.

A Continuous Integration System

Do you have unit tests for your project?  Of course you do (if you don’t, you need to correct that ASAP).  But how often are you running them?  If you’re only running them when you think about it, or when you think you changed something that might impact the test, you are not getting the full benefit of unit testing.  In a complicated project, you don’t know how far down a code change is going to trickle.  Best-case, a code change is going to break something downstream so badly that it won’t even compile.  That kind of thing you will probably find when you build your project before releasing it.  Worst-case, a change will quietly break something downstream.  The code may still compile, but now the downstream code is no longer doing what it was intended to do.  Unless you run the unit tests for the downstream code, how will you know?  You need someone who is continuously checking the changes submitted to your version control system, verifying that they don’t break anything that’s already there.  Someone needs to verify that everything still compiles, and that all test cases still pass.  That can be a full-time job if you have a lot of code-churn.  But who wants that job?  Man, that would be terrible… constantly checking the version control system for new updates, downloading them, building everything, running all the unit tests, typing up reports about what’s broken, mailing them to the appropriate people… I don’t think many people would want that job.

That’s where continuous integration systems come in.  A continuous integration system takes on the role of monitoring your project, insuring that everything builds, and that all your tests pass.  When something goes wrong, it automatically notifies people so that corrective steps can be taken.  There aren’t many good free options here (there are a lot of commercial solutions, but I haven’t ever used one).  The best I’ve found is CruiseControl.NET.  It’s easy to set up, very configurable, and very powerful.  At my present employer, we have an instance of CruiseControl.NET monitoring eight inter-related projects ranging from web applications to GUIs to backend Windows services.  It’s not perfect, but if you are willing to invest a little bit of time in getting it up and running, it can save you a lot of time and pain.

That’s really not a complete list.  Aside from those things, you need a reliable communication tool (GTalk and Gmail ftw), good developers (remember that writing code does not make you a developer), and a good development process.  I might try to blog about those last two things on Friday if I can’t think of anything better to talk about.  Seriously, the stuff I’m working on now is 95% code reviews (which are interesting, but for the wrong reasons) and 5% mundane coding.  Anyway, are there any other critical components that you think are must-haves for a software development team?  If so, post ’em in the comments.