I just read Brian’s post titled “The art of science (or the science of art)“, which reminded me of certain discussions I had over dinner at the workshop in South Africa, particularly with Carli Deysel, from ThoughtWorks. On the very first evening, as we were talking about our mutual aspirations to change the world and [...]

The software architecture workshop in South Africa has come to an end. Spending a few days in a beautiful game resort close to Sun City, I worked closely with a tiny group of new and old friends from different parts of the world. As in previous editions, we used the open space organizational framework. As [...]

I’m just back from Sweden, where I met several folks from Microsoft and our really good friends and partners at Cornerstone. I really like going to Stockholm as people are really bright and welcoming over there! Tomorrow I will be flying to participate to Jimmy Nilsson’s “European” Software Architecture Workshop…in South Africa!! I know, I [...]

There is this common notion of “intelligence” as a largely inherited talent that can be assessed in one hour interview. Do you know your Intelligence Quotient (IQ)? I don’t. In fact, I’m terrified by IQ tests. You see, those tests may well find out that I’m an idiot, or at least, that I’m not that [...]

Have you ever believed that you could never learn to be creative because inventive people are born with some special ability that ordinary people like you don’t posses? A few years ago, I suggested to each member of my team to choose a nick name, an inspiring name that would break away from what has [...]

What would you say if I told you that creativity is a skill and not a gift? Like any other skills, it can be learned and developed. Many will be surprised to know that my mum is an accomplished and multi-talented artist. She is a French-Italian poet, interpreter, writer, editor. In the past, she has [...]

Yes, it’s true. Ron Jacobs has finally released the interview I did with him a while ago for his hugely popular ARCast and ARCast.TV. My initial plan was to use this fantastic opportunity to help promoting the excellent ideas that Dan North has developed in the field of Behaviour-Driven Development (BDD). It’s a great concept, [...]

In case you missed the official announcement, the CruiseControl family of Continuous Integration (CI) systems has a new member; please welcome CruiseControl.rb.

I’ve always been addicted to its .NET counterpart, but this guy is so incredibly simple to setup and tweak that it certainly deserves a lot of attention.

In fact, it is already up and running here at InnerWorkings, right beside its older brother, polling data from our trusted Subversion code repository; it executes ruby-based acceptance tests on a .NET project we are working on.
We could certainly move the entire project there, but for now we’ll probably leave everything as it is.

After all, we can still use the same cctray client to monitor both CI systems on our Windows machines.

Not surprisingly, CruiseControl.rb uses Rake, which is quickly becoming my favorite build language; I find it way more enjoyable and expressive than any xml-based language I’ve used in the past (mainly NAnt and MSBuild).

There are rumors that CruiseControl.rb is set to become the “official” continuous integration system for Rails applications.

It is certainly an easy choice if you are into Rails, but I would definitely consider adopting it for any type of application, including .NET.

Why? Well, here is my story :

I came across behaviour-driven development (BDD) early this year at the software architecture workshop in Cortina.

When Dan North started illustrating the concept and his findings, I almost immediately felt that he was on to something with incredible potential; so much in fact, that I definitely consider that session the highlight of the entire workshop.

On the surface, BDD can be described as a simple refinement of test-driven development (TDD).

After practicing TDD for a while, it is easy to realize that test-driven development is more about code design (specification) than testing (validation).

In fact, it is about expressing the behavioural intent of the systems we are developing.

As a consequence, BDD is a practice that, at its core, advocates modifying the nomenclature of our tests to better support this mindset.

There is a lot more to it of course, but since I still have to prepare my luggage and I risk to be late for my flight to Barcelona (yep, I’m going to Tech-Ed Developers!) I won’t go into any detail today.

I will write about it very soon, however, as I’ve been trying it for a while and I think it is only fair to share my experience.

In the meantime, I strongly suggest reading the excellent article that Dan published for Better Software magazine last March and that now is finally available online.

While Visual Studio has always been the de-facto standard for writing solutions based on Microsoft technologies, savvy developers have often extended it with additional tools to help them better handle the increased complexity of today’s applications.

My team is no different, and, over time, we incorporated all sorts of extra tools, using a pretty aggressive “buy/build/open-source” strategy.

To my great surprise, early last year I heard about the plans to release Visual Studio Team System (VSTS) and Team Foundation Server (TFS); I was under non-disclosure agreement, and getting the news directly from the mouth of Somasegar (Corporate VP, Developer Division) contributed to create a certain level of expectations.

In the months that followed the release, I attended to a few presentations on the topic and the excitement was soon replaced by a bit of disappointment.

It was evident that Microsoft was mostly targeting enterprises that had already plenty of money to invest and was somewhat ignoring smaller realities.

I also felt that existing open source tools were already providing equivalent or better support for well known problems such as unit testing, code coverage, static analysis, version control, continuous integration, etc.

I started considering a slightly different perspective only recently, after I attended an excellent presentation organized by Microsoft Ireland on the subject of agile development, VSTS and TFS.

A few days after that event, I decided to download a trial version and take the system for a good spin.

This time, instead of focusing on the specific developer tools (which I already knew) I concentrated on the architecture, the customization capabilities, and the extensibility points.

I came to the realization that VSTS has a lot more to offer than a simple integration of tools; it simplifies the process of building software by providing better visibility across the various roles involved (e.g. developers, project managers, business analysts, testers, etc).

It is also a very extensible platform; if we don’t like a process or a tool we can bend the system to adopt a better one.

So, do we “need” VSTS?

As usual, it depends.

In our case, we have already created a process that we re-examine and refine frequently; we have tons of tools, workflow capabilities, reports, and excellent metrics we work with.

Although the early days are long gone (when we could simply track our progress on a whiteboard), we can still rely on a healthy dose of verbal communication; after all, the first commandment of the agile manifesto states that we value (more):

Individuals and interactions over processes and tools

Admittedly, building all this didn’t happen overnight, so I can see why other teams may choose a different path and consider using VSTS.

Have any of you guys seriously tried it yet?