Hexploration

By Llewellyn Falco & Jacqueline Bilston

Over the past little while we've been exploring an alternative to the Game of Life with a hexagonal board. You can see the rules here. This led us to some super interesting discoveries that we'd like to share.

1. Verifying Sequences

The interesting part of the Game of Life is how it evolves over time. We wanted to write tests that could help us verify how the board changes frame to frame. You can do this by mapping time to space and creating a text file that prints out each frame one after the other, much like a comic book. Instead we decided to take advantage of the animated gif format, and play out the evolution much like a short film.

Here's an example of one of those calls displaying the initial board plus 33 additional frames:

verifySequence(board, 33, f -> board.advance())

which produces:

2. Exploratory Testing with Property-Based tests

Once we could verify sequences, we could start hunting for initial layouts that produce interesting sequences. There are lots of documented scenarios in a traditional square board (blinkers, guns and flyers, etc.), but we couldn't find any for hexagonal space. We decided to search on our own.

2A. Generating Random Boards

We took a page from property-based testing, and created a generator to randomly generate a board with a given number of live cells. We also printed out the board in a way that allowed us to capture and reproduce the ones we liked.

Here's an example of a board we reproduced.

new HexGameOfLife(_(2, 4), _(2, 6), _(1, 9), _(1, 3), _(5, 5), _(5, 1), _(3, 1))

This generated lots of results, and most of them were booooring.

2B. Filtering for "Interesting"

Taking another page from property-based testing, we created a filter to remove boring results. To do this, we had to ask

Q. What does interesting mean?
A. We can see cells in every frame.

Fortunately, coding this was quite simple.

1. Generate a board
2. Advance a turn, and check that cells still exist
3. Repeat until you get to the end of the frames
4. If you make it to the end, return, otherwise GOTO 1

With these steps, we found this board:

2C. The Blinker Search

In this process, we saw a simple blinker, but lost the board before we could capture it. We tried to get lucky again, but couldn't, so we decided to define what the properties of a blinker were, and then find one automatically.

Fortunately, coding this was quite simple.

1. Generate a board
2. Advance 12 turns, and check that the board is the same as the initial board.
3. If it is, you have found something that repeats every 1,2,3,4,6, or 12 frames. Otherwise GOTO 1

In just under 300,000 randomized searches, this returned: 

If you would like to check out the full code, start here

What is an Agile Technical Coach?

What is an Agile Technical Coach? By Llewellyn Falco & Jacqueline Bilston

Note: We originally wrote this as an internal memo. It's not meant to be a complete definition, but we thought it might be helpful to others so we are sharing it here.

TL;DR: An agile technical coach writes code with programmers for the purpose of improving how the team programs. Common areas include:

• Refactoring
• Test Driven Development
• DevOps

Overview

The focus of an agile technical coach is specifically on technical practices like refactoring, test driven development, and DevOps. This means that technical coaches are sitting with the programmers, writing code together. Their value is in the sustained behaviours the team continues using after they leave.

Although a coach is not a teacher (who works in practise problems), and a coach is not a consultant (whose main value is delivered while they are working with you), the roles sometimes overlap. A coach often wears the hat of a teacher in short bursts in order to enable a more productive coaching session while working with a team, and only rarely, if ever, acts as a consultant.

Agile is about being able to respond to change. There are two parts that work hand-in-hand to allow this to happen in software. One side comes from the management side of what and when to change. The other side comes from the technical side of having code that is easy to change. Technical Agile Coaches empower Agile Coaches to be able to respond in the ways they want.

The 4 Benefits of Tests

By Llewellyn Falco & Jacqueline Bilston

I’ve found that when I'm creating tests they provide 4 categories of benefits. Having these categories helps me to see how to write better tests and helps me see what to improve when I am feeling a particular pain. These benefits tend to occur in chronological order, which is how I’m going to lay out the explanations.

Note: This article is about tests as artifacts, not testing as performance. There is another area of testing known as exploratory testing. It is a different practice and provides different benefits.

#1 Specification

“What am I building?”

At the very beginning, before any code is even written, writing a test scenario can help you understand what it is you’re trying to build. These scenarios often work much better than requirements, as the specifics of a scenario will often surface hidden issues. Programming is often done between two or more parties. Sometimes it can feel that way even if you are doing it by yourself. Scenarios will surface misunderstandings where you thought you were in agreement; edge cases you weren’t considering; and logical errors before they are written.

Even if this is as far as you proceed with your tests, they will still bring value.

#2 Feedback

“Does it work?”

After you have a test scenario, you can immediately start getting feedback on whether or not it is completed. This feedback can come in many forms:

Programming by red: Compiler errors can guide you on what needs to be built next. Failing tests can guide you on what needs to be implemented differently.

Debugging / Logging / Inspecting: Running code and seeing the results is critical to understanding that you’ve built what you meant to. Just imagine if you shipped code that you never ran :-/ 

People don’t know what they want until they see what they don’t: Showing the results to a customer will bring insight into if you are building the right thing.

#3 Regression

“Does it still work?”

Just because code worked yesterday does NOT mean it still works today. Rerunning your tests allows you to know that things still work. A suite of passing tests gives confidence that things still work. Better still, a single failing test proves that something doesn’t.

Note: In my experience, you won’t get good regression without automated tests.

#4 Granularity

“Why did it break?”

Granularity can show up in many forms, but it’s always about figuring out how to fix what went wrong. I tend to see 2 main forms of it.

#1 Temporal Granularity: 

You just changed a line of code and it broke the build. That line is the problem. Maybe you just roll it back, maybe you fix it and roll it forward. Either way it’s fixed and it was easier than if you had changed 1,000 lines of code.

or...

5 people commit and the nightly build breaks, who caused it?

vs.

CI runs after each commit and Jonny's commit broke it.

or ...

The tests passed 2 minutes ago and now they are broken

vs.

The tests passed this morning and now they don't.

#2 Differential Granularity

‘Exception thrown’ doesn’t help anybody

‘Array index out of bounds’  is a little better.

‘Array[10] is out of bounds for length 10’ means you have an off-by-one error.

‘Array[-2] is out of bounds for length 10’ means you have calculation bug.

‘Array[two] is out of bounds for length 10’ means you have to verify user input .

‘Array[5] is out of bounds for length 0’ means you have to check if result came back empty.

Logs in JSON are queryable which helps you find issues faster.

Objects with useful toStrings help you understand the state of your system.

Diff tools help to find what changed between two outputs.

Giving meaningful output helps us understand the causes for failures and the potential fixes.