Software

This article is more than 1 year old

Practical Development Environments

From soup to nuts

Sun 26 Mar 2006 // 06:02 UTC

Book review Given the foundations of computing in symbolic logic and discrete mathematics, it should be something of a surprise that developers are so prone to religious disputes, schism and sectarianism. It’s not just the big things - Java vs C#, Python vs Ruby - that developers get factional about: it’s everything, from IDEs to operating systems to code indentation (tabs vs spaces), and naming standards.

Practical Development Environments

Mundane considerations of programming language or IDE are pretty much outside the scope of Matthew Doar’s ‘Practical Development Environments’. Rather than NetBeans vs Eclipse vs IntelliJ, the book takes a much broader definition of development environment, and encompasses build management, software configuration management (SCM), unit test environments, documentation, bug tracking and release management.

The first couple of chapters put things in context by discussing the different phases of a typical project, from coding to release, documentation to bug tracking. While development methodologies differ in quite fundamental ways, there’s also a great degree of commonality between them. Where unit testing sits in the life-cycle varies by process, but it’s there in pretty much every process worthy of the name. And as for SCM, it’s pretty much essential on anything but the smallest of projects.

With some context and some definitions in place, the rest of the book looks at each of these major areas, as parts of a development environment, in turn. Starting with a look at the issues involved and the technical requirements that a product should meet, this is followed by a more detailed survey of a range of products. The product survey takes in many of the major open source projects in each given area, along with one or two of the leading commercial applications.

The chapter on SCM, for example, looks at the complex issues involved in managing multiple source files for multiple versions of products to be used by multiple developers. Branching, tagging, merging and the like are a logistical nightmare and even basic functionality, such as concurrent access to source files, varies widely between products. In this case the product survey includes CVS, Subversion, Arch, Perforce, BitKeeper, ClearCase and Visual SourceSafe.

Aside from the technical aspects of a development environment, the book does not neglect some of the other aspects of projects. For example, there is a chapter on project communication that looks at building a project web site that is more than just a ‘nice to have’ having a central repository for looking at build status, error reports, unit test results etc is a good idea.

Additionally there’s a chapter on the politics of ‘toolsmithing’. As with introducing a new development process, building a development environment of the type outlined in this book is a political as well as technical process. All developers have a personal toolbox of utilities that they know how to use, so replacing these personal favourites with project-wide tools can be a tricky process that can easily be derailed. Devoting a chapter to this is a good idea and underlines the fact that the discussion throughout the book is focused on project practicalities rather than on theoretical issues.®