Claudio Perrone’s Monologues

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?

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.

Getting to Denver hasn’t been easy at all. The flight to Chicago has been delayed for several hours and as a result I missed my connection.
I finally managed to get to the hotel in Denver at 11:30pm local time and, although I was in a terrible state, my body just refused to fall asleep.

In the morning, I met Erik Doernenburg at the lobby and together we drove back to the airport to join Niclas Nilsson, Arjen Poutsma and Mike Roberts.
With the exception of Mike, everybody else is a survivor of the expedition to Cortina early this year so I’m sure that Jimmy Nilsson (who co-organized the event in February with Andrea Provaglio) will be proud of us.

With two cars available, we finally started our trip to Crested Butte and I took the chance to know a bit about Mike’s work, my co-pilot in this circumstance.
Given his involvement in the development of CruiseControl.NET, it was natural to talk about software configuration management systems and the possibility of using Windows Workflow in this context.

We also went to a bit of discussion on the topic of graphical languages and code generation.
Considering my background in electronics and my experience in automation where graphic languages have been successfully used for years, I’m often surprised to see how much resistance I encounter on the subject.
The future will tell if finally some form of model-driven development will reach the maturity and the widespread adoption that I believe it deserves, but it is clear that a lot of people are currently very sceptic or quite simply indifferent.

Code generation is another controversial subject as many see it as a workaround to a fundamental issue with code intensive frameworks and languages.
I’m certainly keen to explore both subjects in the next few days.

Driving to Crested Butte is quite an experience as the scenery is absolutely breathtaking.
In fact, since we reached an altitude of about 3900m, the body requires a bit of adaptation. We kept drinking a lot of water to avoid dehydration, which apparently is the main enemy in these cases but I must say that at some point I really started falling into pieces given the combination of jet leg, lack of sleep and scarcity of oxygen.
After 7 hours (yes we took it very easy) we finally reached our final destination, a fantastic house that Niclas booked for all of us a few weeks ago.

Finally, we ended the day into Bruce Eckel’s house where some of the other delegates convened for a little party. I was pleasantly surprised to see Philip Nelson again, another friend from Cortina. We had some little “geeky” conversations but quite honestly I was so tired that I doubt I made any meaningful contribution.

Tomorrow I will hopefully be able to describe what happened the following day, during the official opening of the workshop.

I feel a little bit strange writing a post after such a long time. Some say that a blog is like a shark: it has to keep moving all the time to stay alive; I’m afraid the shark is long dead.

I often wonder how certain people keep up writing so often and consistently. Does everybody else have so much more time and talent than I do?

Of course not. It would be such a self limiting belief that I just refuse to consider the thought.

Some people are fast writers; clearly I don’t belong to that category, which is pretty peculiar considering that my very first job was as technical writer! (That was a long time ago, before I managed to decisively follow my heart and start earning a living in software development).

Sure, expressing my thoughts using a foreign language is slightly less immediate, but the more I think about it, the more I realize that I really find the act of writing only moderately pleasing and tremendously painful.
In fact, I find so hard to choose the right words, that in the process my entire body often saturates with anger and frustration.
I get grumpy, my beard grows twice as fast and only my cats dare to stay close to me :-).

My wife once said that she would divorce immediately if I ever dare writing a book. She was joking, but it should give some idea of what I’m capable of becoming.

So why am I writing today? Well, there are things I just have to report.

I am now flying to Colorado since I am one of the few lucky delegates of this year’s software architecture workshop in Crested Butte, a beautiful place right at the heart of the famous Rocky Mountains.
I will certainly meet some old and new friends in the next couple of days and I’m sure you will soon wish you were there as well.
Stay tuned!

Writing about muffin morning was fun, perhaps because our current sessions are very enjoyable.

As I will gain more understanding of the forces at work and the wide implications of this simple practice, I will update the pattern with the new findings.

By the way, if you are implementing it (or considering putting it into practice) within your team please share your thoughts!

For my future reference, I want to add a few points that I haven’t covered in my previous post, mainly because a pattern should be based on observations rather than speculations.

So what did I leave out? Many things for sure, but for now I only have this list:

• Environmental factors conducive to this type of activity
• Relations/interactions with other practices, for example daily stand-up meetings
• Higher management perception/acceptance
• Pressure/deadline handling
• Basic financial support and equipment
• Team size/composition/roles and correlation with volunteer availability
• Finding engaging topics on a regular basis (experiences on the job, technology/product/process, dept vs. breath of coverage)
• Format (lecture, open discussion, study group, etc)
• Time management (preparation phase, delay, overtime, rescheduling, recurrence)
• Session/topic follow-ups
• If/why/how-to involve other teams

