June 13th – Introducing Extreme Programming
It’s our birthday – comes around quick doesn’t it? Now 3 years old XPManchester is almost ready for pre-school. We’re potty trained, walking, talking and well past the dribbling stage. Well, most of us.
As is tradition for our birthday we’re running an introductory session, covering the basics of XP. This year, we have a couple of twists.
First, we’re running this session in conjunction with Manchester Girl Geeks.
Secondly, as well as explaining the basics of XP we’ll also discuss how to introduce the practises to your organisation or to your boss (Introducing XP, geddit?)
This is a (free) ticketed event again, please grab yours from Eventbrite.
6:30pm Madlab, Edge St.
Thoughts on the legacy code session
For those that know I’ve been running legacy code workshops for the last few months at users groups that have been kind enough to hear me witter on. I’d volunteered to do our session on legacy but in the spirit of collaboration I got two wonderful collaborators (Ian Haworth & Dan Smith) to help. This was fantastic as it wasn’t just my diatribe but was peer reviewed by others. Whereas my solo sessions covered topics such as:
- attitudes to legacy
- characterisation tests
- scratch refactoring
- understanding though story telling
It was agreed by the team that we were putting too much into a session. Ian had been to a session run by the on the Gilded Rose kata. This had a much more focused scope than my session. I’d seen the kata before but never attempted it. During my preparation I had a bash and used the characterisation technique above. When I got back together with the session team it appeared I’d not followed Ian’s guidance properly. He wanted us to use a specific technique, the Golden Master.
Golden Master
Like all good ideas the Golden Master is an obvious one. Probably the one you say in your head before you refactor any legacy code, “I want the outputs to be the same as before the code was changed.”
Here’s how Sandro describes it:
The Golden Master approach
Before making any change to the production code, do the following:
Create X number of random inputs, always using the same random seed, so you can generate always the same set over and over again. You will probably want a few thousand random inputs.
Bombard the class or system under test with these random inputs.
Capture the outputs for each individual random input
When you run it for the first time, record the outputs in a file (or database, etc). From then on, you can start changing your code, run the test and compare the execution output with the original output data you recorded. If they match, keep refactoring, otherwise, revert back your change and you should be back to green.
So with our version we took a run of 30 degradations in quality. Including the effects of the new requirement. (I forgot to mention there’s little value in changing code that doesn’t have to be changed).
With the current crop of supported languages with the kata there were a few missing. I cobbled together a javascript version but Ben Nutall deserves a mention for contributing a PHP version.
The Gilded Rose
The Gilded Rose kata is a shop based around something you may find in World Craft. Classes*(HINT)* of items degrade in different ways. The code is written in such a manner that it is a challenge to make a change safely. Your mission is to make the change and hopefully make the code better.
The groups attempts
The group spent longer than I would have thought on cleaning the code to understand it over refactoring to find a solution that I would have expected. Part of this I put to down to blind pairing (new pairs tend to talk more to try and understand each other better) but perhaps we as facilitators didn’t move the session forward as quickly as we would have wanted. In my mind the solution jumps out as a particular design pattern although in our retro no one volunteered that. Again I think that a short timescale makes developers panic. I think 3 out of the 18 groups got the solution completed. This, for me, illustrates that there is a huge cognitive challenge to doing things the right way where legacy is involved.
The group responded favourably to the golden master. It provided an adequate safety net for the pairs to develop against. In the retrospective we discussed the risk that any randomness in code may render the golden master useless. These factors should be taken in to consideration before using this method. There was much discussion on how far to go and that we as developers refactor beyond what is economically valuable.
Coverage
For me, the big lights on was appreciating coverage as a valuable metric with legacy. In the way I approach testing I shy away from coverage obsession. I posit that 100% coverage is a waste of resource and that my feelings are that testing every possibility lends its self to brittle code. However with legacy the golden master should be cover all boundaries where simple characterisation tests many not understand the boundaries to cover all eventualities. These outside tests are essential if possible in my opinion.
The evening
As a session facilitator this was an excellent evening. It’s great to see devs chatting and enjoying hacking together solutions. It seems that people had a great time too. Thanks everyone and see you at the next one.
Ps:The book
Finally if you’ve never read it, buy the book. Working Effectively with Legacy Code is still one of the best books on writing robust code out there.
Session PreReqs for Crushing Legacy Code session on 9th May
Please note that due to previous events being full we have used Eventbrite with this one. Please don’t turn up unless you registered there.
It’s just over a week to go until the next XPMan. Just a few things I’d like to let you all know before the event.
This is a practical session so laptops will be required.If you don’t have one though don’t worry as we pair up and I’m sure there will be enough to go around.
The code we will supply covers the following languages with the following prerequisites:
- Java
- Python
- C++ (requires C++ compiler like gcc and GTest)
- Ruby
- C#
- C (requires C compiler and CppUTest)
- Javascript (requires an HTML5 compliant browser)
9th May Crushing Legacy Code practical – ticketed event.
The next XP Manchester session is a Legacy Code practical session on the 9th May. The evening will be facilitated by Ian Haworth, Dan Smith and yours truly John Nolan. We’ve had a great problem over the last 2 sessions; more of you have been attending. Practically we can’t fit as many in if we do a hands-on session. So as a trial we want people to sign up using eventbrite, http://www.eventbrite.com/event/6306032513.
The session will be as language agnostic as possible. We have solutions for at least Java, c#, ruby, js, smalltalk & python.
As usual we are at Madlab kicking off around 7.02. Reprobates can be found in Common from 6ish.
Slides from the What is (the point of) architecture?
Thanks to everyone who attended the last event, we’ve had a great turnout for the last two. Thought it would be useful to post the slides from the event on the blog. Additionally wanted to say a bit thanks to Chris and Mark for running the event. You can read more of Chris’ musingings on his blog. Mark runs HedTek a small but perfectly formed software house in Manchester.
April 11 What is (the point of) software architecture? With Chris Carroll & Mark van Harmelen
Our next XpMan is on software architecture with Chris Carroll & Mark van Harmelen
Part I: What is (the point of) software architecture?
- defining, calculating and generally getting a tangible grip on software qualities / NFRs like reliability, resilience, availability, performance, testability, maintainability, security, usability, efficiency and other such not-always-well-defined things.
- a brief history and what’s trendy or useful in architectural views & viewpoints
- Calculating, estimating, validating, quantifying, risk-assessing and generally putting numbers on everything.
Part: II Discussion
When do you pay attention to architecture and get the drawing board out? For what scale of system? Using what notation? What happens to your architectural descriptions over time?
Common Bar from 5pm
Talk starts at 7pm in Madlab (but open from 6:30)
March 14th – Domain Driven Design with Iain Mitchell
@iainjmitchell will be talking us through Domain Driven Design this month…
We write software for people, yet we fill our code with clever abstractions and helper methods. What if we wrote code that reflected the problem domain? Surely that’d be a good thing?
This talk is an introduction to Domain Driven Design, which is a set of building blocks to write more domain focused software. There will be a practice session too, but laptops are not required.
Common Bar from 5pm
Talk starts at 7pm in Madlab (but open from 6:30)
