Claudio Perrone’s Monologues

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 help people in our industry (!), she posed the classic question: Is code art? Is there code that can be considered as such?

She seemed surprised to hear that I categorically didn’t think so. After all, we were just talking very passionately about our profession and the creativity and skills it requires; so why not?

I quickly learned that if you try to debate with Carli, you better have a solid point. LOL, she easily crushed my weak attempts to make my case. Luckily, Andrea Provaglio joined the conversation and supported my view. He pointed out that we can certainly find beauty in code. But aesthetic appreciation alone is not sufficient to define something as “Art”.

In hindsight, my biggest grief with defining code as art, is that code has a functional purpose. It is born to be useful; it solves problems; it creates opportunities. Code is like any “how-to” books: it has a function and a limited time-span.

Poetry, on the other side, is (functionally) totally worthless; we don’t “need” it. I can’t read a poetry book to learn how to do something. Yet, some of these books are simply immortal because they force us to reflect on who we are; they deepen our understanding of our human condition; they may even make us cry unexpectedly while truly touching our souls.

In other words:

If writing software is about problem solving, then code will never be art. At best, we (the developers) create beautiful hammers.

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!