In all the cases I just mentioned, I either don’t have the problem or I don’t have conclusive data, solutions or suggestions.
At least, not yet :-).

At the software architecture workshop held in Cortina last February, JC Oberholzer mentioned that he has been doing a special meeting on a weekly basis for the last three years, with the aim of sharing technical information and improve the morale of his team.

In the past, I thought several times about doing something similar but I was never quite sure it could work out in a sustainable way; JC’s example, however, inspired me to try it here at InnerWorkings and, after successfully testing it for almost three months, I can certainly announce that not only it works for us, but it’s becoming part of our DNA!

Would you like some details?

Ladies and Gentlemen let me introduce you a half-baked (bun…oops…pun intended…ok stop!) pattern that you will never forget:

Muffin Morning

Software developers mature distinct experiences and learn technologies and techniques that can be relevant to others in their team.

How can I share technical information across a team/organization and encourage a healthy self-learning culture?

The most effective developers generally invest a significant amount of their own time researching new technologies, seeking optimal solutions to problems and continuously improving their skills; this is hardly surprising given the rapid transformations that the software industry imposes.

What is needed is a way to encourage team members to share technical information with others.

Volunteer to illustrate and debate a technical topic relevant to the team on a regular basis. Encourage others to do the same by keeping things simple and very informal. Meet for an hour every Friday morning without exceptions, and provide muffins, doughnuts, coffee, etc.

The most important thing to keep in mind with muffin morning is that if presentations become too formal, too long or elaborate, few will be able to contribute as it will require too much preparation; a team deadline could easily break the regularity of the event and muffin morning would become nothing more than a failed experiment.
As a consequence, PowerPoint slides should be absolutely banned and the urge to show live code examples on a projector carefully considered.
I personally find that the most successful presentations are the ones that use a whiteboard only, as they encourage a greater dialog and instigate curiosity to find out more about a particular topic.

One of the biggest attractions of muffin morning is its capability to involve several team members in a communication and self-development exercise.

Independently from their presentation skills, volunteers are almost invariably cheered and supported by the rest of the team since they earn the respect of their peers for their courage and effort.

While volunteers have usually enough interest and understanding of a topic to be able to illustrate it to their peers, it is not expected for them to be experts on the subject. Indeed, often some other team mate may happen to have more experience or knowledge about the subject and consequently play a supporting role for the event.

How do you create a strong, positive culture within a team/organization? I considered this problem several times throughout my career. In fact, I think about it all the time.

At some point in my life, my habitual focus on self-improvement gained a whole new dimension as I realized that I could achieve something really amazing only with the synergistic cooperation of others.
I mostly owe this framework of thinking to Stephen Covey: his seminal book, The 7 Habits of Highly Effective People, played a major role in my quest for personal growth.

As developers, we are used to consider software development in pure technical terms: we focus on various technologies, we master the tools and we improve the processes.
While all these elements are very important, there is one fundamental omission; we often forget about the people we work with.

No, I’m not referring to the resources we allocate in a project plan; I’m rather thinking about individuals like you and me, with their cultural differences, their talents and the ideas that they bring, the ones with their struggle to keep up with endlessly evolving technologies, but also with their pride for a job well done.

I recently had a conversation with a developer who told me that people have to earn his respect and trust. He was pretty surprised to hear that I assume people are totally trustworthy unless proven differently over time.

I can understand his point of view. It is the result of a self-preserving mechanism that is unfortunately very common in too many corporate environments; in fact I, for one, have been poisoned by years of the worst corporate (anti) cultures, witnessing people fighting against each other on a daily basis; it’s within enterprises after all that I learned terms such as deception, hidden agenda, blame game, scapegoat, etc.

It does not have to be like that, however.
It takes incredible courage, passion, openness, integrity, determination, respect. These are the same core values that Covey taught me, values I firmly believe in.
Incidentally, I can also argue that these are the same values at the core of all agile methodologies, with their emphasis on individuals and interactions.

As a team leader, over the years I tried several times to become a catalyst of change by helping others to give their best and genuinely succeed in their careers.
I’ve been told more than once that my culture of openness is risky, that it will bite me back hard some day; I’ll keep taking my chances despite the cynical remarks and the unavoidable failures, thank you.

