The 2nd day of QCon was not one where I chose wisely. My focus for this conference was everything Agile and anything from the well-known speakers. So I ignored most sessions that had words like REST, SQL or Java in it. How wrong I was…. But I did not discover that until I heard and read about all the great feedback those got while the only ones that could keep my attention where hosted by Dan North and Erik Meijer.
So, let's discuss Dan North's talk on Deliberate Discovery. It kept my brain hurting for the remainder of the day, even after speaking with Dan and reading his associated post. And I still don't know whether I'll be able to reproduce his message. His point is that many failures in our projects are caused by ignorance. Ignorance on technology, ignorance on organizational aspects, or even ignorance on your own ignorance. Essentially stuff you don't know yet on any level (axes as he calls it) that will reduce or hamper your throughput. And it doesn't necessarily has to apply to you or your team. Ignorance of your stakeholders can be just as catastrophic. Some of the ignorance will become apparent during poker planning sessions or your user story workshops, but that's only going to be the tip of the iceberg.
So what can you do about that? Well, that's the part which I haven't really figured out yet. Fortunately, Dan is still working on that as well, but some concrete things he mentions includes having a brainstorm before you start breaking down stories. In this brainstorm you focus not on the things you already know, but on the relevant things you don't and which may impact the project. I suppose such a brainstorm should include the team, the stakeholders and anybody else how might have something relevant to contribute. I think that explicitly focusing on the ignorance is the differentiating aspect here.
Another example he gave is what he calls Test Driven Testing. If you practice pure TDD, you won't write a single line of production code without having written the test for it (or specification if you will). But sometimes it might be wiser to start with a Spike to do some exploratory developing to see if some idea works out or not. If it doesn't, throw it away. But if it does, start adding first-class unit tests as if you would have done when doing TDD from the beginning. That should force you to refactor or redesign that code to make it testable. If you ask me, Test Driven Refactoring may be a better name.
Anyway, another talk I went to was Erik Meijer's mathematical analysis of SQL versus NoSQL. I must admit that it was very funny to watch. But to be honest, I had no clue of what he was talking about other than being able to vent his opinion that SQL databases and NoSQL databases should be seen as complimentary rather than as competition. Taking into account that he is working for Microsoft, that may have been the real message. Nonetheless, the audience was thrilled so it must have been good…
After taking a quick bite at the Google-sponsored reception, I went to the CQRS OpenSpace discussion I proposed earlier that day. I was quite surprised to finally find the entire .NET minority group present at QCon. It was great to be able to hear the opinions and challenges of all those smart people. The discussion continued for more than 1.5 hour, so that's prove it is something worth discussing. If you’re interested, I’m currently maintaining a demonstration project on CodePlex that uses Silverlight, the Ncqrs framework and some other .NET technologies to demonstrate Event Sourcing and CQRS.