Tools for Team Development - Why Vendors are Finally Getting it Right

TOOLS FOR TEAM DEVELOPMENT:
WHY VENDORS ARE FINALLY GETTING IT
RIGHT

DAVID CHAPPELL
DECEMBER 2008


SPONSORED BY MICROSOFT CORPORATION








COPYRIGHT © 2008 CHAPPELL & ASSOCIATES Most software development is done by teams of people. Yet even though tools to support team-based development have been available for some time, they weren't always as useful as they might have been. Today, the vendors who create those tools have reached a consensus on what the real problem is, and they're providing tools to solve it. The result is team development tools that focus on the right thing: optimizing the end-to-end development process.
THE ORIGINAL PROBLEM: COMBINING TOOLS
To understand what today's consensus is and why it's important, it's useful to look first at the history of development tools. Figure 1 illustrates how the tools developers use have evolved over the last few decades.

Figure 1: What began as separate tools have evolved into unified team development tools.
In the 1970s, all of the functions performed in the software development process were supported by different tools. Developers created code using an editor, then explicitly invoked a separate compiler when needed. Similarly, the tools used to build complete executables, test code, and manage versions of that code were all distinct from one another.
Over time, these separate tools for software development have been combined. In the early 1980s, editors and compilers were united to form integrated development environments (IDEs). Developers loved IDEs-yoking these previously separate tools together meant, for example, that errors could be fixed immediately right in the source Over time, what were code-and so IDEs caught on quickly. Combining these two tools made once separate tools for sense, because it let developers be significantly more productive.
software development As build tools, test tools, and source code control tools became more widely used, it also made sense to combine them with one another have been combined. and with IDEs. Just as integrating compilers and editors allowed things that weren't possible when the two were separate, grouping all of these tools together was also a step forward. The result was team development tools, an advance that began appearing in the 1990s.
2 Unlike IDEs, which caught on quickly, organizations were slower to embrace team development tools. This slowness was partly because this kind of unified tool is harder to adopt than an IDE. Moving from a separate editor and compiler to a unified IDE requires only individual developers to change-it's easy. Moving from separate tools for writing and compiling code, doing builds, testing, and source code control is significantly harder. More people have to change-not just developers-and more important, the development process itself must change.
Making this kind of process change can be challenging, creating various kinds of resistance. For example, one of the most appealing benefits of team development tools is that they can automatically track information about the development process, then generate reports on a project's progress. While this transparency is a great boon for the people who manage the project, it also means that people on the dev team have nowhere to hide. If a developer hasn't checked in any new code in the last week, this problem will show up quickly.
There's also another important reason why organizations have been slow to adopt team development tools: The tools weren't initially as valuable as they might have been. In fact, it's fair to say that, as in most new areas, the real problem wasn't fully understood at the beginning. Today, however, that's no longer true: The challenge has become clear.
THE REAL PROBLEM: OPTIMIZING END-TO-END FLOW
When vendors (and open source projects) first created team development tools, they commonly built or acquired the best tool they could for each area: development, testing, source code control, and so on. This kind of point optimization led to some excellent tools, but it didn't solve the complete problem. The goal in team-based software development isn't optimizing separate parts of the process-it's optimizing the process as a whole.
To see wh... [download for more]