At last, more on the XP 2006 conference
XP 2006 Conference, Day 2 highlights
During the second day in the conference I attended the scientific paper session in the morning. Of the three papers presented the most interesting was the one on TDD and the effects it has on how we develop code.
The gist of the paper was that in order to be able to do TDD you will develop code with higher assignment controllability than if you don't use TDD.
Assignment controllability was defined as the control over all the elements in any assignment statement within a method.
Let's take an example: in the statement A = B + C, the assignment is controllable if the method that does the assignment is passed all the elements in the assignment.
public int addition( int B, int C)
{
return B + C;
}
An assignment is less controllable if some of the elements in the assignment are not passed in:
public int addToC( int B )
{
C = new Integer(5);
return B + C;
}
The author of the paper went on to detail a process to measure the controllability in any method.
The implications of the theory that the author presented are interesting:
- by having assignments in methods that cannot be controlled you cannot reliably use TDD for those methods.
- Assignemnt controlability can be used to see if a project is TDD or not (the threshold is not clear, but you can see a "trend")
- You can use the Assignment Controllability(AC) metric in legacy code to see where it would be easier/harder to insert the tests first. Start testing where AC is close or equal to Zero if you want to tackle the more problematic areas of the code first, and start where AC is close to one if you want to add tests quickly.
XP 2006 Conference, Day 3 highlights
On the third and last day of the conference Kent Beck had the Keynote and he used it to describe what he called "responsible development".
He defined the current state of Agile/XP as:
1- people believe that Agile/XP works;
2- people understand and want to profit from the benefits it offers;
3- people undestand Agile/XP as being practice focused, not value focused.
He went on to explain that Agil/XP should be value focused and called that new approach "Responsible Development", based on the following pillars:
1- accountability;
2- responsibility;
3- integrity;
4- avoiding blame.
Kent described what each of these values means for him and why he thinks people in the software industry should follow these values. He compared each of the concepts with past experiences and tried to justify the business sense that they make for software companies.
One interesting proposal from him was that software companies start reporting on the number of bugs/problems they have open for each of the products they sell. This, he stated, would contribute to transparency in the business through a wide audience form of accountability, as in accountability to all users of our software and shareholders of our companies.
Very interesting outline, I have also given these ideas some thought and went to the point of in a recent project ask the team to report the number of open bugs to all the stakeholders during the iteration reviews. This, in my opinion, brings transparency to the software development process and makes people think hard about the quality they are providing along with the functionality.
All in all a very interesting talk. We as an industry need to pay attention to these concepts, they make very much business sense!
RSS link
2 Comments:
"By having assignments in methods that cannot be controlled you cannot reliably use TDD for those methods."
Sigh. TDD has nothing to do with assignments. It's all about behavior and whether or not that behavior is represented by a single method or a collection of methods, a single object or a collection of objects, is irrelevant. Similarly, if your tests are regularly verifying assignments, I'd dare to say you haven't yet found out what TDD is.
By Anonymous, at July 14, 2006 3:38 PM
The paper I discuss in my post does not focus on Assignment Controlability as the only thing that TDD is about.
I for one am a proponent for a name change from Test-driven development to Behavior-driven development.
I agree that TDD is not about assignments, it is about behavior.
That said however, and that's the interesting point from the paper, if you cannot control the assignments in the unit (method, class, whatever) that you are developing the use of TDD (verification of behavior) will by definition depend on variables that you do not control in your tests, and if that is so there's no way to predict whether you are testing the right behavior when you execute your tests or just some behavior that is not necessarily going to be reproduced when you execute the whole system.
By Unknown, at July 14, 2006 4:37 PM
Post a Comment
<< Home