The answer is no - a professional developer should always use BDD.
No seriously. I read this today and didn't hesitate a second to steal the topic since I there are two discussions around TDD I love; the discussion with people who struggle to write good code and the discussion with people who write really good code. I guess this is more about the latter. When I get into a discussion with the great developer it is often claimed that they think about testability when they write the code but then never find the time to actually write the tests. Yet there is always something in the code that could have been better if some tests were actually written; a few bugs that would probably have been found with tests or a design that is hard to test.
So the next argument is that writing the tests slows this great developer down. Well I would never do something that slowed my team down. Even if one person can write code that is so good it is not worth the time to write tests if that person is the only one ever working on the code - I would agree that it is a bad idea to write those tests since it is a waste of time. The problem is that you do not know when that is the case. And you need to consider the full lifetime of the code (which is typically much longer than you expected) and the time of the team to work on the code. Time to first release is typically not what is interesting but what most people think about.
So far I've been ranting about writing tests, not TDD, so what is the deal with TDD? Well I couldn't agree more with the conclusion from the fishbowl referenced in link above; a professional developer should not always use TDD but I would expect them to have tried it, mastered it and use it when appropriately. To me, that's a no-brainer.
Look at this video. I think it is a great idea. Too bad it apparently only work for Java. Will be interesting to see if this will be a hit or not. I really liked how they linked bubbles with unit tests to bubbles with implementation.
People love sending email at Microsoft. So you need a good strategy to handle it. At work I use a strategy similar to what is described here. My key principle is that the inbox should only contain things I need to address. If I cannot address it in a few days I archive it flag it so it ends up in my task to-do list in outlook. And that list is kept shorter than 10 items at all times. preferably it is empty when I go home every day. OK, that does not happen very often but my to-do list is usually shorter than 5.
But I've not been that good at keeping my gmail inbox clean. Currently I have 155 mail threads in my gmail inbox. Which is way too much for my taste. Didn't really think a lot about it before, but after reading this I realized it is time to clean my gmail inbox because there should be no difference between my work and private life. And I love the analogy between email inbox and Kanban! And I used to have gmail set for 25 so tonight I'm starting to clean up my gmail inbox too...
Malevich is a code review tool that more and more teams within has started to use for code reviews. And now my team is also starting to use it. The really good thing with Malevich is how easy it is to use. It is easy to submit changes for review, it is easy to add a comment (just point, click and start typing without having access to the code). I guess the only thing I have against Malevich is that it is a tool. Because I think the most effective way of performing code reviews is face to face. But if reality is that most code reviews are done solo by each reviewer just sending emails is not great since it means that review history is basically lost (since it only lives in the reviewee's mailbox). Another problem I've experienced with pre-check-in reviews is that you cannot see the changes between the first attempt and the last since you only diff the last change with existing code. With a good tool you can diff intermediate versions too.
Malevich was fairly easy to install too. Once I had a machine with all necessary pre-reqs it took me a little over one hour to get everything to work including restricting security to the team and customizing the appearance of the application. Add another half hour to play around with it to learn how it worked. So if you're looking for a code review tool, I would first ask myself if you really need a tool and if the answer is yes, take a look at Malevich.
There are two things people seam to love at Microsoft; Meetings and email. The latter needs a quick mentioning; there is definitely a culture at Microsoft where a lot of people tend to send email rather than walk a few meters to somebody else's office and actually talk to them. Enough about that. Meetings... I'm not sure Microsoft is any worse than other big companies but at times the calendar looks like a puzzle. A solved puzzle. And the higher up you get in the food chain, the more meetings you have. If I want a meeting with my manager's manager I usually need to plan 3-4 weeks ahead. Or ask him to make room for me.
So with a lot of meetings I think it is important to not waste the time of the participants. I always try to invite the right people rather than everybody who might be interested. But then there is the question about content. Sometimes I walk out of a meeting with a feeling that I wasted some participants time. But now I have a tool that will convert that feeling into facts; ROTI. OK, I must confess I haven't actually tried it yet. I keep getting this vision of everybody in the meeting look at me as if I've gone completely mad... But I'll find a good situation to use this and report back on how it went. Because it makes sense to me to have a small retrospect to improve the meeting.
In my experience a lot of teams that wants to start using test driven development did not write a lot of unit tests before they started to use TDD. And even if they did they often experience a feeling of getting "slowed down". So why do teams bother to do this? Well I don't think you're slowing down. You might take a more time to complete a feature in terms of how much time you're spending on writing the first version of the feature. But you must remember to think about the process as a whole. Typing code is not all you do as a developer. You do other things too such as debug. And if you reduce the time in the debugger you are more productive, right? So the reasons for adopting TDD are very similar to the reasons to adopt pair programming as discussed here. When it comes to TDD there is actually a pretty good report (if you like numbers) that show how TDD is better for you even if you already were writing tests after wards. And if you don't like numbers I would read this (actually read it even if you like numbers because it is funny).
While using properties to create a DSL does not feel like news to me, I read something that felt fresh a few days ago. It was this post on how to use extension methods to separate contexts from each other instead of having an object have methods/properties for all contexts (or even several types of objects representing the same thing but in different contexts). I think that is a very interesting idea. I just need to find a suitable little project to test it on...