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.

 

Advertisements

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 ūüėČ


My friend and colleague Wayne Grant¬†posted an excellent blog/summary of his experiences at Lean Agile Scotland 2012. I was there too and this spurred me on to finish writing about what I got out of the conference too. I’m trying to describe the thoughts I had about some of the talks rather than summarising the content (if you want a summary of the content, check out the Schedule on the link to the conference above), so please let me know if you think I’ve completely missed the point on any of them.

TDD

Common Objections to TDD
As I’m running TDD workshops myself, I felt that I had to attend the two TDD talks just in case I was missing out on any new thinking on the subject. First up was Seb Rose (@sebrose) with¬†Common Objections to TDD (and their¬†refutations). Seb had run a survey on the web gathering objections to TDD and this was an entertaining walk through them followed by discussion of why it was or wasn’t a valid one.

I found it very interesting in Seb’s results, that of the teams claiming to “be agile”, only about half were¬†using¬†TDD. I consider TDD to be core practice and apply the principle to many things outside of software development too as it brings me focus, forces me to ensure I have a good understanding of the task at hand, and provides a measurement of success afterwards. For example, if I’m about to make a phone call I often think of a test-case to describe the call:

  • My car will be booked into the garage…or my team will get to work on a new project

This sets me up for the call and during the call I can refer to it to make sure that it’s moving in the right direction or if I’ve become distracted/side-tracked, I can steer it back around. When the call is over I have a very simple check to see if it was a successful call or not. Maybe I take these things too far, but it works for me as I’m easily distracted.

TDD Pitfalls

The second talk on TDD was Brian Swan (@bgswan) with TDD Pitfalls. I’ve know Brian for some time and didn’t think there would be too much contentious material in his talk but I was motivated to question “Tests as Documentation” as a pitfall.

I don’t like comments in code for a number of reasons, but the biggest one is that they are always out of date. Well, that’s not true…but it very quickly becomes the case in a changing code-base and there is no easy way to tell, so I assume they are…and more often than not, delete them. For me, when I want to understand what a class does and how it should behave, I always read the tests first and find good value in that when they are written well.

I think what Brian was getting at in his talk was that it is very hard to write tests that clearly ¬†describe the¬†behaviour¬†of the class…and forcing yourself to do that is the pitfall, and I’m thinking that he might have a point. It’s very easy to expend a lot of effort trying to achieve this and when you look at the code you still, eventually (I’ll still read the tests first) end up reading the implementation.

BDD

BDD: Busting the Myths

Related to TDD, there was BDD: Busting The Myths with¬†Gojko Adzic (@gojkoadzic)…and if there’s an award for most entertaining talk of the conference, Gojko wins it easily. My exposure to BDD has always been at arms length and been dominated by people showing off how clever the tools are. I’ve never been convinced of it’s value because of this exposure, but have always felt that I was writing off something that could be¬†immensely¬†valuable.

What I took away from this talk was that, as I’d suspected, the tool was just a distraction. BDD is all about facilitating the conversation between the customer and the¬†implementer. That there are some tools to capture this is merely a convenience and I don’t think we’ll ever get to the state where the customer can just turn up with a set of BDD tests (am I even allowed to call them tests?) to hand to a development team.

The conversation is where all the knowledge about the work/story/feature comes from and BDD tests are used to steer that in much a similar way as TDD focuses code and makes you ask the questions around behaviours.

The big revelation I had was that these BDD tests have a much shorter shelf-life than I had imagined. While talking about the costs of maintaining large BDD suites, Gojko was discouraging their use for regression testing of applications (well, certainly using them verbatim as the regression test). I had always struggled to imagine the customer truly owning the tests and maintaining and updating hundreds of them over the life of the product. By suggesting that the most value for them is in the initial implementation and perhaps not maintaining them further down the line seemed to make them much clearer and usable/well defined in my head.

End of Part 1

So that was Part 1, I hope it wasn’t too rambling and that perhaps you even found it interesting. In Part 2 I’ll be talking about People, Kanban, and Rightshifting and some new things I’d like my team to try out.