Software Development Tools

[Thorin]

I started on a new project about a month back.  On this new project, we're using tools to help the development, build, and release processes that are new to me (although there's lots of people in the world already using them).  It's all .NET development, and Windows-specific.  However, some of these tools are cross-platform and I'd certainly consider using them to develop on a non-Windows platform with them.

Subversion
We store code in a Subversion repository.  Having used Visual SourceSafe for years, I had to get used to Subversion's merge-and-commit paradigm versus VSS's locking paradigm.  Now that I'm used to it, I have to say it makes perfect sense.
Benefit: Subversion copies the repository locally to your machine, so you can work on the code without being connected to the network.  You do need to connect when you want to commit changes, though.

TortoiseSVN
We generally access the code in the repository using TortoiseSVN.  TortoiseSVN integrates into your right-click menu in Windows Explorer, and also overlays an icon over folder and file icons indicating modification status (just like the shortcut arrow overlay). I've found TortoiseSVN to be very good at what it does, but you have to understand how Subversion works as TortoiseSVN is simply a GUI for Subversion commandline commands.
Benefit: TortoiseSVN wraps Subversion's commandline commands into a graphical user interface, which is easier to use.

Visual Studio
The Integrated Development Environments (IDEs) that we write actual code with are Visual Studio .NET 2003 and Visual Studio 2005.  Unfortunately we haven't found time to upgrade the older code from VS.NET 2003 to VS 2005, but it's on my list.  Also unfortunately, the code is written in VB.NET - after several years with C# I prefer C# over VB.NET (I find the code reads easier).
Benefit: Well, if you're writing .NET code for Windows, Visual Studio is hard to beat!  Intellisense, colour-coded text, etc.

NUnit
We have automated unit testing with NUnit.  These tests get run every time a build is performed, and can also be run by hand by developers using the NUnit GUI and NUnit Console apps.  NUnit tests are written in VB.NET and stored within the code base.
Benefit: Code gets unit tested (that means in small self-contained pieces) to ensure bugs don't come back in when the code has been changed.

NAnt
We have automated the build process with NAnt.  NAnt is an xml-based scripting language that lets you script the build process.  In our case, it gets the latest code, updates the version number, compiles the code, submits the changes, tags the changes, copies installers to the deployment server, and emails.  Our script can be configured with parameters passed to it, the most notable being branch.to.build (specifies what branch to build if not building from Trunk) and build.type (specifies what type of build to run - CruiseControl, Release, or Debug if not specified).
Benefit: You can set your build up on a build machine, so that you're not building on a developer machine.  This means that the build can run without slowing down developers.  The build can include any action you want to, including copying files (like MSIs) to certain locations and emailing when the build succeeds or fails.
Benefit: You can write a quick batch file that prompts the user for a version number and then calls the build script.  This makes it really easy to create release builds that need an update to the version number (e.g. going from 1.0.3 to 1.1.0).

CruiseControl.NET
We didn't want to run the NAnt script manually, so a CruiseControl.NET server was installed and configured to perform continuous integration.  We now have a continuous build and a nightly build.  The continuous build is set to compile the code whenever changes have been committed to the Subversion repository (it checks every sixty seconds), although it does not compile the deployment projects (these take fifteen minutes to compile!).  The nightly build is set to compile in the middle of the night if there were changes committed, and it compiles the deployment projects.
CruiseControl publishes results from the build to a web server for everyone to see, including build output, nunit test results, and latest commits and log entries.  But I didn't want to sit and refresh a web page, so I installed CCTray.  CCTray sits in your Taskbar Notification Area (aka System Tray) as a coloured icon with balloon popups, and tells you when builds are running, if they succeeded, if they failed, or even if they've failed more than once in row (known as "still failing").
Benefit: The builds run automatically and immediately after someone commits changes.  This means that if someone commits changes that cause compile or test errors, it's caught within ten minutes or so.  Hopefully the developer will get the email and realize what they've done wrong and fix it right away.
Benefit: Non-developers have an easy way of seeing whether the source code is being worked on, is compiling, and is passing unit testing.  No more bugging the developers!

