Claudio Perrone’s Monologues

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 usual, we voiced our opinions, listened, tried ideas and shared stories, occasionally challenging but also consistently helping each other.

On the closing comments at the end of the workshop, Jimmy tried to identify the main theme that seemed to emerge from the dialogs and suggested “cultural differences”. I can’t agree more. I was particularly touched by some extreme stories of titanic struggle while working with certain teams and customers due to differences in attitude, values, ethnic group and gender.

At first, I was vividly shocked. In the past, particularly while working as a consultant, I have been deeply involved in some seriously complex projects, where hostile customers, uncooperative teams and blaming cultures seemed to preclude any chance of success from day 1. Yet, I’ve somewhat always managed to reverse the “natural” course and helped teams succeed well beyond anyone’s expectations.

But these new stories forced me to dig deeper and question my own abilities once again. I thought over and over about what gave me strength in those situations. Why didn’t I just quit? Where those new stories all that different from mine?

Maybe. But, at the risk of sounding extremely preachy, here is a thought. There are no quick-fix solutions to these problems but there is a definite path. To get all the support you need, you have to lead by example, respecting each other’s skills and talents, fully trusting everyone and expecting them to meet that trust. Show integrity and passion, be determined to do what’s right and help others to get there as well. This has nothing to do with being nice. It takes a lot more than “being nice” to develop the will, knowledge and skills to move people for the greater good. I know now, more than I ever knew, that my strengths come from the inside, from being (or, rather, trying to be) principle centered.

When I mention how profoundly “The 7 Habits of Highly Effective People” helped me throughout my personal path, I often hear “Oh, yeah, I read that book” (btw: get the cd first, it is much more effective, imho). But I think most people may not reflect on the hundreds of hours I spent listening to the audio tapes, over and over, learning, teaching to others, and fundamentally reprogramming my behavioral scripts.

I am eternally grateful to those who shared their stories at the workshop; I really wish I could help. I hope to see you again next year, at the latest.

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 know. I’m truly blessed.

As you may have already noticed, this year is looking really promising for me already, so I decided to break my stupid own rules and write down my New Year’s resolutions while the enthusiasm is still high.

Write more code

Last year I moved full steam into product management, release planning, agile coaching, strategic development, research, coordination and business development. In other words, I’ve been fighting like a lion, aiming at removing obstacles, mitigating risks, dealing with constraints, creating new ideas and pursuing new opportunities.
There is something horribly missing in this busy picture, however. I haven’t written much production code for the best part of the year. So that’s it? Years of hard work refining “the craft” have been totally thrown out of the window? Guess what, I’m not prepared to let go of it.
In my humble opinion, C# 3.0 absolutely rocks. I spent Christmas playing with Moq and parsing expression trees for a toy(ish) Linq provider I developed! If you just think that all of this is sad, leave this blog now…there won’t be anything for you to see here

Therefore this year
Write tons of code. Production code. Learn, share, help and lead by example. As usual, strive for elegance and simplicity. Be humble, it will be easier to improve.

Simplify

But I also want to help people writing more meaningful code. We like to estimate, quantify, measure lines of code, complexity, coverage, we start the stopwatch, we really want to be faster. Some metrics are incredibly helpful; others are not that beneficial.
If there is one thing that I learned while working in the software development industry all these years however, is that we are so distracted by the details of the solutions that we offer, that we often fail to see that we end up trying to solve wrong problems in the first place.

Therefore this year
Strive for elegant simplicity, being more creative than ever… Simple solutions are often incredibly hard to find and may not be there at all. But do not to give up too quickly. Challenge the requirement definitions, as actual needs are almost invariably poorly understood and defined.

Be Focused

I want to be less reactive than I have been in past year. At times, I have been a slave of Outlook for the best part of my day. It is part of my evolving role, I guess. I tried lots of techniques and addins to cope with the ever increasing amount of emails and tasks that clutter my existence…I know, it is only an excuse.

Therefore this year
Stay alert and curious, but don’t get distracted easily. Be less committed and just involved, or simply let go of things that are not that important.

And finally…

Contribute!

I constantly learn things, from everything and everyone, but I sometimes feel that I’m not able to give much in return.

Therefore this year
Contribute more actively to the development community. Work on some meaningful open-source project, speak and write more often.

Happy 2008!

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 sharp.
No thanks, in this case I’d rather be a smart coward and influence my destiny in complete ignorance. After all, I can still be “imperfect” and yet make a difference in this world.

Edward de Bono, one of the leading business creativity experts, likes to describe intelligence as the horsepower of a car, our potential. The skill of thinking is then the skill of the driver. A poor driver on a powerful car can still be outperformed by a skilled driver on a humble car.
We may not all have the same IQ, but we can certainly learn to become skilled thinkers.
If I could only remember where I left my car keys

