Whatever else is true in development, the importance of "version control" can't be overestimated. You simply don't want the bugs you've fixed coming back simply because someone implements a new version that isn't aware of the changes you've made.

The trouble is, "version control" tends to be imposed on free-spirited developers by men in suits who can see why it is necessary but have no idea how much of a PITA using some of the products can be. I remember someone once telling me how much he hated his unproductive role as "fixer of the broken database" for one product. An expensive team member occupied just about full-time with fixing corruptions introduced by a product which couldn't scale up to match the team's needs!

Which rather explains the popularity of "viral marketed" version control, brought in by developers at the grass roots who fully realise that it's needed but would rather choose something that works. And, at least with Open Source, for instance, you can see how it works—and "painful" things you do to yourself are always less painful.

Nevertheless, while Subversion, say, is both popular and effective, there is more to “Software Configuration Management” (SCM) than mere “Version Control”. Ideally, it should be part of a “Configuration Management System” and link back to the business changes which drive the development of new software versions— although perhaps that's for another blog.

And, quite often, scalability in the widest sense is still the issue. Lots of people, in different locations, often working for different companies, and working on large software projects makes for a large, complex configuration problem—and different approaches to solving it are possible.

So, different products meet the needs of different development cultures—and neither Subversion nor Git, both excellent in their way, have 100% market share, despite the amount of media attention they excite...

Perforce is one of their competitors that still has a place in serious large-scale software development—for example, I believe that Microsoft uses a "forked" version of Perforce it acquired years ago (and has since developed) called SourceDepot, internally. This isn't part of the publicly available Team Foundation Server, which is also used widely within Microsoft (and, allegedly, everyone there is going to migrate to TFS eventually); but SourceDepot is still used for Office and Windows version control, as Richard Erwin admitted at the CMSG Agile SCM event last year; see Robert Cowham's blog. Google also uses Perforce for its very large development environment, (see the paper here] as does Adobe (see this paper). And Cisco uses Perforce too, as do SAP and a whole raft of games vendors (see here). These are companies that can use any tool they want and Perforce is still fast SCM and very developer friendly.

Which gives Perforce a problem. While some other vendors can add features ad lib, Perforce's "USP" is its speed and focus on developers' real needs. Which means that "bloatware" isn't an option, if it wants to keep its loyal customers. On the other hand, people expect new releases and constant improvement—although (as in the Google paper already cited) scalability is a continuing issue for all development tools.

One advantage that Perforce has (which may have consequences too) is Chris Seiwald's charismatic leadership and focus on Perforce's original vision. Which begs the question, I suppose, "what happens when he retires". Well, I don't feel like speculating here, but it's a question his customers need to be aware of.

However, one way Perforce is evolving is to cater for a wider class of "developer"—it's now attracting people in the games development community, and managing pictorial development assets beyond sourcecode. It appears to be doing this while retaining focus for its original developer customers—although that might be a communication as much as a technical issue. Older customers have to feel that they are still loved!

Nevertheless, with the latest Perforce 2008.2, Perforce seems to have found several enhancement possibilities within its traditional developer scope. The first seems to be improved (graphical) visualisation of the impacts of branch/merge: "the new merge preview displays branches side-by-side with colour-coding for individual files". I believe that such options are far from merely cosmetic—they are almost essential if average developers are to cope with complex environments effectively, under constant demand to "do more with less"

Of course, sometimes visualisation tells you that you don't really want to go somewhere and Perforce now has useful roll-back facilities, with full history logging (both for the work rolled back and the correction), so that the issues and resolution can be reviewed by al the stakeholders.

A second issue impacting developers today is a demand for improved governance of development by the business. Perforce is going some way to accommodate this with dashboards for system administrators (available in the P4V visual client), although these seem very technology-oriented (disk space and performance metrics)—presumably this targets practical scalability, which (for companies like Google) is a business issue as well as a technology one. Seiwald would probably see business-level metrics for the configuration process implemented by the business' CMS (Configuration Management System) as outside of Perforce's very focussed scope—but this would be useful functionality for third parties to provide (I think Perforce is adequately "open" for extension).

And this latest Perforce release has added automatic server discovery from a scroll-down menu of available servers, which sounds useful in complex environments.

All in all then, it seems that Perforce is finding new things to do, driven by changes in the development environment, without losing its focus and speed. But the proof of the pudding is in the eating, as always, and Perforce 2008.2 is available now for free evaluation (including free technical support) on the Perforce website.