This time I both hosted and facilitated this event. This means that besides practical stuff I also did the talking which I will explain further in this post. This was the first time I did this and I’d like to share how it was. If you want to get an impression of the day you can have a look at this slideshow.
A big thanks to Bob Forma and Diana Sabanovic who helped me with the hosting aspects throughout. This enabled me to mostly focus on facilitating.
I was anxious, especially since last years GDCR was very well done. Back then I had a great experience and I was not sure if I could give the participants the same experience. Yet, I wanted to do this: I just love sharing knowledge and give people something to learn or think about.
After attending the GDCR Facilitator Training by Jim Hurne, I had a clear image of how I wanted the participants to experience the Coderetreat: People having fun, learning from each other and the constraints given.
You change something and you can’t tell if your change broke something in the system.
If you’re lucky, you did not break anything. Or nobody noticed it.
Next to that, on the same scale of luck, the potential bugs are found in the manual testing phase.
But often there is no time to do all the regression testing by hand. It will take days and days, and the change you made looked so insignificant. It should go live. What could possibly go wrong?.
Then it happens. You’re live, your changes work, but the inevitable happens. Regression!
Of course, this has to be fixed. We can’t let our customers have a product with new features while the features of the previous version(s) are broken.
And so the patching process begins.
I call it patching, because often you are not done with one patch. While you were working hard to get the first patch live, other regression bugs are found and need to be patched asap as well! And so you end up with a few patches. You could be done with with a few patch releases. But it could easily extend ten-fold.
This process is very stressful for the customer and the development team. As the team is working to get these patches out soon, the customer is unhappy with his ‘broken system’. Even worse, once a few bugs are found, more testing is done on the live system to make sure everything still works, and more regression bugs poor in, adding up to the stress. To the development team it begins to look like…
From the customer’s point of view, it looks like the team working on the product is not in control. It is as if the team does not seem to know what they are doing. To them their product, which seemed rock solid at start, is degrading to a house of cards.
You can debate about high and low impact issues, and the matter of urgency to fix these issues. The perception of the customer is likely to be the same, regardless.
This is how I see it:
It is us developers who are responsible for letting regression happen.
Not testers.
Not project managers.
Not stakeholders.
Not the customer.
It is us and us alone.
We write the code, we change the code, we are in control of the code (at least we should be!).
Even if you happened to be depending on a third-party system, it is your job to keep an eye out on that system. Verify that it behaves as you would expect it to. Why? Your system depends on the behaviour of another system, trusting that this behaviour does not change is not enough. You have to be *sure*.
Its all about attitude
Do you always deal with regression bugs after each release?
Stop accepting it, it is not normal.
Rather, start thinking about how you can prevent this. Don’t look how other people could prevent this. Think of what you could do right now. There are many ways to reduce the amount of regression bugs. For instance: add tests before changing any code. Fixate the behavior with black box tests. When you refactor, keep running your tests so you know you did not break existing behaviour. Add new tests for new features you introduce. Create a test suite that you can trust. Make integration tests. Is it hard to write tests? Make it easier. Don’t back away from the code, it is your code and you should be in control.
But isn’t the whole team responsible?
Ah, of course! But does that mean that you, as a developer can now do less? Would it be okay in a team to not test, because you have testers? (“its their job right?”).
In a team we all have our strengths and weaknesses.
We understand code, and we can change code. No other role in your team is responsible for understanding the code then you. Being in a team does not make you less responsible.
Again, it is all about attitude. Stand for your craft, deliver high quality work and make sure the system is in check. It should be you who controls the system.
Attitude, again
There are developers out there who really think they know everything of the system. And to be honest, I once had a time where I always knew what changes had impact and what I could do. And even though I was right about the impact on changes…
…I was at least wrong as many times as I was right.
But sometimes it is not just being over-confident. Sometimes it is being ignorant, or even arrogant.
Please, don’t be like this guy…
Just because it is hard, doesn’t mean you shouldn’t do it
Regression is a pain. It can be dealt with.
It is not easy.
You will not completely eliminate regression bugs. But with the correct mindset, tools and safety-net(s), you will greatly reduce the amount of regression bugs.
It is necessary. Just do it. For the love of our (your!) craft, do it, for everyone who depends on us:
The customer.
The stakeholders.
The project managers.
Yes, even the testers.
Recently I promoted to do TDD, instead of “Tests First” development. Some people asked me what the difference is between them. In both cases we write tests first right?
So what is the difference?
I believe the difference is this:
Test First decribes your solution. TDD describes the problem
The difference could probably be explained best when using the coderetreat I had organized at the beginning of this year. Within this session I had experienced a great example to tell the difference between Tests first and TDD. To clarify the difference in this blog, we will be writing an implementation of Conway’s Game Of Life. It has the following rules:
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
And it looks like this:
Your assignment:
Write code that implements to the four rules above. It should be possible to apply these on an infinite grid
Test First describes your solution:
So the rules talk about “cells” and in your mind you’re already trying to solve this puzzle. In fact, I bet you’re already thinking about some array to put this matrix of cells into. Using a matrix we can easily determine neigbours and solve this puzzle…
We start with the first rule: “Any live cell with fewer than two live neighbours dies, …“.
We know it needs neighbours, so we need some boilerplate for that right?
The first test looks like this:
public class CellTest {
@Test
public void mustReturnTrueWhenAlive() {
Cell cell = new Cell(1,0);
Assert.assertTrue(cell.isAlive());
}
}
Since we’re doing TDD (atleast we think it is, we’re actually doing Tests First…), we need to create this Cell class to make it compile.
public class Cell {
private long x, y;
public Cell(int x, int y) {
this.x = x;
this.y = y;
}
public boolean isAlive() {
return true;
}
}
Before we can do anything with counting the number of neighbours, we need to determine what a neighbour is. Since adjecent cells are counted as neighbours, we start writing tests for this:
@Test
public void mustReturnTrueWhenNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(1,1);
Assert.assertTrue(cell.isAdjecent(adjecent));
}
@Test
public void mustReturnFalseWhenNotNextToAnotherCell() {
Cell cell = new Cell(1,0);
Cell adjecent = new Cell(3,3);
Assert.assertFalse(cell.isAdjecent(adjecent));
}
And along with it the code:
public class Cell {
private long x, y;
public Cell(int x, int y) {
this.x = x;
this.y = y;
}
public boolean isAlive() {
return true;
}
public boolean isAdjecent(Cell adjecent) {
long diffX = Math.abs(adjecent.getX() - x);
long diffY = Math.abs(adjecent.getY() - y);
return diffX == 1 || diffY == 1;
}
public long getX() {
return x;
}
public long getY() {
return y;
}
}
Wait, stop, halt!
If the above sounds familiar, then I’ve got news: This is not TDD
Lets get back to the original question, what did we try to implement? Ah, it was the question:
“Any live cell with fewer than two live neighbours dies, as if caused by under-population”,
So where is the corresponding test for that?…
In fact, we have already three tests and a bunch of code, and we still are not able to answer that question.
What we’ve done so far is write testsfirst in order to prove a solution we already had in our minds. We did not let the tests guide us to a design. In fact, we already had a design in our heads and made the tests conform to those.
Lets do it in TDD, for real…
So how is it done ? – Test Driven Development
With a clean slate, we start over. And we start with the first rule:
“Any live cell with fewer than two live neighbours dies, as if caused by under-population”
So we create a test (we call it Test, because we do not think about Cells yet, in fact, we are only thinking about this very question).
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
Assert.assertTrue(neighbours < 2);
}
So what does this do, it basically returns true when neighbours is lower than two. We do not call methods yet, we simply have our implementation within the test itself. In this phase, we already had Red (non compiling), Green (compiling and green test). On to refactor. How to get it more descriptive? We could do something like this:
@org.junit.Test
public void anyLiveCellWithFewerThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}
Do we need to do anything else? Certainly! But the essential rule is there already. It is one simple statement, no neighbour checking yet. And in fact, we will not need it to implement the four rules! Lets continue. I am serious, we will not modify the above code yet. We have yet to implement the other rules. Lets pick the second:
“Any live cell with two or three live neighbours lives on to the next generation.”
We have actually two cases here, for two and three live neighbours. Lets start with two:
@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}
Not that much different is it? How about we add the third test for the second rule:
@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}
The total test class looks like this now:
public class Test {
@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}
@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
boolean shouldLiveOn = neighbours == 2;
Assert.assertTrue(shouldLiveOn);
}
@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
boolean shouldLiveOn = neighbours == 3;
Assert.assertTrue(shouldLiveOn);
}
}
We have done some little TDD cycles already. We started describing the problem domain, and we added the minimum amount of code to make this work. We did not yet start write any production code yet. Now one of the most important steps in TDD should be taken: Refactor. (Remember it is Red – Green – Refactor!)
With the third test, we clearly see duplication. The shouldLiveOn can be extracted to a method. Lets do that:
import org.junit.Assert;
public class Test {
@org.junit.Test
public void anyLiveCellWithOneThanTwoLiveNeighboursDies() {
int neighbours = 1;
boolean shouldDie = neighbours < 2;
Assert.assertTrue(shouldDie);
}
@org.junit.Test
public void anyLiveCellWithTwoNeighboursLivesOn() {
int neighbours = 2;
Assert.assertTrue(shouldLiveOn(neighbours));
}
@org.junit.Test
public void anyLiveCellWithThreeNeighboursLivesOn() {
int neighbours = 3;
Assert.assertTrue(shouldLiveOn(neighbours));
}
private boolean shouldLiveOn(int neighbours) {
return neighbours == 3 || neighbours == 2;
}
}
We could refactor out the neighbours var to a constant, which should give us even smaller tests.
At this point we have now our first method which could eventually be moved out of the test class into some other class (we have yet to think of a name for). As you can see, the design of our code is being driven by the tests. So this may like trivial and like ‘cheating’. In fact, as I see it we are actually answering the real questions. We tend to write code for stuff we cannot possibly be sure of that it is correct. Did you see any line say that the Game of Life in this situation should be on a 2D grid? What if it would be 3D? What if we did not know yet if it would be 2D or 3D?
This sounds a lot like real-life isn’t it? Where your customer does not always know exactly what he wants.
Another good thing is, we can implement all rules like this. Eventually we end up with a test class that contains several methods. From there on we can think of a logical way to group them. Methods grouped together will form classes. We tend to group methods logically. When we define the problem domain we know better what classes should exist. Again, our tests drive the design. Instead of the other way around.
Here is an impression how the four rules implemented might look like:
package com.fundynamic.coderetreat;
import org.junit.*;
public class Test {
public static final int StarvationThreshold = 1;
public static final int OverpopulationThreshold = 4;
public static final int MinimumRevivalThreshold = 3;
public static final int MaximumRevivalThreshold = 3;
@org.junit.Test
public void liveCellShouldDieIfLessNeighboursThanStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void liveCellShouldDieIfNeighboursEqualToStarvationThreshold() {
int amountNeighbours = StarvationThreshold;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void liveCellShouldLiveIfTwoNeighbours() {
int amountNeighbours = StarvationThreshold +1;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void liveCellShouldLiveIfThreeNeighbours() {
int amountNeighbours = 3;
Assert.assertEquals(true, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void liveCellShouldDieIfFourNeighbours() {
int amountNeighbours = 4;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void liveCellShouldDieIfEightNeighbours() {
int amountNeighbours = 8;
Assert.assertEquals(false, livesOnToNextGeneration(amountNeighbours));
}
@org.junit.Test
public void deadCellShouldReviveIfMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}
@org.junit.Test
public void deadCellShouldReviveIfMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold;
Assert.assertEquals(true, revivesInNextGeneration(amountNeighbours));
}
@org.junit.Test
public void deadCellShouldNotReviveIfLessNeighboursThanMinimumRevivalThreshold() {
int amountNeighbours = MinimumRevivalThreshold -1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}
@org.junit.Test
public void deadCellShouldNotReviveIfMoreNeighboursThanMaximumRevivalThreshold() {
int amountNeighbours = MaximumRevivalThreshold +1;
Assert.assertEquals(false, revivesInNextGeneration(amountNeighbours));
}
private boolean livesOnToNextGeneration(int amountNeighbours) {
return amountNeighbours > StarvationThreshold && amountNeighbours < OverpopulationThreshold;
}
private boolean revivesInNextGeneration(int amountNeighbours) {
return amountNeighbours == MinimumRevivalThreshold;
}
}
But you did not even get to any cell? How is this any good?
It is true that cells play a role in the Game of Life eventually. But they do not play a role in answering the four questions. In fact, what are cells? We might be talking about squared cells or triangled or circled cells. Perhaps the requirement is to write a 3d version of a cell. Or you might want to use hexagons. If you put the rules logic into a cell, it gets very hard to modify your code because you have put too much responsibility in one class.
TDD prevents you from doing this. It prevents you from doing ‘design upfront’.
Also, if you started with using Cells and the matrix and all that. I would wonder how you would implement the last rule (reviving cells). How would you solve this problem?
Bottom line
Writing tests before your production code (test first) is not the same as TDD. TDD is about how your tests drive your design. Only then you can say if you are doing TDD or actually are just writing tests proving your own solution you have thought about before-hand.
It is hard to not think ahead of your design, and instead trust on our tests to let the design emerge itself. This requires practice. Practicing this can be done in coderetreats for instance.
Disclaimer about design…
TDD works great on a lot of levels in your architecture. This does not mean you can just do everything with TDD. Good architectural design requires thinking. You can’t just ‘do TDD’ and magically have a perfect design emerging. However, TDD will give you surprisingly elegant results. Especially, the more specific your problem (with a clear scope) the better TDD yields results.
Ever heard of the ten commendments of egoless programming? I came accross them a while ago. I just thought of putting them here for history sake, these ten are actually quite good and should be cached on every search engine’s server as many times as possible.
I really like nr 6 a lot. How about you?
So, here a recite:
1. Understand and accept that you will make mistakes.
The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2. You are not your code.
Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
3. No matter how much “karate” you know, someone else will always know more.
Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
4. Don’t rewrite code without consultation.
There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5. Treat people who know less than you with respect, deference, and patience.
Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
6. The only constant in the world is change.
Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7. The only true authority stems from knowledge, not from position.
Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8. Fight for what you believe, but gracefully accept defeat.
Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
9. Don’t be “the guy in the room.”
Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10. Critique code instead of people—be kind to the coder, not to the code.
As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.