The use of sophisticated (and often expensive) software development tools is well established in traditional software development projects. However,more and more software development teams are embracing or, at least, experimenting with agile development techniques such as eXtreme Programming [XP], Scrum [Scrum] and Feature-Driven Development [FDD].
Although the details of these agile approaches differ from each other significantly, the driving principles behind the development of each one share a number of core values. The agile manifesto published in 2000 by a group of thought leaders in agile development techniques sought to capture these core values. The manifesto starts by stating that the authors value:
“Individuals and interactions over processes and tools” [agile manifesto]
Some people have interpreted this as saying that processes and tools are unimportant in agile projects. However, this is not the intent of the statement as the final sentence in the manifesto explains,
“…while there is value in the items on the right, we value the items on the left more.” [agile manifesto]
As anyone who has participated in a well run agile software development project will tell you, tools are critical to the success of the project, just not as critical as human beings working well together.
Software Configuration Management
Obviously developers need the kinds of editors, compilers, debugging, and unit testing tools found in modern integrated development environments. However, in addition, it would be almost impossible to run an agile software development project without some form of version control system (vcs) or software configuration management (scm) system to manage the team’s source code files.
Without a scm system, key agile practices such as continuous integration and collaborative code ownership become very difficult. Continuous integration is the practice of building the software and running automated tests whenever a modification to software’s source code is completed. Continuous integration finds any fundamental integration problems as early in the project as possible. In most cases, checking a file into the scm system is the trigger for executing the next build. Collaborative code ownership is the practice of allowing any member of the team to modify any source code file whenever they need to. This avoids situations where one developer is waiting on another to complete a piece of work. Without a scm system to provide versioning, comparison and merge functions, this practice would be impractical.
Software Design ToolsSoftware design tools are a little more contentious. The expensive CASE systems of the 1980's that failed to deliver on their promise, the clumsy, stand-alone, throw-it-over-the-wall, object-modeling tools of the early and mid-1990's, and to date, the under performance of the Model Driven Architecture (MDA) vision, has caused many to reject the use of software design tools altogether.
One design tool I have become addicted to since first encountering it over a decade ago is Borland's Together. Borland Together was originally constructed to address the problem of design models and documents becoming out of date. This tended to happen as developers wrote the source code for the system and absorbed important change requests as they did so. Often there is just not time to go back and update the design models and documents and they become stale, out of date and, finally, worse than useless.
Together's LiveSource™ approach of using source code as the model storage mechanism means any change made by a developer to the source code is also reflected in the design models. The design and code are always synchronised.
More and more, Together is built on the open-source modelling capabilities provided by the Eclipse Modeling Project. Borland contributes to this project and Together adds commerical-level features and ease-of-use to this sopisticated modelling platform.