08.29.10
Posted in Agile, BDD, Iterative Development, Pair Programming, Software Development, TDD, Teams, Uncategorized at 7:41 pm by Pablosan
Recently I was honored to have the opportunity to work toward being approved to teach Ron Jeffries’ and Chet Hendrickson’s Agile Developer Skills course. I had my first opportunity to co-teach the class last week. It was a great class and I very much enjoyed working along side Chet and Cheezy, two software craftsmen I respect highly.
If you follow the links above, you’ll notice a theme and, though it’s not explicit in the class’ title, Extreme Programming is a significant influencing factor in the course content. Like most software developers, XP has had a major positive impact on my pursuit of the craft, and it’s great to see the practices hold up so well over time.
The ADS course utilizes some lecture, but it is primarily a hands-on workshop giving participants the opportunity to experience developing high-quality, working software using Agile principles and practices. This is the second time I have experienced the class (the first time was as a participant back in May) and it has remained an intense, thoroughly enjoyable way to either learn the practices for the first time or to delve deeper into Agile. I find it hard to believe that anyone could leave the course without learning a great deal. It is both challenging and insightful.
I think my favorite part of the class are the questions and how they help shape and guide the content. That feedback is crucial to the success of the course (maybe any course) and, as an instructor, I find the questions leave me thinking about these principles long after the class is over.
Next time, I’ll share a couple of the questions and some of those thoughts. For now, though, I encourage you to take a look at Agile Skills Network and consider taking the course. Regardless of where you are in your software craftsman journey, the ADS course will encourage you to push further down the path!
Permalink
04.04.08
Posted in Agile, BDD, TDD at 1:48 pm by Pablosan
Much to my surprise, blogging is hard. It’s not the research and it’s not the writing: my problem is consistency. You see, I’d rather not waste your time nor mine if I really don’t have anything interesting to say. And then, sometimes, I simply find it hard to find a good anchor point out of the research that I am performing.
I thought I had a great anchor point in BDD. I really like the idea of the Test-First approach to software development being focused on behavior. When I teach TDD in the classroom, it is the concept that I repeat the most. Focus on behavior. It’s the right thing to do. And I like the fact that BDD makes the focus on behavior patently obvious. Yet, once I started digging into BDD it felt… awkward. At first, I assumed this was simply due to my lack of experience in this new approach, but the feeling didn’t go away. I couldn’t put my finger on what was wrong until I ran across Dave Thomas’ blog post on BDD.
When I evaluate tools or languages I look, primarily, for two qualities:
- Conciseness
- Elegance
I realize our discipline does not lend itself to either, and I think that is why I place so much importance on them. Coming up with a convoluted, high-ceremony, complex solution is easy. Because they don’t come naturally, coming up with a concise, elegant solution is hard work. And therein lies the problem with BDD: it is neither concise nor elegant – quite the opposite. The emphasis on attempting to provide a “plain english” syntax makes the tool verbose and unwieldy.
Does this mean we should stop exploring BDD? I don’t think so. It simply means the approach still needs a lot of work and some time to grow up; evolve. So, for now, I’m happy to stick with xUnit… with an eye toward BDD’s progression. It’s a bit of an anti-climax, I know, but sometimes life is like that.
Permalink
02.27.08
Posted in BDD, TDD at 10:38 pm by Pablosan
Lately I’ve been squeezing in work on TDD examples, learning Erlang, brushing up on Ruby and researching BDD whenever I can find a few minutes in my schedule. It just so happened that today I had a sizable block of time to focus on one thing. That one thing ended up being continued exploration into Dave Thomas’ Kata 2 (implementing a binary search) using TDD. I have tried this previously in both Java and C#, but was not satisfied with the results. A discussion and (unfortunately) interrupted pairing session with a friend of mine provided a fresh perspective.
Implementing a binary search is really a great TDD learning exercise. The hardest part for me was figuring out how to describe the desired behavior in a test – a description that would force the use of a better algorithm than just implementing a brute force, linear approach. Then it dawned on me: the key to this requirement is how many iterations it takes to find the right value and, for a binary search, that is a quantifiable number: 1 + log2(N), where N is the number of elements in the collection. If it is quantifiable, we can write an assertion. If it can be asserted, we can use TDD to drive out the implementation! I have chronicled my latest TDD approach on CodeNotes. Fair warning: it’s detailed and, therefore, long… but I’m pretty happy with it.
Who knows… after this great success, maybe I’ll go over here and kick those embers back into flame! Sudoku anyone? <evil grin>
Oh, and don’t worry: I haven’t forgotten about the BDD example in Ruby… it’s coming soon!
Permalink
02.08.08
Posted in BDD, TDD at 3:08 pm by Pablosan
In spite of all that TDD provides, there is one glaring omission: TDD is not particularly interested in business value. I’m sure that strong proponents of TDD would argue that TDD is valuable; and it is – as an engineering practice. I’m sure that those same proponents would say that TDD’s implicit improvement in design and code quality provides business value. However, it is entirely possible to follow the rules of TDD to the letter, providing beautifully designed, air-tight ,validated code, and yet provide minimal or no value to customers/stakeholders.
One might argue that, because TDD is an engineering practice it should not be required to explicitly drive business value; and that argument is not without merit. But wouldn’t it be easier to justify the use of a tool that did?! More importantly, having a tool that makes this value an assertion, rather than a happy side effect puts the emphasis where it belongs.
In my previous post you may have picked up on a theme: behavior. TDD should be about designing, describing, discovering and validating behavior. As developers practicing TDD, we are following the discipline of writing our specification iteratively… very iteratively. Focusing on behavior is what keeps us from writing an elegant system that does exactly the wrong thing. Enter Behavior-Driven Development.
BDD is not particularly new: Dave Astels wrote his excellent white paper (PDF) introducing BDD back in July of 2005, but it seems to be steadily gaining wider acceptance. When I first heard of it, only a few languages had implementations. As of today, you can find a “Spec” implementation for pretty much any major language.
The first BDD implementation was RSpec for Ruby. Excellent! Combining my new-found interest in BDD with one of my favorite programming languages should result in some interesting code examples. I’ll do my best… in my next installment!
Permalink
