5 SPA Conference takeaways that could make us better software professionals

4 minute read

Last week, my colleague Ahmad Atwi and I went to the London SPA Conference to give our Remote eXtreme Practice talk.

The London eXtreme Programming is one of the most active in the world. You could feel an XP atmosphere at the conference. For example, people like Nat Pryce and Steve Freeman, authors of GOOSGT book were speakers.

The cover of Growing Object-Oriented Software, Guided By Tests

To summarize, we had the chance to attend a lot of very interesting sessions during the 3 days of the conference. Here are 5 pearls of wisdom I took back with me.

What connascences are

Identifying code connascences helps to rank refactorings and keep the system maintainable.

Continuous refactoring is one of the core practices of XP. For me, knowing what to refactor next has been a matter of code smells, discussing with my pair and gut feeling.

A connascence is a coupling between parts of the system. Two parts of your code are connascent if changing one implies changing the other. For example, a function call is connascent by name with the function definition. If you change one, you need to change the other.

Connascences are more formal than code smells. We can detect and rank them to pick the most important refactoring to do. People have listed 9 types of connascences. Some are visible in the source code, others are dynamic and difficult to spot before runtime.

The lowest form of connascence is ‘of name’, like in the function call example above. The worst form is ‘of Identity’, when different parts of the system must reference the same object.

The higher the connascence, the more difficult it is to evolve the parts involved. Instead of relying on intuition, you can use a connascence based refactoring algorithm :

  1. Detect the highest connascence
  2. Reduce or remove it
  3. Repeat.

Thanks Kevin Rutherford and Adrian Mowat for your Red Green then what ? session about connascence.

Tips for pairing with junior developers

Irina Tsyganok and Nat Pryce gave a very fun session about this topic. A lot of valuable points discussed, from which I saved a few pearls of wisdom.

It was reassuring to hear Nat saying that “As we gain experience, we are not expected to know everything”. Pairing with developers out of college is an occasion to “exchange” skills. Hard learned design skills versus updates on the latest technologies.

I also learned about the Expert’s Amnesia and why experts often have a hard time teaching. Expert level knowledge is by nature instinctive. At this level of skill, it becomes very difficult to detail the logic of things that seem obvious.

We engineers are more mentors than coaches

In the first XP book, there were only 3 roles in the team : team members, on site customer and XP coach. The XP coach should be a developer who can help the team to learn the practices and principles of XP.

About the same time, the personal or professional coach jobs appeared. The Scrum Master, is to Scrum what the XP coach is to XP, without the developer part. Remember the joke “Scrum is like XP, without everything that makes it work” (Flaccid Scrum).

It looks like the Agile Coach job title appeared out of all this. The problem is no one exactly knows what this is. Should he be an experienced developer like the XP coach ? A great people person ? Or someone good at introducing change ? or a mix of these ?

Portia Tung and Helen Lisowski ‘s  talk “The power of coaching” clarified that.

There is no knowledge transfer from the coach to the coachees ! On the other side, a mentor does transfer knowledge to his mentees. The coach helps his coachee take a step back and take decisions in full consciousness. The goal of the mentor is to inspire and train to new techniques.

I’m fine being a mentor and not a coach ;-)

Servant leaders need to be tough at times

We hear a lot about servant leadership nowadays. Scrum Master should be servant leaders, as well as managers in agile organizations.

Angie Main gave a very interesting session about servant leadership. She made an interesting point I had not heard about before. We all know that servant leaders should trust the team to get the work done most of the time. In spite of that, servant leaders must also be ready to step in and remove people who don’t fit in and endanger the team !

This reminded me of what Jim Collins says in Built to last : “People who don’t fit are expelled like viruses !”

The cover of Built to Last

1/3000 ideas succeeds

Thanks to Ozlem Yuce’s session, I learned about the “Job To Be Done” technique to understand the customer’s real needs.

Studies measured that only 1 idea out of 3000 ends up as a successful product ! Here seems to be the original research.

I’ll remember this fact next time I’m ask for a funky feature !

To conclude

At the end, we had a very good time at SPAconference. The talks were insightful, we had interesting discussions, the premises were comfortable and on top of that, food was great !

I’m already eager to go to SPA conference 2018 !

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment