Section 2.9. Recommended Tools | Practical Development Environments

2.9. Recommended Tools

This section contains my personal recommendations for tools for development environments. The recommendations are intended for projects with less than 1 million lines of source code and under 200 people involved in developing, testing, documenting, and releasing the product. The annual budget for tools probably ranges from zero to $100,000. These choices are purely personal ones made from the tools available in 2005, with no undue influences from any individual companies or projects.

If you use a tool that you feel is much better than one of the tools I've recommended, feel free to send me email about it via bookquestions@oreilly.com. My own contact details are available at http://www.pobox.com/~doar.

IDE recommendations are also welcome, but rants about editors (the programs, not the people) are generally unproductiveuse one that does the job for you, and learn it well.

If these recommendations are enough for you to make progress with a development environment, that's great! Reading the sections about each tool later in the book is still a good idea to get some more background, especially Section 3.7.

However, a development environment is more than just its tools. The discussions of the best practices and annoyances of each area in the chapters that follow will help you use each of these tools in a more productive manner.

2.9.1. Modern Environments

This list of tools is for environments that can afford the effort of using tools that are still themselves being developed. Some reading of mailing lists and weblogs, and possibly some local development of the tools by a toolsmith, may be necessary.

SCM tool: Subversion (Section 4.6.2) with FishEye (http://www.cenqua.com/fisheye)
Build tool: Ant (Section 5.5.4) for projects using Java©; SCons (Section 5.5.6) for most projects and other languages
Test environment: xUnit (Section 6.4.2)
Bug tracker: JIRA (Section 7.2.6)
Documentation: Anything that uses an XML source file format with an open DTD or schema; examples include OpenOffice and DocBook (Section 8.4.3)

2.9.2. Classic Environments

This list of tools is for environments that want to use tools that have been stable for a number of releases and have an extensive support network. These are the tools that you can buy more than one book about.

SCM tool: CVS (Section 4.6.1) with FishEye (http://www.cenqua.com); alternatively, Perforce (Section 4.6.4)
Build tool: Ant (Section 5.5.4) for projects using Java; otherwise, make (Section 5.5.2)
Test environment: xUnit (Section 6.4.2)
Bug tracker: FogBugz (Section 7.2.5), but only if the preconfigured settings work for you; otherwise, TestTrack (Section 7.2.7)
Documentation: FrameMaker (Section 8.4.2)

2.9.3. Future Environments

This is a list of how I foresee development environment tools changing in the next five years. Most of these tools don't exist yet, though the foundations for them certainly do. An important question for future development environments will be how well each of the tools is integrated with the other toolsSCM with bug tracking is one exampleand how much of the process of using them can be automated.

SCM tool: BitKeeper (Section 4.6.5) or Arch (Section 4.6.3), but with better integration with bug tracking systems and a clearer view of recent changes.
Build tool: SCons (Section 5.5.6), with mappings from other languages so that you can write Perl or Java build files as well as Python build files. Support for parallel builds on multiple machines as well.
Test environment: More extensions to the xUnit architecture (Section 6.4.2) to support system tests and historical reports of test results.
Bug tracker: A bug tracking system based on an SCM tool, so that every single change to the whole system is recorded. Better built-in support for a bug that appears in multiple releases of a product is also long overdue. Better integration with build tools, so that it's easier to know which bugs were fixed in which releases. Support for changing bugs while disconnected from a network could also be useful.
Documentation: I would hope that a real typesetting tool such as TEX and all the concepts of literate programming will come back into style one day. Until then, anything that uses an XML source file format with an open DTD or schema.
Release: Better automatic deployment of software products, along with any other pieces of required software. Doing this both atomically and efficiently. Better integration of installation tools with build processes.

As an imaginative finale, with the increased importance of licensing for software, one useful option for a compiler might be the ability to understand various common licenses in source files. Functions from each source code file could then be identified by their license type, and only fully license-compatible libraries and executables would be created. In fact, there are already companies such as Black Duck Software (http://blackducksoftware.com) and Palamida (http://palamida.com) that provide tools to enforce what is referred to as "software compliance management."