4 ms·

Document-Driven Design (DDD)

1 points by reader_1000 14y ago

dalke 14y ago
Interestingly, this example is one of my counter-arguments for how TDD isn't applicable. You have a function "sort(numbers)". You have a set of pre- and post-conditions; in this case the documentation lists the post-conditions and in TDD it's done through test exemplars. But the author writes "Next, you can write actual code, then tests since you know clearly what you are going to code." This is rather incorrect. You know what your goals are, but not how you want to achieve it. Are you going to implement Shell sort? Quicksort? Timsort? Your tests and your API documentation should not be so dependent on the implementation that you can't replace one with another (so long as certain performance requirements are met). But that means the *DD techniques don't clearly describe 'what you are going to code next.' There are any of a number of algorithms with a similarly simple API but with complex implementations; substring search for one, and one I just did is graph canonicalization. Here, btw, is a 2011 PyCon talk on Documentation Driven Development: http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-documentation-driven-development-4896872 http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-doc...
- reader_1000 14y ago
  I am the author of the post. You are right, even if you know what to code, you don't know how to code it and how part of the code is a more serious and problem specific problem I think. I am not sure that we can come up with a methodology that describes how to part. I think *DD techniques help to write cleaner code. However, I don't think that implementation becomes dependent to tests / documentation when you write them first. As with your example, sorting algorithms have same goal, so their last output will be same except if you change in-place sort to not-in-place sort. Moreover, we want our interfaces stable so that no change will break any other existing code. btw, thanks for link, I didn't know that.

1 points by reader_1000 14y ago

dalke 14y ago

Interestingly, this example is one of my counter-arguments for how TDD isn't applicable. You have a function "sort(numbers)". You have a set of pre- and post-conditions; in this case the documentation lists the post-conditions and in TDD it's done through test exemplars. But the author writes "Next, you can write actual code, then tests since you know clearly what you are going to code." This is rather incorrect. You know what your goals are, but not how you want to achieve it. Are you going to implement Shell sort? Quicksort? Timsort? Your tests and your API documentation should not be so dependent on the implementation that you can't replace one with another (so long as certain performance requirements are met). But that means the *DD techniques don't clearly describe 'what you are going to code next.' There are any of a number of algorithms with a similarly simple API but with complex implementations; substring search for one, and one I just did is graph canonicalization. Here, btw, is a 2011 PyCon talk on Documentation Driven Development: http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-documentation-driven-development-4896872 http://blip.tv/pycon-us-videos-2009-2010-2011/pycon-2011-doc...

reader_1000 14y ago
I am the author of the post. You are right, even if you know what to code, you don't know how to code it and how part of the code is a more serious and problem specific problem I think. I am not sure that we can come up with a methodology that describes how to part. I think *DD techniques help to write cleaner code. However, I don't think that implementation becomes dependent to tests / documentation when you write them first. As with your example, sorting algorithms have same goal, so their last output will be same except if you change in-place sort to not-in-place sort. Moreover, we want our interfaces stable so that no change will break any other existing code. btw, thanks for link, I didn't know that.