The Living Room Architect

This isn't a new insight into software engineering but it's one I've been reminded of recently and not everyone knows about it or at least not everyone remembers to apply it.

"If it hurts do it more often"

I don't know if Martin Fowler coined the phrase but he certainly talks about it here and a google search reveals loads of blog posts about it. If you know who originally coined this phrase or how it came about as an insight into software engineering then please let me know via the comments section below.

I find it is really useful to consider this rule whenever anything on our software projects is painful. No matter what it is. It seems counter intuitive at first but there have been too many projects that have failed or had a stressful last couple of months because they've left something painful until the last minute like testing or integration.

In our case we are planning our approach to a project which will involve integration of our software components with hardware and software components developed by different teams. The answer here is fairly obvious. Instead of integrating with other teams once every two or three months we really need to be doing this much more often. Even integrating once a month is going to be much more beneficial than every three months, especially in a project which will take about a year to complete.

We should also be finding ways to automate a suite of integration tests and running them every time someone checks-in any code in, or at least overnight if the tests take a while to run. Although the developers on the project will be writing unit tests via TDD, integration tests and acceptance tests we really need a single person dedicated full-time to the automation and implementation of a full suite of integration tests across all of the teams and all of the components.

If we don't have a software engineer with testing experience and a testing focus to start working on automating the integration aspect of the project from very early on in the project then the pain of integration will be delayed until the end. That will then cause the project to slip past it's due date and we would only know about this slip right at the very end of the project where it's too late to do anything about it.

Please leave a comment if you've either seen projects fail because they didn't do something that hurt more often or succeed because they did do something specific more often.

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!