Wiki
I'm a big fan of creating a development wiki, because developers can more easily record comments and thus are more likely to do it.  I also like wikis because they keep historical versions of the text and because anyone on the project can correct mistakes immediately.  I haven't got a specific piece of wiki software that I prefer, though.
Benefit: Quicker and better dissemination of information from one developer to another, and more likely to be kept up-to-date than squirreled-away Word docs.

Bug Tracking
Bug tracking software is a must-have, but many development projects just use Excel spreadsheets.  I've seen slapped-together web sites that let developers and testers just throw in comments, and I've seen huge enterprise-level ticket tracking software that's just a pain to work with.  On our project, we might try FogBugz.  Hopefully it's all it's cracked up to be.
Benefit: Centralized storage of bugs encountered, root problems, workarounds, and hopefully better ownership of bugs and their fixes.

-----

Anyway, there's what we use (or want to): Subversion + TortoiseSVN + Visual Studio + NUnit + NAnt + CruiseControl.NET (including CCTray) + [wiki software] + [bug tracking software]

I'm really enjoying working with these tools, and when I switch to another project I'll be pushing for having those tools if they're not there already.  Setting them up does require some work, though.  Expect that setting up Subversion, the NAnt build script, the CruiseControl continuous integration script, the wiki, and the bug tracker can take a person two weeks to a month or more.  It's easier to do this at the beginning of the project, of course.  The build script and continuous integration script will probably need tweaking as development occurs, and Subversion will probably get re-structured at times (like when code is branched).  However, In my mind the benefits far outweigh the time it takes to set up - now we get notified our code doesn't compile as soon as it's committed to the version control repository, creating releases with installers is a painless activity, and developers can continue working on code even if they're disconnected from the network.

[Mr. Analog]

Eclipse
Eclipse is a software platform comprising extensible application frameworks, tools and a runtime library for software development and management. It is written primarily in Java to provide software developers and administrators an integrated development environment (IDE).

It makes Visual Studio look dumb when it comes to refactoring tools, built in widgets and plug-in availablility.

Apache Ant
a Java-based software build system. NAnt is based on it, but from my understanding most .NET people are moving to Microsoft's MSBuild... anyway, we use ANT quite a bit.

GWT (http://code.google.com/webtoolkit/)
Google Web Toolkit (GWT) is an open source Java software development framework that allows web developers to create Ajax applications in Java. It is licensed under the Apache License version 2.0.

GWT Java-to-JavaScript Compiler
Translates the Java programming language to the JavaScript programming language.

If that don't get you interested I don't know what will...

UNA (http://www.n-brain.net/)
Collaborative text editing. Need I say more?

Other things that are good / fun to muck with:
Apache
Tomcat
MySQL

VirtualBox: (http://virtualbox.org/)
VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL). See "About VirtualBox" for an introduction.

[Tom]

I started on a new project about a month back.  On this new project, we're using tools to help the development, build, and release processes that are new to me (although there's lots of people in the world already using them).  It's all .NET development, and Windows-specific.  However, some of these tools are cross-platform and I'd certainly consider using them to develop on a non-Windows platform with them.

Subversion
We store code in a Subversion repository.  Having used Visual SourceSafe for years, I had to get used to Subversion's merge-and-commit paradigm versus VSS's locking paradigm.  Now that I'm used to it, I have to say it makes perfect sense.
Benefit: Subversion copies the repository locally to your machine, so you can work on the code without being connected to the network.  You do need to connect when you want to commit changes, though.

One thing about Subversion, since it doesn't stop people from making changes to stuff you might be working on, its a very good idea to "update" right before you go to commit. Sometimes other's changes will change things in a way that will get Subversion to not give you a warning about collisions, and just sortof improperly merge the two works. Also, if it does warn you about a collision, try not to firce the commit unless you're absoultely sure theres no problem.

[Mr. Analog]

I started on a new project about a month back.  On this new project, we're using tools to help the development, build, and release processes that are new to me (although there's lots of people in the world already using them).  It's all .NET development, and Windows-specific.  However, some of these tools are cross-platform and I'd certainly consider using them to develop on a non-Windows platform with them.

