Firstly, thanks to Seb for organising the ALT.NET beers conference last night. I had a great time and met some very interesting people who I hope to see at future conferences.
The first topic was on two related questions, which were something along the lines of "why would I use a non-relational database" and "how would I architect a database differently if I was writing more than I was reading".
Personally, I wasn't really getting the question here. The whole thing about "writing more than I read" made no sense to me - why bother writing it if you're never going to read it. The speaker was unable to really identify where his pain points are with his system. I felt that there was an interesting discussion to be had, but the conversation didn't seem to inspire many people and it wasn't carried too far. I would welcome this discussion continuing elsewhere and if it does I would be keen to take part in it.
We talked a bit about document databases here, Ayende naturally getting involved as he has designed (not built, mind) a document database before. The idea is that if you want to store fairly unstructured data, you would use a document database. Again, this isn't something I know much about and I wasn't sure what the benefits of a document database are over, say, storing the document on a file system and then indexing the information you want to search separately (e.g in a relational database for querying, or search appliance for searching).
Note: I was going to discuss this further outside with Ayende but the topic changed to BDD which is something I have recently starting doing so I wanted to hang around for that one! If you're reading then perhaps we can discuss it next time?
So as I said, we moved onto BDD which Ian Cooper summed up excellently with a great analogy, which I won't repeat here. What it bogs down to is that whilst test driven development is about ensuring that we do things right, behaviour driven development is about ensuring that we do the right thing. Given that we had a bunch of Lean/Kanban enthusiasts there, I thought it quite appropriate topic. With BDD you minimise rework by getting things done right the first time, this will naturally help to you can increase throughput and decrease wastage, which is what Lean's all about.
So having recently started a new job (which explains my lack of recent blog posts) I am trying to introduce BDD to the team, using SpecUnit.Net. They don't do TDD at all, and I think BDD is not only easier to adopt but also adds much more value. I am actually new to BDD, having consistenly read about it I'd not had the chance to actually try it on a proper project. I am impressed with the effect and the way it makes you think about your code, so much so that I couldn't see myself not developing in this way ever again!
Anyway I actually had some interesting conversations after the event about BDD. I will try to gather my thoughts about this soon and perhaps capture them on a future blog post.