Bob on Medical Device Software

First a definition:

driv·en –adjective

1. : having a compulsive or urgent quality
2. : propelled or motivated by something — used in combination <results-driven>

Driven software development methodologies abound:

• Behavior-Driven Development (BDD)
• Design-Driven Development (D3)
• Domain-Driven Design (DDD)
• Feature-Driven Development (FDD)
• Model-Driven Architecture (MDA)
• Process-Driven Development (PDD)
• Test-Driven Development (TDD)

Many of these are encompassed by the iterative Agile software development methodologies. Collectively they are sometimes referred to as the XDD acronyms. As you might expect, these along with all of the other competing, contrasting, and overlapping development philosophies can cause a software developer much consternation. Confessions of a Software Developer* is a good example of the overload that can occur.

My reason for bringing up driven methodologies is not to complain about being overwhelmed by them (which, like most others, I am). It's simply to point out the contradiction of X-Driven with the Merriam-Webster definition. I think this will help us better understand what should really be driving us.

Look closely at definition #2. Propelled or motivated by something ... results-driven. What is that something? Ah ha!

The fundamental motivation for all of these development approaches is to:

Improve productivity and quality.

This is the result, the goal. Behavior, Model, Test, etc. are all just the means by which we are trying to achieve this desired result. It's the result that we're driven towards, not the methods and techniques we use to get there.

So, in order to make this distinction clear and to eliminate confusion in the future, I propose that all these methodologies be renamed from Driven to Guided. Think of them like you would a GPS system in your car, except these will allow you to find software Nirvana. TDD is now TGD, and the whole lot is known as XGD.

The point here is that you should not let any particular development philosophy blind you to what the real purpose of using it is in the first place. Being guided by a methodology helps me remember that better than when I'm driven by it. Also, the whole concept of being driven seems exclusionary to me. You shouldn't hesitate use the pieces and parts of any combination of these techniques that best suites your needs.

This entry was posted on Sunday, February 17th, 2008 at 4:54 pm and is filed under Agile, Programming, Software Quality. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.