From D3 (Directions in Desktop Development), a sister publication
In 1986 Fred Brooks, who headed two huge groups at IBM and wrote the landmark study The Mythical Man-Month, predicted that technology wouldn’t rescue software teams for at least ten years. That decade is now up, and Brooks’ claim – that there would be ‘No Silver Bullet’ – has been vindicated. Nevertheless, the tools available to programming groups have improved, and despite the huge increase in individual programmers’ productivity there remain projects that require a team effort. In this article, we look at past developments in tools for team-based programming, and consider how those tools are adjusting to meet modern demands. Programming imposes quite enough discipline for anyone; developing software in a team requires even more. Yet, there are challenges unique to team development for which project-wide control is essential. Foremost among them is the problem of ‘conflicting edits’. With an uncontrolled team it’s almost inevitable that two programmers will alter copies of the same element of a project then return their results to the source-code pool. If this is allowed to happen, the first set of changes to be returned to the project will be over-written by the second set. The jargon for this is ‘conflicting edits’. The surprising thing, perhaps, is how seldom it occurs; conflicting edits can be avoided without tools. Well-managed software projects are modular, and an axiom of software design is that, if one person can’t wrestle with a module then it should be smaller. Wherever possible, developers must be assigned sole responsibility for well-defined parts of a project. If those parts don’t overlap, and programmers avoid straying into each other’s territory, then conflicting edits need never arise. This sort of gentleprogrammers’ agreement can work well in restricted circumstances. If it is to work, the group must be small. In a team of five, using one-to-one communication to avoid conflicting edits, every member must communicate with the other four and so there are twice as many communications paths as members. That factor grows as the team expands; in large groups the overhead of organizing by direct communication outweighs the advantage of adding more people. A large team can be grouped into small clusters, and the clusters organized in a tree structure to limit the number of people with whom each member must communicate directly. But information still has to pass between clusters, which necessitates communicating indirectly. It’s just too tempting to create ad hoc information paths; when these clash with formal ones, edit conflicts can result. At some point, even for small teams, a tool to avoid conflicting edits becomes attractive. Developing software is creative and expensive; pushing administrative responsibilities onto programmers is wasteful. To avoid conflicting edits, the tool of choice is the Version Control System (VCS). It needn’t be a software tool: once, the VCS was simply a logbook through which elements of a project were signed out of a source-code pool, then signed back in after modification and testing. Such a ‘paper registry’ implements the same ‘mutual exclusion’ theory as its software equivalent – provided programmers use it. Managers despair of those who, rather than waiting to book out a source-module, will copy an already-booked-out version, then attempt to merge the two sets of changes by hand. To the supervisor it’s subversion; to the programmer, it’s progress. The best way to avoid it is with software tools.
Paper replacements
Early software VCSs were simple replacements for their paper predecessors; to be truly useful they had to be more difficult to bypass. Initially, this meant integration with editors and code- storage systems, merging the VCS with a source-code librarian and editor, to prevent programmers from working on anything that hadn’t been signed out correctly. At least, that was the idea. Anyone in a hurry would simply take source-code off backup tapes; for a while, going behind
the VCS’s back became a new form of ‘progress’. Encryption put paid to that adventure, but only by buckling the last strap on a straitjacket. Many of the best editors weren’t integrated with VCSs; some programmers preferred to avoid VCSs if it meant keeping their favorite development tools. What VCSs needed was a public-relations success – features sufficiently attractive to overcome programmer hostility. This came with the recognition that version control is just part of the team-management problem.
By Lloyd Blythen
Through integration into modern, Rapid Application Development (RAD) environments, Intersolv’s desktop version-control package PVCS has gained sufficient popularity to become an accepted part of overall project management. Although a true cradle-to-grave system is some way off, this is the direction in which modern tools are headed. Other vendors – Microsoft in particular – are beginning to compete with PVCS, but with over 200,000 seats the Intersolv product remains the most widespread example of advances in team programming tools. PVCS complies with the open- environment Application Programming Interfaces (APIs) supported by RADs like Borland’s Delphi. Increasingly, high-end versions of such environments are project-driven. Until recently, a typical project comprised a collection of files whose relationships were expressed solely within source-code (such as C++ ‘#include’ statements). Programmers had to ensure that related files could reach one another, using the rather crude mechanism of disk directories. Unix improved on this with ‘make’, which could invoke disparate tools on demand to build a project. It also, provided simple version control by using date-time stamps to determine whether a file had changed since it was last processed.
Content from our partners
Disparate linkage
‘Make’ was developed to tie together command-line tools – like linkers and compilers – that had little common ground. Modern RAD vendors have turned this concept on its head, recognizing that the project is paramount. No longer does launching a RAD offer a source-code file to the user; instead, it offers a project – a collection of files whose dependencies need not be relegated to a source language because they can be expressed hierarchically in a project browser. Removing the tool-centric emphasis from team development and replacing it with a project-centric one has brought additional benefits to the desktop. A compiler deals only with source-code (and, through bolted on contrivances, with resources such as menus and dialogue boxes); a linker processes only object-code. But a project-centered system can also control test-program scripts, OLE controls, database files, even business-modeling tools – in short, it’s the appropriate interface between team members and the tools they use to contribute to it. Opening up RAD tools by adding APIs has brought team development a long way. PVCS has been ported to several environments and even shipped as a third-party add-on with some of them. Once open RADs become widespread developers will be able to plug in their favorite tools, rather than being forced to use them as standalone applications outside the control of the project-management system. What does the future hold for team development tools? For a while, OOP (Object-Oriented Programming) looked like becoming Fred Brooks’ Silver Bullet. But, as Visual Basic has shown, component technologies and binary re-use became popular even with non-OOP languages. Software components – in concert, particularly, with Microsoft’s OLE (Object Linking and Embedding) – certainly improved productivity, but not by an order of magnitude. Now the Silver Bullet is supposed to be Java combined with the Web: serving up software; enabling teams of scattered programmers to build ad hoc development environments; and allowing members to annotate software modules and communicate using audio-visual clips and e-mail. Frankly, the acceptance and bandwidth of the Internet simply aren’t up to this yet and won’t be for a long time. The software innovation o
f immediate benefit to development teams is a small one, starting to appear in VCSs. Until now, to avoid conflicting edits a source-code file was booked out through the VCS, which then locked it on disk to block access by other programmers. But this is very much an implementation-based approach: it says, Source code is stored in files, so to lock a module you should lock a file. With object orientation, this is becoming inappropriate. Instead of viewing a class-definition as a source-code module, it can itself be regarded as a collection of objects: properties (which may include references to nested objects such as icons); and methods. To avoid conflicting edits on, for example, a particular method, locking an entire source file represents an unnecessary level of Fascism. Locking the file certainly avoids conflicts on the method in question, but at the cost of preventing access to all other objects in that file. Increasingly, modern VCSs register the components of a class in a repository rather than the entire class definition. Individual team members can then sign out different components of the same class without the risk of conflicting edits, which provides version control at a much finer resolution than before. The new, object-repository approach is finding favor for two reasons. First, the finer locking resolution offers greater flexibility to teams: a group of programmers can work on the same class definition, provided they don’t work on the same objects within that class. Second, it opens the way for developments in object storage. In future, objects collected into a class might be stored individually in different locations, possibly distributed over the Internet. With repository-based VCSs this would be possible without affecting version control, whereas older systems expect all class elements to reside in a single file. Despite the Internet hype in the air at present, the most important piece of software for development teams will continue to be the VCS. Reducing the tool- driven emphasis on software development and replacing it with a project-centered view has been a big step forward. Opening up the RAD environment with APIs will offer even greater flexibility, and fine-grained version control is removing restrictions without introducing edit conflicts. Productivity among programming teams may not be ten times better than in 1986, but we have every reason to be optimistic.
