The following is an alphabetical list of various terms relating to agile development that appear elsewhere on this website.
Continuous Integration
Under continuous integration an application under development is completely rebuilt and retested frequently, perhaps as often as after each check-in of modified code. The aim is to ensure that the software is always in a fit state for testing, demo or release purposes (rather than to spend months on this task once "implementation" is complete).
There are a number of open source projects to implement continuous integration, most significant among them being Cruise Control (also ported to .NET), Luntbuild and Apache's Continuum.
The wikipedia entry is here, Martin Fowler's description is here.
Dependency Injection
Dependency injection (DI) is a programming design pattern and architectural model. Dependencies between different subsystems are isolated and typically a framework is used to set up the dependencies between these systems by "injecting" references as required.
This is an important pattern for agile development primarily because it decouples the different subsystems and allows them to be more readily tested, eg using Mock Objects.
There are a number of open source projects to implement dependency injection, most significant among them being Spring (also ported to .NET), PicoContainer (also .Net) and HiveMind.
The wikipedia entry is here, Martin Fowler's original article defining the term is here.
Design Patterns
A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code; rather it is a description or template for how to solve a problem that can be used in many different situations.
Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.
The wikipedia entry is here, a patterns catalog is here.
DRY Principle
The Don't Repeat Yourself (DRY) Principle emphasizes that information (or analysis, or code) should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency.
The wikipedia entry is here, the term was first coined by Dave Thomas and Andy Hunt, see for example here.
Domain Driven Design
The premise of domain-driven design is two-fold:
- For most software projects, the primary focus should be on the domain and domain logic; and
- Complex domain designs should be based on a model.
The definitive word on Domain Driven Design is Eric Evan's book; we use Naked Objects is our primary means for prototyping/implementing domain-driven designs.
The DDD website is here.
Extreme Programming
Extreme Programming (XP) is a software engineering methodology, and one of the most prominent of several agile software development methodologies. Its emphasis is on placing a higher value on adaptability than on predictability, adopting development techniques that allow ongoing change to requirements as a natural, inescapable and desirable aspect of software development projects.
There is some overlap between Scrum and XP, but the former focuses more on management techniques whereas the latter more towards development techniques.
A good portal for all things XP is Ron Jeffries' website.
Scrum
Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, such as Extreme Programming, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.
The key words here are management and emperical. Scrum is about managing the software development process, rather than saying what the activities actually are. It is also empirical in that it accepts that the problem of software development cannot be fully understood or defined, and focuses instead on maximizing the team's ability to respond in an agile manner to emerging challenges.
The wikipedia entry is here. The Scrum website is here.
Test Driven Development
Test-driven development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. This gives rapid feedback, but it also helps in the design of the software. The technique began to receive publicity in the early 2000s as an aspect of Extreme Programming, but more recently is creating more general interest in its own right.
There are a number of open source projects that make it easy to adopt TDD. Most prevalent are the xUnit family of projects to assist in writing and running tests, most significant of these being JUnit (also ported to .NET). Mock object libraries such as JMock (also ported to .Net) and EasyMock.
The wikipedia entry is here. A good portal for TDD is here.
Ubiquitous Language
The term Ubiquitous Language originates with Domain Driven Design, and is central to it. It means a language structured around the domain model and used by all team members (including the business representatives) to connect all the activities of the team with the software.
If the business and technical staff use different terms for the same ideas, then it is almost impossible for the two to communicate effectively. Building a ubiquitous language means committing for all team members to use a common set vocabulary; if a concept is required then isn't in that language, then the concept should be named and the language extended.
This practice works exceptionally well when using Naked Objects, because the only concepts that the technical staff need to deal with are those pertaining to the business.
The DDD website is here. Its definition of ubiquitous language is here.
Waterfall
The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.
There has been substantial criticism of the waterfall model, however. Proponents of agile development approaches in particular have argued it to be a bad idea in practice, because it is impossible to get one phase of a (non-trivial) software product's lifecycle "perfected" before moving on to the next phases and learning from them.
The wikipedia entry is here.