This year I and Steven Baker will be hosting Global Day of Code Retreat in Malmö.

This year is the 10th anniversary of the code retreat format and to commemorate this the global day is now two days! Both Friday the 15th and Saturday the 16th of November. You are welcome to one or both days.

Back to patterns again. And in specific ADR or Architectural Decision Records or even Lightweight Architectural Decision Records. The reason I write about this now is that it strikes me that more people should know the pattern exists. I recently read a couple of meeting minutes. The person who has written them has written them very much in the style of ADRs. They describe a problem, a context and a suggested solution.

What struck me when I read the meeting minutes though was that the author was not aware of the ADR pattern, which prompted me to write a little article about it.

As hinted at in my last post I wanted to dig into some of the different developer tests there are. Such things as unit test, integration tests, behaviour tests, specification tests and so on. We will also look at some different disciplines such as TDD, BDD, test first and test later, as well the concept known as Good Unit Tests (GUTs). I am no expert in all of the above but I've worked quite a bit with several of them. So I'll try to shed some further light on the stuff I know and hopefully make you more curious on the stuff I know less about. I'd love to get feedback, either on Twitter or [LinkedIn](linkedin ref), where we can talk about the topics.

Before I go in to the above topics though I'd like to start with a slightly more in depth look at what I mean when I talk about developer tests. I find that this is one of the less understood, and yet very important, aspects that we as developers need to understand in order to write good tests.

I find that a lot of people are confused about the difference between developers and testers working with tests. What seems to be the root ot the confusion is one of the key differences between the two roles, namely:

• The testers main task is to provide stakeholders with sufficient evidence that the stakeholders requirements on the product are met. To do this the tester needs to help the stakeholder define how to measure each requirement. The tester then needs to prove the product satisfies said measures. Much of this work is defining the criteria that we measure against. Then there is the work creating the data and reports that presents the evidence to the stakeholder.

• The developers main task is to implement the requirements the stakeholders have on the product. In order to do so it helps if the developers has access to mentioned criteria, but often they don't. Developers use tests to document details, integrations and use cases for the product. Tests are a tool we use to ensure that a product can be continuously developed in a sustainable way. They are our lifeline when we need to refactor and re-design. They are one of our main sources of documentation.

The other day I though struck me. I have a very senior colleague who is specialised in testing and have had a number of test lead roles. I my self is a pretty accomplished software crafter. What would happen if we looked at offering clients coaching in the whole lifecycle of software production, from idea to business capability and value. Naturally such coaching includes sustainably delivering release after release and continuously learn what value is and how this affects planning and functions in the product. After some conversations in the office we realised that we need to package this in some way. Find some kind of process or method we can use that will help the client to understand the value we add. This, at the moment, is focused on the inception phase, getting the client team up and running with the right thing.

After some poking around in my library I found the book Impact Mapping again. This is a really good method to get started. Working with the client to create an impact map to understand which path is one that is most beneficial to start with, whilst being able to track that we are doing the right thing over time. But something in the book made me think about a patter Dan North defined in his book Software Faster. The Three ages. So I wanted to write something about how The Three Ages can be applied to even further increase the value of your impact map.