(reader beware: this post comes from the author's recent findings on numerous posts on Agile Methods, TDD, design, and other buzzwords that he pays attention to. Incoherient ramblings may be present. Parental discretion strongly advised...)Earlier this week, I had a mild epiphany while reading
Jeremy's post on the
NSpec project which led to catch-/brush-up on reading the
enlightening wisdom of
M. Fowler. Specifically, the update Fowler made to his post on
Specification By Example and
bantering of "Uncle" Bob Martin and others in the Agile community have led me to believe that, aside from the seemingly constant, recurring debates on SProc's VS. "ad hoc/parameterized" SQL, VB.NET vs. C# vs. Java (and surely to appear shortly) vs. Ruby, Agile methods and their practices are going to fuel the feuds of the future. And I really think it has less to do about the practices and methods, but rather language; that is, the vernacular of the UBIQUITOUS LANGUAGE or Domain-Specific Language (or whatever you wish to name it) that most emerge from our projects as professional developers.
OK, so after reading that, I, too, shook my head and said "a wha?!?"...
NSpec: even by looking at the very early and contrived examples on the project home page, you can see that there is most certainly a language to the object model that composes the NSpec utility (snipped from the project's home page):
namespace Example
{
[Context]
public class Example
{
[Specification]
public void BooleanSpecificationExample()
{
// ...Some set up code...
Specify.That( someObj.SomeMethod() ).ShouldBeFalse();
// Or...
Specify.That( someObj.SomeOtherMethod() ).ShouldBeTrue();
}
}
}
OK...while someObj and Some[Other]Method my not be very informative, the Specify class and its methods clearly indicate the intentions of the
developer programmer more so than an Assert.IsFalse() would and has greater meaning especially when you consider using NSpec for testing that your implementation for, say, an inventory system, is correct.
Rhino Mocks has a language around creating, preparing, and verifying mock objects in unit tests as well, which I find makes my code much more understandable - thus, increasing maintainability. However, becoming comfortable with the language of these systems does, unfortunately, seem to take a non-trivial amount of time, IMO...
So how does all this language mumbo-jumbo related to the discussions of "Uncle Bob" Martin and M. Fowler? I believe that the language that the Agile fathers use to communicate the ideas and principles of the discipline are to simple. In fact, "Uncle Bob" said this himself - given the time they have, Bowling, Stacks, and Lists are as complicated they can get for an hour or so. It isn't clear or easy for to formulate a [meaningful] language around a bowling score keeper or a stack implementation. Who decided that Push() and Pop() were better names than Add() and Remove() anyway? But I digress...
I think that people who have a mind-set similar to Cedric's would greatly benefit from more concrete examples that show how when (as an example) an order is placed on Amazon.com, the inventory is updated, customer order history reflects the new order, and the shipping carrier is notified that an item needs to be picked up, or similar example. More importantly, to show how tests can be the specification for the software, show how the language of the system evolves, expressing the ideas, goals, and intentions of what the application does rather than just a series of "IF...THEN...ELSE...OpenReader()...CloseConnection()" statements that when any code monkey sits down at the keyboard doesn't know any more about the application than the person(s) who originally wrote the feature.
To me, I think this may need to become more of the language of the Agile mentors and "prophets" than "just wire-up your xUnit framework and 'RED-GREEN-REFACTOR' your way to the application of your customer's dreams!" to illustrate the development principles that make one an Agile developer...
