Fifth and last day at Agile2011

Fifth and last day at Agile2011

I finally take some time to finish my series of articles about Agile2011. The fifth and last day was actually only one morning with two keynotes.

The morning started very well. I was having my breakfast, seating alone at one of the round tables near the entrance of the Imperial Ballroom of the Grand America, when a familiar voice asked me the permission to sit down at my table. It was Linda Rising. She was with someone who had just asked her a question. She spent some time gently answering him. When the guy excused himself to go get a refill of coffee, I took the opportunity to refresh Linda’s memories about our first encounter.

The other guy came back and the 3 of us continued with our conversation, when Mary Poppendieck joined in. She and Linda know each other pretty well, so she sat down with us. This breakfast that started like any other morning ended up being the most interesting of my week.

Linda left the table, saying she wanted to get closer from the stage because she didn’t want to miss Kevlin Henney’s keynote. She assured us he was worth listening to… which he was.

Kevlin Henney started his talk by explaining that whereas Code is the most important thing in our industry, very seldom someone dares to give a keynote about it. After providing a few interesting definitions (and distinctions) about code and craft, Kevlin set the stage by showing pictures of BSOD and other strange error messages photographed while traveling around the world, displayed on the most incongruous places : one on an airport advertisement panel, one on an airport travel information display, one on the Netherland’s railway online booking website. These slides triggered some kind of hilarity in the audience, to say the least.

He then showed screenshots of visually beautiful pieces of code like this one

Pi Code

This code is apparently functional and calculates Pi. Uncle Bob would probably argue that this is the worst example of code readability you could imagine, but in a certain way, the code does communicate the intent 🙂

