在我看来，关于Joel 测试的问题 #1 到 #4都是关于正在使用的开发工具和为开发人员提供的支持系统：
我只是好奇对于没有大银行账户的小型开发商店有哪些免费/便宜（但很好）的工具来获得对这些问题的肯定答案。
对于源代码控制，我知道 Subversion 是一个很好的解决方案，如果你是一个单人商店，你甚至可以使用 SourceGear 的Vault。
我将 NAnt 用于我的大型项目，但还没有设置脚本来构建我的安装程序以及运行混淆工具作为一个步骤。还有其他建议吗？
如果您可以一步回答“是”，我认为创建日常构建会很容易，但是您会推荐哪些工具来自动化这些日常构建？
对于一两个人的团队，已经在 SO 上讨论过您可以使用 FogBugz On Demand，但是对于小型团队，还有哪些其他错误跟踪解决方案？
我的首选堆栈：
1）颠覆。我对分布式源代码控制很感兴趣，但还没有机会尝试任何愤怒。对于集中式解决方案，svn 是坚如磐石的。
2）蚂蚁。Maven 在工作时使用起来很有趣，但作为一个老蚂蚁黑客，我发现一旦出现问题，maven 就很难遵循。
3）哈德逊。到目前为止没有被提及，但绝对值得研究。令人难以置信的可用和积极维护的工具。以前我们为 Anthill Pro 付费，它看起来很脆弱，每次搞砸时都很难修复。
4) 我们为 jira 付费。不便宜，但比我们看到的开源选项更有用，而且非常灵活。
我的工程堆栈：
毫无疑问，这些选择受到我的开发堆栈的影响，其中最常见的包括 Ruby、Rails、SQLite、Firefox 和 OSX。
您可能想查看我的一个现有问题，以找到 Team System 的替代方案。里面也有很多推荐。
我是一个少音节的人;-)
确保使用某种版本控制，开发人员可以轻松地创建私有分支，然后将他们的私有分支压缩到主分支上的单个提交中。这样，个人开发人员——而不是组织——可以获得版本控制的好处，而不会因提交中断而污染任何其他人的代码（并减慢他们的工作）。
这个特性是我喜欢 git 的地方。我认为它只存在于分布式版本控制系统中；不过，使用 DVCS 并不意味着您实际上必须进行分布式开发。
关于一步构建，make 是默认构建工具，它适用于大多数任务。除非您有充分的理由不这样做，否则我会这样做。
您想要每日构建，请将构建命令放在您的 cron.daily 中。如果需要，设置一个 procmail 挂钩来处理来自 cron 的邮件。
对于错误跟踪，使用$(apt-cache search bug tracking). 基本上，只要它在盒子上写着“错误跟踪器”并且您知道其他人正在使用它，它可能会正常工作。常客中有 bugzilla、mantis 和 trac。
我没有任何工具可以建议，但我确实对日常构建有一些建议。我总是对这个问题回答“是”，即使我们没有每日构建。相反，每次有人提交时我们都会进行构建。因此，我们几乎可以立即发现任何问题。如果我们的任何项目曾经有足够的 LOC 构建花费的时间超过微不足道的时间，那么这样做也会在日常构建的方向上优雅地降级。
axoSoft OnTime是一个相对便宜的好问题跟踪器。在获得 MS TFS 之前，我已经使用了多年。
Nant和CruiseControl是我的环境的主要内容。
我认为您不再需要在 .Net 上进行混淆（请参阅另一个回复）
我不会考虑 Vault，SVN 目前确实是市场领导者（而且是免费的）。Git 看起来很有前途，但目前只是命令行，学习曲线陡峭。
MSBuild 在 .Net 2 或 3.5 上击败 NAnt
CC.Net 非常好。
查看这些关于使用 MSBuild、CruiseControl.NET、FxCop、NUnit、NCover 和 Subversion 进行持续集成的文章...
我目前正在使用 SVN，但我通常在结帐到开发服务器上的网络驱动器时遇到很多问题或问题。往往存在需要大量钓鱼才能解决的锁定问题。可能是使用 WebDav 访问方法，可以缓解其中的一些问题，但我还没有尝试过。
Bugzilla、Trac 或 Fogbugz 中的任何一个都可以帮助您进行错误跟踪，并且每个都提供导出功能，因此您以后可以随时改变主意。此外，如果你能让你的团队完全参与进来，时间管理软件也可以方便地进行事后分析等（如果每个人都有积极参与的积极性。