Claudio Perrone’s Monologues

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?

I finally moved my extremely interesting and groundbreaking blog to claudioperrone.com.

I thought about doing it for a long time, but I haven’t really bothered until now.

The geek in me, however, has finally taken full control of my destiny and now I can finally tweak everything I want: permalinks, themes, text filters, and, even more importantly, spam filters!

Since I’m moving away from a service based on .Text, what do you think a traditionally hardcore Microsoft technologist like me would install? Community Server? DasBlog? Perhaps Subtext? Build my own engine?
Nahhh… boring, boring, boring… been there, done that.

In the end, I decided to install Typo 4, a little jewel based on Ruby on Rails.
I can almost hear you guys: Blasphemy…This is not .NET! Betrayer etc, etc (well I know, others may ask Ruby on what???, but never mind).

No, I’m not out of my mind.
I still love .NET, and I passionately work for an outstanding company whose purpose is to reveal more efficient ways to help developers building enterprise applications using .NET technologies.

The truth is that it is time for me to give Ruby another chance.
Yes, you heard me. I said another chance. In fact, I tried it in the past, with modest results.

The problem was me, not the language, of course.
I kept questioning everything.
Can you imagine it?
Why this, why that?
How can that code be manageable in a reasonably big application?

I remember going through the Pickaxe book with extreme frustration.
I lost the battle; Ruby was too different; I didn’t “get it”.

But do you know how children learn their (first) language so fast?

• They don’t have anything to compare it with
• They don’t question its value
• They don’t set high expectations
• They just absorb everything, like only the best sponges can do

So there you go; I want to be a child again.

Arguably I have being exposed to these concepts for too long. Some colleagues already played with Ruby, and, largely thanks to the early adoption of Michael O’Brien, both strategic applications and tactical scripts have been already built for internal use.

And like a disease, the doubt that I might have been a bit too superficial in my early judgement is spreading all over my body.

At the workshop in Crested Butte, Niclas Nilsson, Martin Fowler and Bruce Eckel giggled when I naïvely told them that I have a “static” mindset.
Puzzled by my (admittedly poor) choice of the word “static” in that context, Bruce smiled and asked me if I meant that I live in a static world where nothing ever changes!
Eh eh, we had a good laugh.
Of course, I only meant that I’ve been pretty comfortable with the perceived sense of security that “strongly typed” languages give me.
But now I’m ready to go back and revisit my assumptions.

So, what’s next?

If there is one thing that I’m learning about blogging is that I should never set expectations about future posts unless I am positively confident that I will definitely fulfil those expectations.
My writing energy fades away too easily.

So don’t expect anything.
Be a child.