What I learned from creating a Merge Queue

What is a Merge Queue?

When your team wants to ensure all tests are passing before their changes are merged into main/master/trunk it can be helpful to have an automated process to trigger those tests and ensure they pass before merging. A lot of Pull Request systems can do this for you with a check that the tests must pass before merging. There isn’t any reason to consider a merge queue unless the test take a long time to run. Waiting 5 minutes between updating a pull request and merging it in is usually fine but waiting a hour can become a problem. Especially when there are a lot of other people working on the same code base.

Continue reading “What I learned from creating a Merge Queue”

10 ways to talk about Agile without talking about Agile

A good friend was asked to talk to the executive management and give a brief 10 minute talk about Agile. But she was asked to not mention Agile. The context of that challenge is interesting and could hint at all kinds of good or bad reasons. But I was surprised when I saw other Agile coaches struggle with this challenge. They were drawn to talking about “Value Streams”, “Lean Flow” and “Release on Demand” but those are very Agile centric jargon that may not mean anything to someone a few steps removed from the software development. So I wanted to set myself a challenge: Ten ways you can talk about Agile without talking about Agile. Might be you want to sell someone on the value in Agile or just want to ensure you’re using a shared language. These are options you can present.

Continue reading “10 ways to talk about Agile without talking about Agile”

Chicago and London Style TDD

Chicago and London

When learning Test Driven Development eventually you’ll discover there are two different schools of thought on what those tests should look like. At that point you probably already have a favourite style (only now you have a name for it) and will go to war against the other style as clearly inferior. Indeed there are lots of blog posts out there on Chicago vs London and I did my tour of duty on that war too. But I’m calling an armistice as there’s no need to fight. We need to do both as both serve specific needs. So even if you have a favourite you need to learn the other approach and think about where it better applies. You can still have a favourite – I have a favourite screwdriver – but you should be comfortable working with either.

Continue reading “Chicago and London Style TDD”

Theories that Form an Agile Mindset

When people talk about Agile Software Development people will often cite how important having an Agile Mindset is to the success of any Agile project or team. But I’ve never heard a great definition of what an Agile Mindset is. It’s always a mix of personality traits and problem solving goals that no one can seem to precisely describe.

Part of it is clearly an Growth Mindset and that has been well defined and analysed. But it’s more than just that so I’ve been thinking about what that more actually is.

Continue reading “Theories that Form an Agile Mindset”

When Agile is Not Common Sense

It’s been about 10 years since I got my Agile training from James Grenning and started an Agile Pilot with my team. Right from the start I was super keen and got people practicing TDD and Pair Programming even though I didn’t really know if that effort would pay off. I just knew we had lots of problems with the old way so I wanted to embrace the new.

So I’d run my own little sessions with the broader team in Sydney sharing Agile concepts and ideas. Giving us a chance to discuss things and keep learning long after James had left. But often I would present new ideas and a few people in the group would respond “oh of course, that’s just common sense”. Initially I thought it was great as they were embracing these ideas as valuable even though it was not what we were doing before. But after a while I started to get frustrated because they we’re not really listening. If some small part of a concept fit nicely with their “common sense” then they took that on and ignored the rest.

Continue reading “When Agile is Not Common Sense”

Software Design Algorithms Cheat Sheet

If you have a career as a software engineer at some point you’ll be asked to diagram a software system. It might be a system you plan to build. It might be to help explain/document a system that has already been built. Or it might be part of an interview question. These days most people seem to have given up on UML and will create a wild mix of arrows, boxes, circles and words. But there’s a lot of other methods that are useful and the best results usually involve a mix. So here are the techniques I’ve found useful in a super quick way.

Continue reading “Software Design Algorithms Cheat Sheet”

Software Architecture with Tarot Cards

One of my favourite things to do with software engineers is to practice together. I like it because often we’re not trained to collaborate and it can be a difficult adjustment. If we throw people into collaborative techniques they can struggle as they try to navigate their way through the process while protecting their reputation. I’ve seen teams so nervous about suggesting a “wrong” idea that they will struggle to suggest anything when presented with a trivial problem. So I like to get teams to practice on something that feels a bit like a game.

I first got to experience an Architecture Kata at the Aglie 2018 conference in San Diego. I got to attend a workshop my Martin Salias on Architecture Kata with Tarot Cards. In his workshop we formed into groups of 3-4 and selected a kata exercise from Ted Neward’s Heroku App – we got some kind of medical advice service. We then got 10 minutes to work on our first release. The Katas ask for a lot so you immediately have to consider what to prioritise so you get that real feeling of a sprint plan being executed even though you’re just drawing out a design.

Continue reading “Software Architecture with Tarot Cards”

8 Patterns for TDD

I’ve been doing Test Driven Development for nearly 10 years and I’ve spent most of that time doing TDD with C++. There’s a bunch of things I learned early on that I still use heavily today. And some patterns I’ve come to value over time. I’m using C++ examples but I’ve applied the same thinking in Python, PHP, Javascript and Lua.

I will also include some warning smells along the way. Things that will give hint your design is not testable.

1. Dependency Injection

This is one of the first things you’ll learn in doing TDD. It doesn’t matter if you’re doing London Style or Chicago Style you will eventually hit cases where you need to swap out the real item. It may be because that real object would touch the file system, a database or a network. Or it may be because it forms a convenient seam between your code and something more complex.

Smell: Singletons and classes that new their dependencies.

Continue reading “8 Patterns for TDD”

Pair and Mob Programming for Interviews

In a recent assessment of people applying for graduate and intern positions at my work we wanted a way to quickly assess them as a group. Ideally we wanted to see their individual skill at work, how well they worked with others and all in under an hour for groups of up to five. So I suggested we get them to do some Mob Programming on a Kata exercise. It wasn’t something we tried before but the idea wasn’t completely out of the blue.

Continue reading “Pair and Mob Programming for Interviews”

Learning Refactoring Together

My team has a challenge that I haven’t run into before. We all want the code to be better quality that it is now. However we don’t agree on what “better” is.

Even simple things can lead to long discussions and debates so it was a struggle to get some serious progress. Reviews could get bogged down because a refactoring someone did triggered a debate on its merit. We needed a format to allow us to work through some of the fundamentals and find where there was consensus. So I booked us in to do some mob programming together except we were not going to write new code. We were going to focus on only refactoring.

Continue reading “Learning Refactoring Together”