Release-driven Development

The following development pattern is presented as an Anti-Pattern to Test-driven Development. Any development team finding their selves following RDD will be quick to point out that this is not how things should be done, and are working towards a more sustainable model. 

Release-driven Development (RDD) is a software development technique that relies on pushing out software releases as often as possible to satisfy stake holders.

RDD focuses on establishing a release date with one or more critical patches for a particular user, then attempts to stuff as many other updates and patches as possible into that timeline. The particular fit of individual changes do not matter as much as the quantity.

Requirements:

Release-driven Development requires developers to avoid creating system tests in an attempt to fit even more changes to the code base. Developers often create unit tests to help maintain correct behavior as systems change, and to assist in any refactor tasks as their code base evolves. RDD tries to get by with a minimal of test updates, essentially just doing enough to make builds succeed.

Benefits:

• Releases come out on time, pleasing stake holders.
• Active release cycle promotes appearance of steady advancement of project.

Vulnerabilities:

• Unit and System test suites become increasingly irrelevant as they are tweaked just enough to allow builds to pass (see technical debt).
• Few important issues are resolved per a release.
• Minor or Trivial issues get resolved faster due to it being perceived as easier to tackle low-lying fruit in tight time line situations.

Notes:

Seen in organizations of all sizes, does not appear to be technology stack dependent.