Goodbye Martin

May 20, 2019


I lost a good friend this weekend. On Sunday morning I discovered that Martin Burns had passed away suddenly. He leaves behind Lucy and his children, and I can’t comprehend their loss or what they are going through just now.

Martin was always brimming with enthusiasm and encouragement for others. Whether it was drumming up participants for workshops, being trolled about my political views in one of his conference talks, or jamming while he played some (much under-rated) guitar, he always had time for other people and tirelessly made sure everyone else was happy and comfortable.

This morning, I shed a tear in the car when I heard Annie B Sweet’s cover of Take On Me (originally by A-ha). On top of her sickly sweet vocals, there is the lyric “It’s no better to be SAFe than sorry”.

This is just the sort of thing that would have me messaging Martin: an obscure song lyric, an interesting alternative of something well known, and a comment about SAFe because he’d have known I was trolling him and just using it as an excuse to chat…except those conversations won’t be happening any more.

We won’t be having any post-conference jam sessions, we won’t be co-writing any talks with musical interludes that we never quite got round to, or even taking him on a motorbike tour. These are all things I thought there would be plenty of time to do, but those opportunities have passed now…and I am upset that I didn’t take them sooner.

I’m not big on morality tales or schmaltzy endings tacked on to the end of TV shows or films, but I hope in the future I will not put things off so much and commit to participating in more activities.

Goodbye Martin – it was a privilege to know you, and you will always live on in our memories and bring smiles to us when we think of you.


This year I will be presenting again at Lean Agile Scotland. This will be a case study of the 18 months I’ve just spent putting together and running a mob programming team. It’s been a huge amount of fun and I can say without a doubt, it’s the best software development team I’ve ever been involved with.

You can read the full abstract here. I’ve got a post-lunch slot on the 2nd day (4th October) so if you want to sit back and let lunch digest while I tell you all about it, this might be a good session for you.

 


On Friday 11th September, I was at Code Craft Conf (@codecraftuk) in Glasgow facilitating a Guided Conversation on Test Driven Development. It was a great event and I hope it becomes a regular fixture in the calendar. Many thanks to the organisers.

Here are the 12 questions I planned. We didn’t get through them all, but we did have many entertaining discussions over the session:

* Why do we test/why do we test first ?
* Where does TDD add “value” ?
* How does test “value” vary over time ? (life-cycle from writing test first to it becoming part of the regression pack)
* When is TDD not appropriate ?
* What’s are the qualities of a good test ?
* Do you have to be strict about test types? Unit vs. Collaboration vs. Integration etc.
* What is the hardest things about TDD ?
* How do you determine the right ratio of test types ?
* Do you care about code coverage ?
* What stops you/others from practicing TDD ?
* Does TDD have an effect on team dynamics ?
* Can you prove that TDD delivers software more effectively than other methods ? (soliciting real stories & comparing “war stories”)

I’d be interested in your thoughts on any of them…might even motivate me to blog more 😉

Lean Agile Scotland 2013

August 11, 2013


I’m speaking at the Lean Agile Scotland conference on the 19th/20th of September 🙂 The subject is SOLID TDD and the abstract is below.

SOLID TDD

Software developers generally don’t write poor, unmaintainable code out of any malicious or deliberate intent. They do it because software development is complex and there is not enough feedback in the process to ensure they adhere to good SOLID OO principles. By using TDD, and listening to the feedback from the tests, you can be guided to adhere to the SOLID principles…resulting in improved TCO and significant quality improvements.

Lean Agile Scotland

It’s a really good conference with a wide variety of speakers. I enjoyed attending so much last that I proposed a talk this year and wrote a two part review of the sessions I attended in 2012 (part 1, part 2). It’s being held at Our Dynamic Earth in Edinburgh and you can check out the list of speakers here. I’ll hopefully see you there…and if you post a comment I’ll see if I can get you a discount code 😉


Martin Fowler states that the first law of distributed objects is: don’t distribute your object. I think that the same applies to distributed teams. Co-location just makes things easier and distributing people makes it all much, much harder. However, sometimes, for reasons outwith our control, you end up with a distributed team.

I’m hoping to catalog some techniques I’ve used to run distributed retrospectives (and possibly other activities like stand-ups, planning, pair programming, etc) in a series of posts under “Distributed Team”. It’s not an in-depth study of the retro techniques, rather notes and observations on how well they worked with a distributed team (and what changes can be made to help).

Why? Well I’ve been working on distributed Agile teams almost exclusively for the last 5 years and have tried many things to make the team feel more inclusive, work better together, and ultimately be more effective at delivering software. Some of these things worked well and I’d like to share them.

Sailboat

I like the Sailboat retro technique as it’s very good at gathering data and quickly grouping it. It is also fairly simple to understand, requires minimal preparation, and overall is a great introductory technique for teams unfamiliar with regular retrospectives.

For those of you unfamiliar with this retro technique, there is a picture of a Sailboat. It’s essentially a visual collaboration game where you place issues around it to signify:

  • Sails – what is making the project faster/better ?
  • Anchors – what is slowing down/dragging on the project ?
  • Rocks ahead – what risks/dangers are coming up?

Distributed Sailboat

I flexed my Paint skills to the max and sketched out the boat below, feel free to use it yourselves.sailboat

First off, we all dial into a conference line. We’re in a Windows 7 environment, so I ran a screen-sharing session with the Sailboat as my background (and a nice clean desktop). Using the Sticky Notes application, I would capture each idea as it was raised on a new note, then locate it appropriately over the image on my desktop.

It sounds simple, and for this technique, it worked really well. Once you’ve aligned the Sticky Notes around the boat, colouring them also helps. This is how ours ended up:

sailboat_obfuscated

Summary of tools

  • Conference line
  • Screenshare
  • Paint (or use my image above)
  • Sticky Notes

Like many distributed retro techniques, this relies on one person driving the shared screen. With a lightweight activity like this, where the other participants are providing most of the data and discussing the groupings, it’s not too much of a burden.


A few years ago I was lucky enough to attend Tom & Mary Poppendieck’s Lean Software Engineering course when they visited Glasgow. One of my colleagues recently reminded me of the assertion Mary made on that course that Test Driven Development is a minimum bar for a professional software developer to reach. With that in mind, I came up with the message below that I hope will inspire & motivate or at least catch the attention of people just starting out in this line of work (and perhaps some of those who’ve been around a while too).

What is a professional software engineer?

Wikipedia defines a professional as:

I don’t like that definition, it’s far too narrow. It defines a professional in terms of group membership and ability to generate income. If I want to have someone on my team, hire someone, those are not the top attributes I am looking for. When I build a team, I want to want people who care about quality and focus on maintaining high standards consistently…not just when it’s easy to do so.

Perhaps we should stop using the word “professional” to describe quality-focused software engineers and go for something more like “software artisans” or “craftsmanship” to indicate the qualitative attributes we seek?

What is the difference between a professional and an amateur?

I think we confuse professionals and amateurs (gifted or otherwise). I can use a hammer and saw, I could probably build a fairly basic shelter given enough time…I wouldn’t want to live in it because it would be a death trap, but it would probably be ok in the very short term to keep safe from the elements. If I wanted to build a permanent home, I’d get professional builders & architects in to do the job properly.

So how can we separate amateurs from professionals?

I think it can be summed up by the aspirations of the individual:

  • An amateur aspires to achieve perfection
  • A professional aspires to deliver very high quality results, consistently

An example

I know several very keen amateur photographers. They have all the latest cameras and lenses, they know all about shutter speeds, focus, exposures, lighting, etc. Most of them have taken some absolutely spectacular pictures. However, those pictures generally represent a huge investment in time, and more discarded pictures than they’ll ever admit to. Professional photographers generally can get a very high quality picture in a fraction of the time and their pictures are generally of a far more consistent quality. This is because they have mechanisms and practices in place to govern the quality of their output. Sure, there might not be as much free expression in their work as in an amateur, but that is most likely the nature of the pictures they are being asked to capture, rather than taking pictures of whatever you like, whenever you feel like it. I think that the same is true in software development.

Low Barrier of Entry

The barrier of entry to software development is very low. This means there is a broad spectrum of quality across the industry. I recall being about 7 years old and getting the computers in Tandy to display my name, infinitely scrolling across the screen. I can write a program, does that make me a professional software engineer?

When I was a student, I wrote some MS Access and VBA front-end to manage stock and re-ordering from suppliers. I earned money from that, which I lived off of. Does that make me a professional software engineer?

A long time ago I passed my Java Programmer Certification, my degree also qualified me for some kind of partial membership to the British Computing Society (can you tell that I’m not overexcited by that?). I’m a member of two professional groups, does that make me a professional software engineer?

We need a culture of quality, we need to be software artisans.

Becoming a software artisan is not about ticking a few boxes, reading a book, getting your code to compile, then declaring it to the world how wonderful you are. It’s a journey that starts with a sometimes difficult realisation:

  • You are not the world’s most clever software developer
  • You are probably not even in the top few percentile

That’s OK, you are in the majority. That doesn’t mean you can’t be a good software developer, it just means that you need to work at it and adjust your attitude for learning. Understand that you are not perfect, and introduce good practices and checks to ensure that you are producing a quality product…rather than just banging away on the keyboard until it “seems to work”.

Test Driven Development is exactly the sort of process that can raise the quality of your code dramatically, at the same time as reducing the chance that it won’t work. People make mistakes, quite often silly mistakes, sometimes more complex and subtle ones. If you’ve crafted your test before you start coding, then you’ve got a clear, black & white (green & red?) indication of whether you have made a mistake or not. It provides you with confidence to try out different design patterns and refactoring. TDD is a software developers safety net.

Following the SOLID ideas around writing good OO code, that’s something else that can raise the quality of your work. It will make it more robust, easier to use, more readable/less confusing, more amenable to refactoring, and various other positive things. However, you have to remember to follow those ideas with all the code you write. TDD guides you in the direction of the SOLID ideas because the further away from them the code is, the harder it is to test. A difficult test is an indication, a code smell, that the code under test might be able to be refactored/redesigned to be more easily testable…and that very often involves making it more SOLID.

TDD, it’s not just a good practice, but it enforces other good practices too!

Learning TDD

I’ll not sugar coat this, TDD is hard to learn without lots of practice. However, the same can be said of any worthwhile skill. I like to think of it like riding a bike. We can all agree that travel by bike is faster than walking…but not the first time you ride a bike. No, you get grazed knees and bruised elbows as you fall off, but gradually you stay on for longer and longer and it eventually becomes second nature and you start to achieve your potential.

There is a great ring of truth to the rule on 10,000 hours of practice leading to mastery of a subject rather than some innate talent. There are some practices you can do to cut down on that time that I’ll steal from a rather good infographic.

  1. Get a coach
  2. Surround yourself with like-minded individuals
  3. Build expert habits
  4. Don’t waste time on the small stuff
  5. Deliberately practice (not just mindless repetition)
  6. Teach others
  7. Find someone to kick your butt if you fall off track

I reckon I’ve clocked up at least my 10,000 hours of TDD, and I’m STILL learning new and better ways to do it.