Today, I’m happy to observe that the InnerWorkings’ ecosystem shows more than a few traces of this culture almost everywhere; our thriving daily standup-meetings, internal forums, pair programming efforts, weekly muffin mornings, etc. are a testament of a social culture that is expanding well beyond my wildest dreams.

So, how do you create culture? I’m afraid I don’t have the complete recipe. In fact, I can’t even take full credit for what’s happening in my organization.
But I have one certainty: you too have the power to make a fundamental difference in your organization, your career, your life.
All it takes is courage.

In this post, Paul Gielens mentions the article ”Design and Implement a Software Factory” published with the new issue of the Architecture Journal magazine.

The article describes Microsoft’s progress in developing a proof of concept of a factory in the healthcare domain. It is definitely worth a read, particularly if you are (as I am) struggling to find a real, or at least realistic, example of a factory schema.

On a related note, you might have missed Ron Jacobs’ ArcTalk interview to Jack Greenfield and Mauro Regio on the very same subject; the interview serves as an introduction to the HL7 project and to the whole concept of a software factory.
Towards the end of the talk, Mauro gives some comments about the perceived loss of developer creativity that switching to a more “industrialized” process seem to imply. Well, I totally share his view that creativity is not gone at all, but simply repurposed to solve new and more interesting problems.

A while ago, I showed to my team an early prototype of a very simple domain-specific language that I wrote which will be part of a product line that we are building.
To be honest, there wasn’t much to it; after the quick demo, however, one of the previously skeptical developers looked at me with evident surprise and said:
“Claudio, now I finally get it! You are going to remove the boring parts of my job”.
Yes I am, buddy… yes I am :-).

Last week Jimmy Nilsson expressed his growing dislike for today’s overuse of XML, particularly when conceived as a surrogate programming language.

I really share Jimmy’s concern, especially when I think about the XML abuse I’ve been subjected to while creating languages and recipes using the Domain-Specific Language (DSL) Tools and the Guidance Automation Toolkit (GAT).
On the other hand, I recognize that it is totally unfair for me to complain; this is, after all, the price we pay for dealing with prerelease software.
In fact, the DSL Tools team already announced that will soon provide us with a modeling language able to deal with the .dsldd file and hide that ugly XML from our sensitive eyes.
I haven’t heard of announcements regarding similar improvements on the GAT side, but I choose to be optimistic and wait for new developments.

Unfortunately this problem does not affect prereleases exclusively; released software, both closed and open source, is not immune either.
Let’s face it, it is far too easy to define and process a language using XML for not taking advantage of it; in a not-that-distant future, however, I have no doubts that we will look back and laugh thinking about how we put up with manually dealing with its angle brackets notation on a daily basis for all these years.

Apart from really extreme cases such as XSLT, perhaps XML-based build languages of the likes of Ant, NAnt and MSBuild are among the most obvious and discussed examples of how a good idea can turn nasty when scenarios get a little more complex than anticipated.

Martin Fowler already suggested that today’s enterprise applications require pretty sophisticated builds which are better handled using a full-fledged programming language.

Last year, he also wrote an article about his explorations using Rake, a build language based on Ruby. In a nutshell, using an internal (text-based) domain-specific language such as Rake enables developers to easily switch to the external general-purpose language (Ruby) whenever necessary.

But how sophisticated can builds be? To put a little bit of perspective into things, let me tell you that for more than two years at InnerWorkings we have adopted a continuous integration solution based on CruiseControl. NET and NAnt; unless you’ve read Jimmy’s brilliant manuscript of his upcoming book (in which I was honored to make a small contribution as guest author) you will be surprised to hear that we manage to automatically and continuously build, obfuscate, package, test and deploy several hundred .NET solutions.

While I think that we have done more than a reasonable job at maintaining a good degree of modularity and reuse in our XML scripts, our tolerance to NAnt’s notation has been tested several times.

Resorting to a DSL written on top of a full programming language as Martin suggests would definitely help, but I have the impression that a purely text-based language may still be rather inadequate at solving one of the issues that we often face, particularly when dealing with many scripts in parallel like our scenario requires: lack of run-time visibility about the progress of each build.
Do I have a viable solution? I’m not sure, but I speculate that it won’t be long before we will see the raise of a new generation of continuous integration systems built around the upcoming Windows Workflow Foundation, with steps defined using domain-specific activities.
What do you think? Is it a daft idea?