The Living Room Architect

Pairing with Jason Gorman a few days ago reminded me of something we all need to keep at the front of our minds. I still have a lot to learn about programming! I've spent quite a bit of time programming on my own recently and with my team but it wasn't until I sat down with someone more experienced that it really showed how much I have to learn. It reminded me of one of the core requirements of being a software craftsman and of becoming better at anything and that is to practice, practice, practice.

We also need to practice with people who are better than us. We don't get better at anything unless you practice and just practicing on our own or practicing with the same people all the time isn't enough. If we are only ever practicing with our seven year old brother who is learning Java then we feel like experts but we're simply a big fish in a little pond.

The idea of practicing is explicit in the Software Craftsmanship Manifesto as well as building a community of professionals. So from today I'm making a resolution to practice more, practice on my own, practice with members of my team and practice with people outside my team! So if you'd like to pair with me on anything please get in touch. I have also resolved to start running coding dojos for my team and to get people from outside of our department involved where it is appropriate.

Learning to develop software is quite like training for a competition and training to get fit.

I used to swim competitively and also became a qualified swimming coach. Think about members of your software engineering team while reading through the following paragraph.

When you train for a sporting event you train to be the best in the world. To be the best in the world we need to be able to compare yourself to others and to do this on a regular basis before the main event. Athletes do this in a number of ways. First we join a competitive team who we train with every day giving us the opportunity to compare ourselves to and practice with members of our team on a very regular basis. If you're lucky there will be members of your team who are better and faster than you and that will inspire you to become better at what you do. However, most people who are any good will find that there isn't anyone in their team with the same speciality who can keep up with them. That is why sporting teams hold many different events during the year. An athlete will attend 10-20+ competitions every year to practice and measure how good they currently are compared to athletes who are currently competing. These events are a great way to learn from each other and to highlight areas that we need to improve on.

Back to software engineering, one of the things that concerns me is that a lot developers are scared to show others their code in case it draws criticism. This causes an environment where developers are overly protective of their work and the parts of the code base that they have created. It can even lead to developers being unwilling to delete code they have written because a lot of effort went into creating that baby in the first place. We've got to get over this.

If you are a developer, like me, who wants to improve then we need to practice. We need to practice with people who are better than us and we need to practice with people outside of our teams. We also need to admit that we have a lot to learn and become very good at taking and giving constructive criticism.

So how about it? Want to put your money where your mouth is and show us your code?

I helped run Software Craftsmanship 2009 in the BBC Media Centre a few weeks ago. It was a really thought provoking day where many of the well known master craftsman in the software industry exchanged ideas, taught and discussed what it means to be a software craftsperson.

I started the day helping Jason Gorman and Peter Camfield setup and have to congratulate and thank Jason for organising a very successful day! Also many thanks to Robin Doran who helped massively in getting the logistics of the day sorted.

Jason put together a load of references to other blogs and materials from the talk and a really good summary on Kerry Buckley's blog.

The following are some of my notes and thoughts on the sessions I attended.

Programming in the small: Ivan Moore and Mike Hill.

This was my highlight of the day where Mike and Ivan facilitated a hands-on coding session with the group of about 50 of us. They gave us some example code and asked us to pair up and "show it some love". After 10min of reviewing and refactoring we were asked what we'd done and why. They would then summarise with their main points and repeated the process with two different code examples. Their slides and Ivan's blog contain some really great advice for anyone writing code. Two of the main points from the workshop really stuck in my mind.

• Removing even the smallest amount of duplication in your code is worth it.
• Readability is extremely important to the modifability of your code.

Other smaller points from my pairing sessions were.

• Your tests must be easy and fast to run everywhere, otherwise refactoring is much harder or you can waste time trying to get them to run.
• The Eclipse refactoring tools are fantastic, use them even for simple refactorings so that you get used to them.

Three Paradigms, Programming in a safe environment: Keith Braithwaite

I didn't at first think i got much out of this session as I was looking for clear answers to the questions he posed. His main point though was that there's no right way to answer them. It's a powerful message and also a double edged sword. It's powerful because its damaging to follow structured programming and patterns rules without knowing why you're using them. It's also dangerous because it can be used as an excuse by non-experts and experts alike to ignore some of the hard rules that are important in certain situations.

I spoke to experts on the weekend who were ignoring ideas and practices that would help them because "there's more than one way to do it". I'm reminded of my uncle here who still claims that there is no proof that smoking causes lung cancer. It seems to me that too many conversations and arguments in our industry are solely fueled by religious beliefs and not backed by scientific proof. Even when the proof exists it is ignored.

Let's hope that movements such as the recent Software Craftsmanship help us reflect on the skills required to do our job well and improve the software we write.

My Defining Moments: Steve Freeman

There's a very good summary of this one on Kerry Buckley's blog, however the one thing that struck me with everyone who stood up and spoke about their defining moments was that everyone included learning and really understanding TDD as one of, if not the defining moment of their carrer.

Final Thoughts

I had a great day and I hope all of you who were also at Software Craftsmanship 2009 enjoyed it and learned something, I certainly did!

I'm involved in helping set-up and run a new conference in London about "building it right". It's called the Software Craftsmanship 2009 Conference. The website is now live thanks to Jason Gorman who's chairing the conference and it's all systems go. Registration is free and opens on the 1st of December, proposals for presentations and tutorials are due by the 1st of Jan 2009.

http://www.softwarecraftsmanship.org.uk/

As the site says:
"This conference is all about the principles and practices, and the disciplines and habits, that distinguish the best 1% of software professionals from the 99% who are failing their customers and failing their profession by taking no care or pride in their work and delivering buggy, unreliable and unmaintainable code."

This is an area that I feel hasn't had enough focus in recent years, and Software Craftsmanship is something I'm really keen on learning more about. As software craftsmen and craftswomen we are professionals and that needs to be reflected in the software we create. I want to be sure that the software I write is of the best possible quality and this conference is a great way to learn from the experts how to do just that. It's a conference where some of the best software professionals in the world will be gathering to compare notes and share what they've learnt, so get involved.

Of course, if you are already part of that illusive 1% then why don't you submit a proposal for a tutorial or presentation and show us all how it's done... Lasse?