Software development is currently being "driven". This article finds existing X Driven Development approaches wanting because they focus on too narrow an aspect of development and, primarily, because they are grounded in the wrong philosophy of what exactly software development "is". An alternative ( theorY Driven Development - YDD), addressing the "essential difficulty" of development is proposed. How YDD represents an evolutionary step for Agile is argued.
A Plethora of D's
At minimum, software developers are confronted with TDD, DDD, MDD, RDD, LDD, FDD, PDD, and SDD. The middle D in all acronyms represents the word, "driven." The final D might be Development or Design, but both words tend to be used interchangeably. The initial letter stands for Test, Domain, Model, Responsibility, Lean, Feature, Pattern, and Service, respectively.
According to Bob Martin, Responsibility Driven Design is the grandmother of DD as it appeared as the title of a book–by Rebecca Wirfs-Brock - in the 1990's.
Each of the DD's promotes one aspect of development to a position of privilege. It becomes THE thing that must be right if you are to have any hope of delivering software.
- If you fail to understand the domain, your software will always be an abrasive intrusion.
- If you modularize your software on any basis other than a "service" you will miss out on reuse and cool Web technologies.
- If you don't get the distribution of responsibilities across a set of objects correct you will fail to realize the benefits of OO and create overly coupled and brittle software.
- If development is not predicated on automated testing you will be forever mired in a swamp of un-fixable code.
Overstatement? Sure! But, each example does contain the essence of the claim made by each approach.
The DD's do not make the claim of exclusivity: only privilege. They do claim to be able to work together.
There is certainly value in adopting any or all of the DD's (except perhaps Model Driven, the latest incarnation of automatic programming) - each does address a pragmatic issue that makes software development difficult. Each offers a starting point and a perspective that quickly leads to improved software development. Agile development is as powerful as it is, in part, because of ‘D' adoptions.
Unfortunately, none of the ‘D's directly confronts the Essential Difficulty of software as described by Fred Brooks in the well known paper, "No Silver Bullet."
Normal 0 false false false MicrosoftInternetExplorer4
The essence of a software entity is a construct of interlocking concepts ...
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. [Brooks 1986]
If agility is to realize its full potential it must incorporate practices and principles that facilitate the development, refinement, and sharing of conceptual constructs.
Fortunately, agility already incorporates such principles and practices and is primarily in need of a contextualizing framework to fully understand and exploit them.
YDD is intended to provide that kind of framework, but it is first necessary to explore a bit what is meant by "conceptual construct" and "theory."
Conceptual Construct = Theory
A software entity is a complicated thing. It is embedded in, and must satisfy the demands of, a complicated deterministic system (the hardware) and a complex system consisting of cultures, applications, users, laws, environments, and change. According to Brooks, " Software entities are more complex for their size than perhaps any other human construct. "
To have a conceptual construct of the software you are to build means having a mental "model" of all the interlocking and interacting parts - both the parts in the machine and those in the world-at-large.
The idea of a mental model is problematic. As Brooks notes: " Software is invisible and unvisualizable ." Moreover,
"As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. ... The graphs are usually not even planar, much less hierarchical ..."
Even a deep understanding of mathematics and physics will not help.
The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence. For three centuries, mathematics and the physical sciences made great strides by constructing simplified