Post navigation

Back to the Technical Stuff (or “Why so Quiet Cap’n?”)

A recent entertaining high point was this photo of Alberto Brandolini‘s (@ziobrando on twitter) lightning talk at XP2014 going viral. It’s still doing the rounds on twitter 2 weeks later so if you’re here because of “that photo”, thanks for stopping by and don’t forget to congratulate Alberto! Sadly most of the content on here – whilst hopefully interesting and insightful – probably won’t have the same mass-appeal. Back in the day-job, I have 3 irons in the fire at the moment.

Build & cycle time

Agile staff development

Rebuilding my “developer empathy”

Build & Cycle Time

I’m working with two of the function heads at Red Gate on a project to improve our build and test cycle times. Chris and Jeff are doing all the hard work directly with the teams, I’m just offering support, guidance and occasional prods.

In the last 6 weeks they’ve managed to reduce the amount of processing on our build servers for one of our major products from 56 total hours (requiring a total test run duration of nearly 15 hours) to 10 hours processing, ~30 minutes total run time and a build time reduction from 40 minutes down to 6.

At the same time they managed to get all the tests back to green and fix the hidden bugs they were masking (just 3 luckily). Somewhat embarrassingly, this was a first in over 5 years). This has had an amazing positive effect on team morale and Chris’ visualization of status has really upped the game for all teams in the division. The team’s best run so far without a broken build or failing tests was a week but this time when things failed, they were fixed and re-tested in under an hour, not left for the next “overnight”.

That’s a major shift in behavior for us and means we can now be much more responsive in turning around customer issues too. The knock-on impact of this on all other projects is probably even greater.

Other teams are benefitting from a build queue that actually has free slots during the day (previously unheard of) and overnight runs that are significantly quicker due to the reduced load on infrastructure.

This is all part of a major push by our team to crank up the effort on our technical issues here. We’ve got agile project processes running to a level where we’re happy and continuous improvement is culturally part of every PMs daily life but we’d not focused on the technical side, XP practices and development culture so much. Until recently our teams had done “pretty well” with brute force and intellect but many hadn’t seen what “really good” looks like for a while. We’re fixing that :)

Agile Staff Development

This is where most of my time’s been going. I’ve been working closely with Brian, our head of Tech Comms to roll out training on our new “personal development planning” workshop and tools to all our line managers in development. This is the culmination of the work I wrote about back in September last year following a successful pilot.

We’ve overhauled the skills part of this area as a team with some great design assistance from our head of UX (Marine) resulting in a skills map for each of our main development roles.

We’ve developed a half-day training course where participants explore the materials and gain a deep understanding of the concepts, goals and challenges and then actually do the personal development workshop itself as deliberate practice – with one participant leading and one participating – before unleashing their new skills back with their teams. We’re documenting much of our work at http://dev.red-gate.com/skills/ and have made our internal skills maps available under an open source license for others to adapt the concepts for their own use.

We’re now at the point where all development line managers have been trained, about half of our development staff have development plans (and are actively tracking and maintaining them) and we’re now looking at how to both make this scalable, sustainable and expand the next phase of the project to cover non-development roles.

There’s been a real buzz about the skills maps in particular outside Red Gate so we’re hoping to take these concepts out to a couple of conferences toward the end of the year.

Rebuilding my “Developer Empathy”

Related to our technical push around the build and cycle times, I found that after too many years away from the technical coalface I was becoming somewhat jaded towards what I perceived as a lack of technical discipline from some of our developers. I needed a mental reset. Starting out with the premise that we hire great, motivated people who care, I needed to understand what it was that would make someone with the best of intentions fail to write and maintain unit tests, develop poor quality architecture and allow a codebase to fall into disrepair.

You see when you look at it like that, something else must be amiss.

Rather than simply looking, I’ve decided to do it myself. So in the last few months, in early mornings, lunchtimes and evenings I’ve taken up (simple) coding again. I’ve taken a domain I know well (text adventures) a project I knew I’d enjoy (writing a new game) and started deliberately building up a legacy codebase. Whilst trying to use at least some basic object concepts (in JavaScript), I’ve not used SOLID principles or composition (In my former Java life I generally avoided inheritance in favor of interfaces/composition), I haven’t written tests first and I’ve written some quite complex methods without tests.

3 months later I have a rather neat game and engine, a nasty codebase. 150 tests (all passing) where I should realistically have more than 1500 and amongst the full set of classes, a small number of 1500+ line “god classes”. I found myself repeatedly “play testing” new features rather then writing tests, blurring the boundaries of responsibility across objects and occasionally rushing work so that I could “get home” or switch back to my day-job.

I’ll write about this in much more detail in future (and will try to find somewhere to host the game) but in summary, I’ve reconnected my empathy circuit. There are many reasons why we don’t work at our best on legacy codebases. I don’t always know how we get there in the first place but I can see why we fail to dig ourselves out.