Archive for the ‘Technical’ Category

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.

A lot of this talk was a repeat of things I’ve heard before:

Efficient feedback increases effectiveness

We need to build things to learn things through measuring

We need to start with understanding user needs

When we define a problem, we’re usually guessing, so we need to validate our guesswork (through feedback loops) as quickly as we can

A wicked problem is a problem that one can only fully understand or define once one has found the solution to the problem. Software in a wicked problem: when we find the solution (note: find not build), then we can usually answer what the problem actually was.

One of the new ideas for me from this talk was the #ConstructionMetaphorMustFall idea. Traditional engineering models treat coding as part of the build process, however Jacques argued that code should actually be treated as a design document and that writing code actually forms part of the creative design process. The code equivalent of bricks and mortar is actually only the conversion of code to bits together with the (hopefully automated) checking process i.e. when we release. In this model, things like Continuous Integration and Continuous Deployment are actually design enablers: they allow us to test our theories and verify our design through feedback.

Shifting your mindset to view writing code as part of the experimental design process rather than execution of a final plan/design would probably lead to a paradigm shift in other areas too. I’ve been saying for a while that, as software tooling improves and more “routine” activities become automated, writing software is becoming less of a scientific engineering field and more of a creative field.

What are your thoughts on shifting the “coding” activity out of the build phase and into the design phase? What does this mean for how we should be thinking about code and feedback?

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?

Popcorn Flow

Leader Transformation

The full title of this case study was “Leader Transformation – a side effect of an agile transition”.

Key take-outs for me:

Different parties have different motives and often change driven from the top is feared or regarded as a ‘fad’ to ‘survive’.

Beware early successes- sometimes they create a false sense of confidence which leads to running before one can properly walk

Start from where you are

Mob Programming Case Study

An interesting talk on the before and after effects of having a team practice mob programming. Some of my key take-outs for if you want to try it:

Start by following the rules and then inspect and adapt.

There are some things where mob programming doesn’t work very well, e.g. doing research, where learning is not an outcome of the work, and problems that are still very large.

You need to mob program with a cross-functional team with all the perspectives (problem knowledge, testing expertise, developers, UX, etc.).

You also need to create time for team members to do things on their own i.e. not all of their day is spent with the ‘mob’. This “alone time” could be spent on things that aren’t suited to mob programming and/or other creative initiatives.

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions.

I was hoping the video for this talk would be available before I got round to blogging about it, however unfortunately it isn’t 🙂 I’ll update this post with a link once it is available, because I don’t feel my notes will really do the talk by Neal Ford full justice.

The talk kicked off with a couple of tales about QWERTY keyboards and the legacy that remains. Most people have heard of the fable that QWERTY keys are arranged to help typists type more slowly to prevent jamming (apparently not true…), however how many of us have ever considered the underscore? Sure, we use it now, because it’s there, but did it really make sense to port if over to modern-day keyboards when it was originally there to enable manual typists to underline pieces of text? Perhaps not 🙂

To Neal, anti-patterns are wolf ideas in sheep’s clothing: they are ideas that look like a good idea at the time, but sometimes turn out to be a terrible idea. He then went on to describe six practices that have potentially proven to create anti-patterns over time:

1. Abstraction Distraction

Abstraction seemed like a clever idea to black box certain functions, however as the abstraction layers increase, things become increasingly complicated and confusing, eventually resulting in so much abstraction that the code is almost unusable and people are afraid to go in and make changes because they have no idea what will break

2. Code Reuse Abuse

Code reuse in principle, is good, but it can also lead to a whole bunch of dependencies that need to be managed.

3. Overlooking Dynamic Equilibrium

Things change all the time – and they change at different paces – so it’s really hard to plan an architecture for the future because you don’t know which parts will change when and at what pace. It’s no longer possible to be predictable, so rather focus on being adaptable.

4. Dogma

“Do it because I said so” or “do it because that’s how it’s always been done”

5. Sabotage

Cowboy coding

Focusing on cool stuff rather than necessary stuff

Inventing cool puzzles to solve

6. Forgetting that some things scale non-linearly

Examples are code, teams, and tools over time.

As the size increases, the pain increases exponentially

Tools have life-cycles and Neal recommended that when you are using a tool and it starts becoming painful to use, the you should probably start looking for a new tool

Neal also recommended a book called “Evolutionary Architectures” and mentioned some key concepts to bear in mind:

Components are deployed

Features are released

Allow for incremental change at an architectural level

Embrace experimentation and remember to include users in your feedback loop

And I’ll leave you with one last thought from the talk: Is Transitive Dependency Management tomorrow’s GoTo anti-pattern?