Subversion
We store code in a Subversion repository.  Having used Visual SourceSafe for years, I had to get used to Subversion's merge-and-commit paradigm versus VSS's locking paradigm.  Now that I'm used to it, I have to say it makes perfect sense.
Benefit: Subversion copies the repository locally to your machine, so you can work on the code without being connected to the network.  You do need to connect when you want to commit changes, though.

One thing about Subversion, since it doesn't stop people from making changes to stuff you might be working on, its a very good idea to "update" right before you go to commit. Sometimes other's changes will change things in a way that will get Subversion to not give you a warning about collisions, and just sortof improperly merge the two works. Also, if it does warn you about a collision, try not to firce the commit unless you're absoultely sure theres no problem.

If you are using TortoiseSVN and you commit a change that is in conflict and SVN cannot merge it, it won't let you commit the change without going through a bunch of annoying hoops. SVN will sometimes sloppily merge (which is worse IMHO) but at least can be recovered from.

At least you can branch the version that is questionable while keeping revisions of the previous file rolling and then merge when the problems have been resolved.

[Thorin]

In my experience (I had conflicts earlier today), TortoiseSVN indicated a conflict and I had to apply my human mind to determine which changes were the most important.  I tried to commit, TortoiseSVN reported the conflict, I double-clicked it and was presented with a three-way merge editor, I decided what stayed, and then I committed again.

I don't really consider that "annoying hoops" as I know full-well that no automated program can truly decide which changes are more important than which other ones.

I've worked with Visual SourceSafe, which locks the file you're working on.  I'd rather have a possible collision that I have to sort out by hand then just not being able to edit a section of source code for the next three or four days while I wait for the other guy to check the file back.

[Mr. Analog]

The annoying hoop with Tortoise is once if you've picked through the file and made your revisions you have to ensure you clean up the diff files otherwise you get weirdness later when you have to merge again.

I think there's also a threshold for how much you can manually merge, if you work with a team member who uses a code formatting plug-in I pity you.

[Thorin]

We're seriously considering FogBugz 6 for our project as well.

$25 per person per month if they host it (only people that actually accessed the site in the month are counted).
$199 per seat if we buy it and host it ourselves.

Here's a 12-minute demo that even kept my wife watching: http://media.fogcreek.com/fogcreek.com/FogBugz/60movie/60movie.html

It looks like some neat software!

[Tom]

Yeah, the problem I mentioned is something with subversion itself, its not really depenant on the client used. Sometimes it doesn't seem to notice changes to a file when you're merging (especially if you didn't update before hand), as long as the diff is compatible and doesn't show any conflicts, there still may be some, that is some change was made that makes yours buggy, uncompilable, or just obsolete, or the other way around. In this case its not really Subversion's fault, its more of a conceptual problem if you're used to locking VCSs where files can't be changed while you're working on them.

It is really important to always update before making any changes, and before committing them to sort out any issues. I like to do some tests before committing as well, to make sure everything works as expected.

[Mr. Analog]

Dojo
http://dojotoolkit.org/
A suite of tools that give you a rich GUI for the web.

Tatami
http://code.google.com/p/tatami/
The project aims to integrate the Google Web Toolkit (GWT) and the DOJO framework. Indeed the DOJO framework is very rich in term of widgets and utilities (fisheye, slider, drag and drop functionality) and the main interest is to take benefits of the huge work which has been already done by the DOJO community. In other words, it means: the DOJO widgets become GWT widgets, the DOJO utilities become GWT helper.

JExplore:
http://www.duke.edu/~rrd/main.html
Universal file explorer.