#SGZA 2016: “Taming the Beast”

I recently attended the regional Scrum Gathering for 2016 in Cape Town. This is a post in a series on the talks that I attended. All posts are based on the sketch-notes that I took in the sessions.

As we’re also looking to move a very complicated, fragile system over to a new technology stack, I found this talk by @NigelBasel quite interesting. One of the most interesting parts was his application of Conway’s Law to the problem: the software had evolved and modeled when there were only a handful of developers working on the system; and now it needed to change to model the communication structures required between a number of teams working on the same codebase. He also showed us the output from a really cool tool (I think) called Gource which he’d used to model changes in their source code repository over time. Made me wish I could see the same animation for ours! I’m sure it would be fascinating!

Nigel gave a suggestion of two steps one could take when faced with this legacy code-wool problem:

Stop digging (yourself into the hole)

Get out of the hole (carefully)

They’re still progressing on their journey, but these are the steps they’ve taken so far to try and bring their code base back under control:

They identified and fixed any coincidental cohesion – they moved parts of code which logically belonged together and just happened to be where they were because they were written into things like libraries and services.

They shifted their thinking of layers to services and considered things like whether certain services like authentication be provided by 3rd party tools and removed from their code base. If a service seemed to make sense, they created it and then migrated functions as they were needed, thereby “starving” the old code base.

The considered their code base in terms of business features and the data required and tried to group these together

They write all their new code using their new strategy (as far as possible)

One issue Nigel admitted that they haven’t really got to grips with yet was version control. He emphasised that their journey is not yet done. I’m hoping we will hear more about their adventures and learnings once they have traveled their path. Did you find any of these points helpful? Do you have experience changing old code to reflect new organisational communication patterns?