One of the interesting ideas of this talk was to create a word cloud representation of your code. In a ideal case, the words the cloud highlights most should belong to your domain and not be technical. I found this idea amusing so I tried to run Source Code Word Cloud Generator on my current project (a big C# project that has been going on for 4 years and has thousands of lines of code). Here is the result.

Source Code Cloud

Ok, I confess. I cheated a little, by using the black list feature of the tool to get rid of words like string, int, class, public, private and others. Even though, you can still see that the most prominent words here are either fairly technical (Model, View, EventAggregator, etc) or quite generic (Value, Context, Data, Id, etc.). This project is an Intellectual Property management system. The domain is about Trademarks, Patents, Designs and such thinks. Well, you need to have very good eyes to distinguish the first occurrence of one of the names belonging to the business domain (which is Trademark by the way).

I am not really sure this has a real meaning in terms of quality of the code. Yes, you should tend to use words of the domain in your code, but in the end your code is written in a given language, it uses patterns and technical infrastructure. So it’s not so surprising to find language reserved words, or technical terms in code. Maybe it just proves that our tooling is not good enough yet, and still forces us to spend more time on plumbing than we ought to.

Anyway, in the rest of his talk, Kevlin Henney warns us about our own behaviors and practices. As people who belong to the industry of software, we are not there to sell consulting and management improvement methods. We are there to produce working software, and we should always try to do it better. That is what the Manifesto for Agile Software Development and the Manifesto for Software Craftsmanship intended. Writing better software by communicating with the customer and building quality in.

Wordle: SCTAGS2009

Henney finished his keynote with a quote from Edward R. Murrow

The newest computer can merely compound, at speed, the oldest problem in the relations between human beings, and in the end the communicator will be confronted with the old problem, of what to say and how to say it.

Kevlin Henney being such a good speaker, the audience was already quite thrilled after his session. But the best was yet to come.

For those who don’t know Linda Rising, I can only recommend that you check out what she does. She is a brilliant woman and has a lot to say. Of course, she started her talk by explaining that she was, as usual, in charge of giving the weird talk of the conference. She has made a specialty out of it, but I have rarely seen a so called weird talk being so well received.

Linda Rising

At first, Linda explained an experiment that was led on students and consisted of 6 phases

  1. After being asked a set of questions, half of the kids were classified as Smart and the other half as Effort.
  2. When asked to choose between a more difficult test and the same kind of test, about 90% of the Effort kids chose the more difficult one, whereas 80% of the Smart kids chose the easier one.
  3. When given a very difficult test, the Effort kids worked hard and welcomed the challenge, whereas the Smart kids were easily discouraged.
  4. When given the choice between seeing the copy of students who did better to the test, or the copy of students who did worse, the Effort kids chose the first, whereas the Smart kids chose the second.
  5. When given an easy test again, Effort kids had improved their results by 30%, whereas Smart kids had decreased them by 20%.
  6. At the end, all kids were asked to give some advice to other students and provide the score they achieved. Effort kids gave a lot of advice, whereas Smart kids did not provide valuable information and most of them lied about their score.

So where does this experiment bring us. Well, apparently, research shows that your mindset can determine the way you learn, the way you react to success or failure, and your general attitude towards new challenges.

With what Linda calls a Fixed mindset, people tend to be static, to avoid challenge. They believe that people who need to provide some effort to achieve their goals show a lack of talent, but turn out to be helpless when challenged.

On the other hand, with what Linda calls an Agile mindset, people like to learn new things and improve, they welcome being challenged. They think that you can learn from your failures and are more resilient.

This keynote was based on the research of , a psychology professor at Stanford University. It’s really surprising how this keynote converges with the one given by Dr. Fredrickson on the second day of the conference. It’s even funnier when you know that during breakfast, Linda confided that she did not know Dr. Fredrickson before the conference, but was interested and amused to discover that their keynote topics were so complementary.

Linda continued speaking about something apparently dear to her heart : Bright Little Girls. According to Linda, there is a good reason why there are less women than men in software development (even though the feminine attendance was quite important at Agile2011). More generally, there is a good reason why women are less prone to end up getting a high responsibility job. Since they are little, we tell little girls that they are bright, that they are perfect, that everything they do is good. On the other hand, we ask little boys why they are so messy, why they can’t be more like their sister. Doing so forces girls into a Fixed mindset whereas boys tend toward a more Agile mindset.

The good news is that this mindset is not carved in stone or hard-wired. You can change it. When asked

How can you changed someone’s mindset ?

Linda answered

Well…. you don’t ! You can only create the right environment, to allow people to change their mindset.

The important thing to know is that, as parents, we have an influence on the mindset our children develop. Teach them that making efforts to reach a goal is a good thing, that a failure is a chance to get better, that they should seize any occasion to learn. “Always be the worst guy in every band you’re in”, right ?

In Agile software development, we learn that failure is a option. We learn to fail early and fail often. Linda quoted a great sentence by Kent Beck

Perfect is a verb

She then explained that an Agile mindset gives us the opportunity to get better at what we do. Continuous improvement is part of the Agile mindset and like good wine, we shall continue to improve with age.

Linda finished here talk by another quote, of Samuel Beckett

Try again, fail again, fail better

This quote and the rest of Linda’s talk, her skills as a speaker and her wit led to the first and only standing ovation I have ever seen at a conference.

Since the very first day I met that woman, I have been nothing but impressed by her knowledge, her kindness and her humor. I did not dare to tell her face to face, so I use these few lines as an occasion to testify of my admiration for her. I am just about to read Fearless Change (currently on top of my book stack) and I can’t wait to read her.

As far as I am concerned, this post concludes my series about Agile2011. I can only hope that the videos of the conference will be online soon. According to the last newsletter I received, they should be during the month of October. Be assured that I will post a link as soon as they are, that way you will be able to see Linda’s session by yourself.

Cédric Pontet

Cédric Pontet is a seasoned Lean and Agile practitioner, with more than 13 years of experience in software development. He really started focusing on Agile project management when he joined Agile Partner. Since 2005. Cédric has been involved in sizable projects, for several customers in sectors as various as "notaries" public sector, intellectual property management, banking & insurance, or post & telecom. He has been working on these projects first as a developer, and then as an architect and a team leader, gaining more and more experience and agility, while always keeping an eye on technology evolutions. Lately, Cédric has been spending more time coaching teams to start their agile transformation, evangelizing Lean and Agile values, in Luxembourg and its neighboring countries, not only for software development but beyond.

No Comments

Post a Comment

Comment
Name
Email
Website