Alt.Net Mailing List - The Hidden Benefits

Since the Alt.Net mailing list saw it's first post on October 8, 2007, the list has seen an average of 87 posts per day. The content is wonderful (now that we aren't arguing about the name so much).
This high volume has also done wonders for my ability to scan and speed read. This is a skill that I had during my schooling but seemed to have lost. Now that I have been following this mailing list, I have seen much more zero-bounce in my blog reader - even though I have more feeds coming in.

Now, I can finally keep up with the volume of content coming from Ayende's blog.

altnetconf - Cool Tools Don't Make Cool Software

I'm pretty sure that Jimmy Hendrix could make awesome music with a cheap guitar. Likewise, I could drop $5000 on a beautiful vintage guitar and I still won't be going on tour with anyone. The artist makes the tool work. While good tools make the artist's life a bit easier, they don't make the artist.

Likewise, it is perfectly possible to write clear, maintainable software without the use of things like inversion-of-control containers and mock frameworks. This weekend at the Alt.Net conference, I spoke with some very smart developers that don't use these tools that I take for granted. Tools that I even view as a necessary item. One developer that I spoke with stated that he has yet to find a need to use a mocking framework. Instead, he prefers the Testable Object pattern. I was completely taken aback until I grokked what his explanation. While I'm not going to drop my use of easymock, I see that this is certainly a valid way to do things.

I had the opportunity to speak with another developer this weekend - a brilliant developer and the second person ever added to my feed list. When the table at lunch started talking about IoC containers, he said that he's never seen the need for one. I found this to be very surprising. Once a couple of us explained why we like and use tools like StructureMap and Guice, he quickly grokked what was going on, and I think he could see why some find them to be useful tools to have. However, it also became clear that he had found other ways around the pain of supplying dependencies when using Dependency Injection.

All of this is to say that I was reminded that I don't have to pull in every tool under the sun. It's good to keep my head up and take a look at what others are doing to alleviate problems. However, there are also other ways around problems that may not involve pulling in yet one more tool.

It's not the tools that make the software good. It's the developers that apply sound judgement and experience - regardless of what tools they have.

altnetconf - Random Thoughts on Fishbowl

Some of the sessions are using the fishbowl format. This is a really fun format that lets just about anyone that wants it the opportunity to contribute content to the conversation. However, this did not work very well during the BDD Discussion most likely because code samples were being periodically presented on the projector. This was proof positive that if your turn on a video source, the entire audience will focus on it. In this case, chairs were setup for the fishbowl, but the fishbowl rules were not followed by the audience. Because the group was focused on the screen rather than the chairs and the people in them, the conversation was not controlled.

Either present video or do the fishbowl, but it seems you cannot do both at the same time

altnetconf - Behavior Driven Design

This post is separated into summary and thoughts.

Summary

This thing called "Behavior Driven Design" (BDD) doesn't seem to have a formalized definition. Not everyone in attendance could agree on what "it" is. However, the most clear definition presented involves several components. Scott Bellware asserted that BDD = UserStories + TDD + UbiquitousLanguage + Solubility.

Some constraints on the above components should be explained. User stories must be well-formed. So, the idea is that during a conversation that the business analyst and the developer would work together to produce a story of the form "As a... I want to... So that..." The assumption is made that the TDD being used is driving design at a granular level with only one assertion per test. To extend Scott's definition of Solubility linked to above, another term "grokability" was proposed by Scott Hanselman.

The Behavior Driven Design (BDD) session began with many questions, asked many more, and perhaps answered a few things. Bellware started by saying that BDD is not about testing. He later stated that BDD provides better tests. So, to summarize, BDD is not about testing... except when it is. So, that make that about as clear as mud.

Much of the discussion centered on improving the conversation. More specifically, the conversation between the developer and the business analyst was discussed.

One criticism presented is that BDD is using programming languages to discuss things with the business analyst. The concern was that we would be asking business analysts to write specifications including the markup. This bred a great deal of consternation.

This critique was perhaps diffused later when the suggestion was made that the business analyst would sit down with the programmer, and the two would discuss the user story and the specifications. During that discussion, the developer would transcribe the conversation into the story markup used by the spec tool (RSpec, NBehave...). Another possibility presented was that the conversation could be initially captured onto a story card and then transcribed to the tool by the developer at a later time.

There was the assertion made that BDD provides or formalizes context for conversations with the business analyst and context for the developer to write the implementation.

Scott Hanselman says, "This is like NUnit that generates prose." There seems to be a bit of buy-in for this. Perhaps C# doesn't lend itself to the readability of the spec implementation. The business owner writes this through the ears of the developer that is sitting next to him.

Part of BDD is generating a specification document directly from the tests. This allows the tests and the information being passed back to the business analyst to stay in sync better. This is NOT to replace verbal communication, but again to provide a talking point to augment the conversation.

Thoughts

It seemed as though the thoughts around BDD have application in many parts of the development life-cycle. BDD practices are useful for clarifying the discussions that should be taking place during the entire process. The initial definition of user stories is helped by these practices. During development, BDD practices help developers see the bigger picture. Finally, and importantly, the executable specifications serve as a note to the future self. In other words, when you come back to the code, it is easier to understand why the test was written in the first place.

Much of the confusion came about because these thoughts are useful in so many different places. It seemed that participants saw the potential to have certain pains alleviated, then latched onto that particular portion of usefulness. BDD is aspect-oriented. It is a cross-cutting concern and does not simply fit into a single portion of the development process. Wherever there is conversation in the development process, formalizing that conversation helps to remove ambiguity.

Perhaps this is more useful when you MUST generate documentation. Not everyone needs to have everything generated in paper form. For some business, people, they feel better seeing the specifications generated as either a sheet of paper or a web site. Even in situations where this documentation must be generated, this documentation is not set in stone.

I'm pretty convinced that we don't need a separate tool to do effective Behavior Driven Design. We need to get much better at language - both natural language and expressing natural language with programming languages. As if the natural language wasn't ambiguous enough, we are forced to complicate it by writing something that the parser can understand.

The conversation about this is still in process. I'm sure that I don't know everything about this. I hope to continue to look in this area and find ways to write better software with less pain.

altnetconf - Alt.Net First Impressions

I'm not sure how much I will find myself around the computer this weekend, but I thought I would post my impressions of the ALT.Net conference as we go along. The comments during the opening remarks and fishbowl seemed to center around a few core concepts:

• Though perceptions might be otherwise, nobody expressed total contempt or hatred of Microsoft.


• Everyone wants to write better software.


• Writing better software probably means using tools that weren't developed in Redmond.


• The overriding of "better software" seems to be maintainability.


• Drag-and-drop is still the whipping boy of this crowd.


• Alt.Net IS alternative because most .Net developers seem to use whatever tools Microsoft puts out (and MSDN talks about). Conference attendees are much more likely to use tools that are alternatives to simply the set put out by Microsoft.

I'm looking forward to hearing more opinions and thoughts as we go along. I'm not sure how much will be decided. Many seem to want to come to a consensus, but everyone in attendance is so passionate that it may not happen. We'll see. At least we're trying to figure out what is going on and how we can deliver better software for all involved.