The irony is that highly intelligent people may fall in what Edward calls the intelligence trap: for example, they may be unwilling to take risks for fear of not being right all the time. Or they may be so good at supporting and “sell” their own point of view that they may never find a need for seeking potentially better alternatives. Ouch!
As the French philosopher Alain (Émile Chartier) once said:

Nothing is more dangerous than an idea when it’s the only one you have.

I recently found some evidence that IQ and creativity are different in the most unlikely of all places: the Big Brother House (BB8 UK).
Uh? Big Brother? Well, I confess. I usually don’t watch these programs, but this year I’m hooked. The best part is shown on Sunday evening, when a group of psychologists display the result of their weekly experiments on the contestants.

A few weeks ago, Big Brother called each housemate in the diary room and presented them with a simple task. Within one minute, they had to identify things you can and can’t do with a paper clip.
Each of the housemates came up with a bunch of ideas; it was certainly interesting to observe how the constraints of the environment and their condition greatly influenced the answers they gave.

But when 20-years old Brian entered the room, something unexpected happened.

Poorly educated, gullible, goofy and - by his own admission - not one of the brightest people around, Brian quickly identified a rather impressive number of ideas and easily outperformed all his housemates.

As the experts indicated, within the given time constraints, he gave proof of excellent:

• Fluency: the number of meaningful ideas generated
• Flexibility: the number of different categories of relevant responses
• Originality: the statistical rarity of the responses
• Elaboration: the amount of detail in the responses

In conclusion:

• Don’t envy others for their intelligence, because you can be (at least) as creative and as they are.
• Explore the world with a fresh perspective and you’ll soon see things others can’t see.

Along the way, you’ll pick up some serious thinking tools to help boosting your potential.
Like a blacksmith, I’m hand forging those tools for you.
The first one is almost ready, and I’ll hand it to you in my next post!

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 been chosen for them by their parents.
I didn’t have a particular reason; it was just for fun.

A co-worker (who later changed his mind and chose to be called Lone Ranger) initially opposed to the idea and argued that “you can’t wake up one day and decide to call yourself, say, Alexander the Great”.
Why not? – I replied.
I thanked him for the really great suggestion, as he had just found my new name!

Alexander was such a formidable icon.
He was an invincible fury who conquered most of the world known to the ancient Greeks.

But there is a different reason why I still use that name to this day.
It is a powerful reminder that you should never be afraid to question the rules and revisit your assumptions, particularly when others say “it can’t be done”.

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 been a painter, a radio DJ, a dancer, an aerobic instructor, and many other things I can’t even remember.

Even if we discount the tiny possibility that my attitude towards creativity may have been genetically determined, my character has been powerfully influenced since early childhood.
In my family, we have always valued originality and worked extremely hard to develop our talents.

Although it might sound widely pretentious to state it here, I know I can be (and I have been) extremely creative.
Unlike my mum, however, I’m not an artist.
I’m a software developer, after all; I’m more technically inclined and definitely a bit rusty on poetry

I hopefully inherited her capability of creating ideas that can bring success in any field and personal life.
The problem with such attitude, however, is that you can only accept it for what it is – it’s not easy to develop a gift, is it?

The truth is that creativity can be learned and developed indeed, and it has nothing to do with intelligence.
Perhaps you knew this already, but I was surprised to make this discovery very recently and by pure coincidence.

Luckily, my motorbike broke.
On my new bus commute to work, I started speed reading creativity books voraciously.
I learned theories and ideas form Edward de Bono, Michael Michalko, Roger von Oech and many others.

I shared some of these findings with my team in our latest muffin morning, and will share them with you here, in my next few posts.
I will present some behaviors, mental models and tools that I found useful to organize thoughts and generate tons of ideas.

My dream is to evolve as a better thinker, to be original, maybe even revolutionary.
And I would love to share and help others to evolve too: my family, friends, coworkers, and, yes, perhaps even you.
I know, it’s just a dream, so please don’t judge me.
We are all allowed dreaming after all, although most of us have long forgotten how to.

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, I thought, and it must be shared among the community.

Well, that was the theory! As I started talking to Ron, I quickly realized that it is almost impossible to talk about BDD scenarios without first introducing the agile context on which we can apply these techniques.

The result? I ended up talking about some agile values and techniques that I have adopted over the years, and I honestly didn’t manage to even tackle the essence of BDD.

Forgive me Dan, but we really run out of time!
Well, if anybody is still reading this post, please go to Dan’s site and get more info about his work, straight from the source.

By the way, have you noticed? I’m such a bad blogger, aren’t I? It’s really a bad sign when you forget the password of your own blog administration

Ron however, reminded me of how gratifying is to share and learn from each other.

So I declare this blog open again.
Be patient, and you’ll soon see something which I hope you’ll find interesting.

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?

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.