Turning unpredictability into profit.

A liveblog of Don Reinertsens’ Agile Cambridge keynote

Liveblog - The accidental sysadmin.

liveblog: the accidental sysadmin (starting at 28 minutes into the session)

Software engineering in a digitized world

A live blog of Mary Poppendieck’s xp2016 keynote.

XP at scale - liveblog from the XP2016 keynote

Elizabeth Hendrickson keynoting on eXtreme programming at scale, XP2016 Edinburgh. Elizabeth works as VP R&D for Cloud foundry development at Pivotal.

Test Drive a unit testing framework in bash part two

This is the second part of my writeup of the session I did at XPDays Benelux and XP 2016 in Edinburgh called “Bourne Again” on bootstrapping a unit testing framework in the Bourne Again Shell (bash). This series of posts walk you through the steps I took in 75 minutes of programming.

Test Drive a unit testing framework in bash part one

I did a public programming session at XPDays Benelux and XP 2016 in Edinburgh called “Bourne Again” on bootstrapping a unit testing framework in the Bourne Again Shell (bash). This series of posts walk you through the steps I took in 75 minutes of programming.

What is a heuristic?

A heuristic is anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.

Glanceable tests

As we spend more time reading code than writing it, we’d like our code to be glanceable. By glancing at the code, we want to quickly understand its intent. Glanceability is a useful property, for production code as well as test code. Test code is there to help us out, so being able to quickly grasp what the test is about will help future us, and others, keep our tests habitable.

TDD Heuristics: Given-When-Then or Arrange-Act-Assert

How do I structure my tests, so that they are understable and focused on the behaviour of the system under test? Given-When-Then and Arrange-Act-Assert are two similar ways of structuring your test cases to make them easier to understand at a glance. This test structure also helps to keep your test focused on a single concern.

TDD Heuristics: One Assert Per Test

We do not like long test scenarios with loads of different asserts. A test case that has many expectations is difficult to understand when it fails. We then have to dig inside the test’s implementation to see what exactly went wrong where. Before we know it, we fall in to a lengthy debugging session.

TDD Heuristics: Test name describes action and expected result

We use test names or test descriptions to tell what the test is about: what is the action or event, what is the expected result.

TDD Heuristics: Faking & Cheating

Once we have a failing test, how do we get to green quickly? If we can get away with faking it, we do that. It is sometimes the simplest way to get the test to pass, and to remind us to write the next test case.

TDD Heuristics: Act Dumb in Implementation

When we have written a failing test, we try to make it work in the simplest possible way - do the simplest thing that could possibly work. We prefer baby steps, so at each step we understand precisely what we are doing, even if we have not solved the whole problem yet. Cheating and faking are allowed.

TDD Heuristics: 0, 1, N

Where do we start when test-driving a new piece of code? All options are open, but we risk getting stuck because of the blank-piece-of-paper feeling. Because we want to take baby steps towards the end result, use the 0, 1, N guideline: we start with some ‘zero’ or edge case, then make it work for a single case, then generalize it to multiple cases.

TDD Heuristics: Start with the expectation

Write the last part of your test first: start with the expectation (or the assert) and write the test bottom-up.

TDD Heuristics: Wishful Thinking

Write a test based on how you wish the object under test could be used. Then make it work. Don’t let yourself be limited by constraints and implementation details… nothing is holding you back! Just write it as you’d wish it to be.

TDD Heuristics: Think about design in test

When writing a test, we don’t just think about how to formulate the test. We think about design - the design of the code-under-test and the context in which it fits. Writing a test is an act of design.

Test Driven Development - Still Relevant in 2021

The practice of Test Driven Development (TDD) has been around for quite a few years. It was popularized as part of eXtreme Programming 20 years ago. It has been our favourite way of working ever since, helping us to deliver multiple software products successfully. Though it’s simple to explain, it needs practice to master and to reap its benefits.

Hexagons in the back-end - an example

Hexagonal Architecture allows us to continuously evolve a web back-end. In this post, we’ll show you how we do that. It is a continuation of a series, previous instalments demonstrated how Hexagonal architecture facilitates automated test architecture, and development of a Vue.js based front-end. In this post, we will share how we applied it in the back-end for the Online Agile Fluency Diagnostic application.

Paying the price of fast(er) tests

We are fans of Test Driven Development (TDD). It has served us well over the years. The TDD cycle - test, fail, run, refactor - is all about getting rich feedback fast, feedback about design decisions, about the test, about your code. We thrive on fast tests. We also want to test-drive our adapter integration and UI tests. These tend to be slow and fragile with low quality feedback, so we try to keep these minimal.

Fast browser tests with Cypress - First Impressions

Imagine your UI and end-to-end tests could run an order of magnitude faster than they are now? Oh, you don’t have end-to-end tests, because they would be too slow and brittle? I have had that too, don’t worry. Imagine then if you could have cost-effective end-to-end tests. How would that impact your product development?

Test Data Builders

Updated 25-05-2021 - added link to the original Test Builder pattern post by Nat Pryce

Test driving a command line interface in Python

Testing a command line interface (CLI) should be just like testing a REST interface. A CLI is an adapter concern that we can test drive, separate from the business logic. In this post I’ll show an approach to test drive the command line interface of an application in Python.

How to decide on an architecture for automated tests

In this post, we will share another benefit of looking through the Hexagonal Architecture lens: it supports making decisions about the architecture of automated tests in your application landscape. It can guide you in questions like:

TDD & Hexagonal Architecture in front end - a journey

Over the years, we have done our share of UI and front end development. Long long time ago with SmallTalk, Visual Basic and Delphi, building web applications with server side rendering and React, and being involved in Angular projects at several clients. Recently we have been building front ends based on Vue.js. In a series of blog posts, we are going to share how we approach (hexagonal) architecture, test driven development, and incremental design in the front end.

Test Driven Development with Java course in Utrecht, NL, March 19 and 20 2020.

Happy new year! We are restarting open enrollment courses this year. The first one up is our test driven Java course. This will take place in Utrecht, Netherlands in March 19 and 20 in 2020.

Delete pending tests

Do you have pending tests left over from yesterday? Better delete them before they grow stale.

Test Drive a unit testing framework in bash part two

This is the second part of my writeup of the session I did at XPDays Benelux and XP 2016 in Edinburgh called “Bourne Again” on bootstrapping a unit testing framework in the Bourne Again Shell (bash). This series of posts walk you through the steps I took in 75 minutes of programming.

Test Drive a unit testing framework in bash part one

I did a public programming session at XPDays Benelux and XP 2016 in Edinburgh called “Bourne Again” on bootstrapping a unit testing framework in the Bourne Again Shell (bash). This series of posts walk you through the steps I took in 75 minutes of programming.

When (not) to use feature toggles

In this post, we will reflect on the practice of using feature toggles. As more and more development organizations are moving towards continuous delivery, we see them using feature toggles more and more. It is, once again, not a best practice, but one that comes with trade-offs. We are not implying feature toggles are bad, but we urge you to be aware of the trade-offs and risks involved, and to take a critical look at how you are using them.

Deploy a blank page with Dokku

So you want to quickly deploy a small experiment to production. How do you do that? Dokku is one way of doing that. Here are my first impressions.

Logical vs Deployment Architecture

When we visit clients and discuss the architecture of their software systems, we often notice that people conflate different concerns under the term ‘architecture’. They tend to mix logical concerns with deployment concerns. Examples of logical concerns would be domain logic, domain dynamics, and how these are connected. Deployment concerns can be for instance REST APIs, components, microservices, and lambdas. The recent ‘cloud native’ movement has made this even worse, especially with serverless infrastructure concepts.

Cargo cults and angry chaos monkeys

Upaated 21 november 2020, added some more notes on Simon Wardleys segment.

Liveblog - The accidental sysadmin.

liveblog: the accidental sysadmin (starting at 28 minutes into the session)

Glanceable tests

As we spend more time reading code than writing it, we’d like our code to be glanceable. By glancing at the code, we want to quickly understand its intent. Glanceability is a useful property, for production code as well as test code. Test code is there to help us out, so being able to quickly grasp what the test is about will help future us, and others, keep our tests habitable.

Literate adventures in C - warming up

Jez Higgins and Chris Oldwood recommended The Practice of Programming book to me when we were working on an enterprise C++ project. It is from the same vintage as Extreme Programming Explained and Refactoring, but quite different. It is multi-language, but some of the exercises are in C (not surprising, given the authors’ backgrounds). I got started on it last year, but life got in the way, and I needed to practice my C a bit before being able to do anything meaningful in it. Now that Rob and I are prepping for a C++ TDD / Legacy code training next month, I’m in the right frame of mind to also dive deeper into C.

Why red-green does not keep you clean

Red-Green-Refactor is broken, because the psychological reward happens at green. When you get that reward, you feel the task has been completed, and are inclined to stop. Therefore refactoring is a lot rarer than it should be.

Delete pending tests

Do you have pending tests left over from yesterday? Better delete them before they grow stale.

Literate adventures in C - warming up

Jez Higgins and Chris Oldwood recommended The Practice of Programming book to me when we were working on an enterprise C++ project. It is from the same vintage as Extreme Programming Explained and Refactoring, but quite different. It is multi-language, but some of the exercises are in C (not surprising, given the authors’ backgrounds). I got started on it last year, but life got in the way, and I needed to practice my C a bit before being able to do anything meaningful in it. Now that Rob and I are prepping for a C++ TDD / Legacy code training next month, I’m in the right frame of mind to also dive deeper into C.

Delete pending tests

Do you have pending tests left over from yesterday? Better delete them before they grow stale.

What is a heuristic?

A heuristic is anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.

Glanceable tests

As we spend more time reading code than writing it, we’d like our code to be glanceable. By glancing at the code, we want to quickly understand its intent. Glanceability is a useful property, for production code as well as test code. Test code is there to help us out, so being able to quickly grasp what the test is about will help future us, and others, keep our tests habitable.

TDD Heuristics: Given-When-Then or Arrange-Act-Assert

How do I structure my tests, so that they are understable and focused on the behaviour of the system under test? Given-When-Then and Arrange-Act-Assert are two similar ways of structuring your test cases to make them easier to understand at a glance. This test structure also helps to keep your test focused on a single concern.

TDD Heuristics: One Assert Per Test

We do not like long test scenarios with loads of different asserts. A test case that has many expectations is difficult to understand when it fails. We then have to dig inside the test’s implementation to see what exactly went wrong where. Before we know it, we fall in to a lengthy debugging session.

TDD Heuristics: Test name describes action and expected result

We use test names or test descriptions to tell what the test is about: what is the action or event, what is the expected result.

TDD Heuristics: Faking & Cheating

Once we have a failing test, how do we get to green quickly? If we can get away with faking it, we do that. It is sometimes the simplest way to get the test to pass, and to remind us to write the next test case.

TDD Heuristics: Act Dumb in Implementation

When we have written a failing test, we try to make it work in the simplest possible way - do the simplest thing that could possibly work. We prefer baby steps, so at each step we understand precisely what we are doing, even if we have not solved the whole problem yet. Cheating and faking are allowed.

TDD Heuristics: 0, 1, N

Where do we start when test-driving a new piece of code? All options are open, but we risk getting stuck because of the blank-piece-of-paper feeling. Because we want to take baby steps towards the end result, use the 0, 1, N guideline: we start with some ‘zero’ or edge case, then make it work for a single case, then generalize it to multiple cases.

Simple acts of kindness and love

Today we’re writing about how simple acts improve feedback loops, which has a compounding effect in development teams over time.

TDD Heuristics: Start with the expectation

Write the last part of your test first: start with the expectation (or the assert) and write the test bottom-up.

TDD Heuristics: Wishful Thinking

Write a test based on how you wish the object under test could be used. Then make it work. Don’t let yourself be limited by constraints and implementation details… nothing is holding you back! Just write it as you’d wish it to be.

TDD Heuristics: Think about design in test

When writing a test, we don’t just think about how to formulate the test. We think about design - the design of the code-under-test and the context in which it fits. Writing a test is an act of design.

Test Driven Development - Still Relevant in 2021

The practice of Test Driven Development (TDD) has been around for quite a few years. It was popularized as part of eXtreme Programming 20 years ago. It has been our favourite way of working ever since, helping us to deliver multiple software products successfully. Though it’s simple to explain, it needs practice to master and to reap its benefits.

When (not) to use feature toggles

In this post, we will reflect on the practice of using feature toggles. As more and more development organizations are moving towards continuous delivery, we see them using feature toggles more and more. It is, once again, not a best practice, but one that comes with trade-offs. We are not implying feature toggles are bad, but we urge you to be aware of the trade-offs and risks involved, and to take a critical look at how you are using them.

Why red-green does not keep you clean

Red-Green-Refactor is broken, because the psychological reward happens at green. When you get that reward, you feel the task has been completed, and are inclined to stop. Therefore refactoring is a lot rarer than it should be.

Hot reloading a purescript Halogen UI with minimal configuration

Hot reloading a Halogen app with Parcel requires almost no configuration. Demo

Change is for other people

To remind myself that I often find it easier to encourage others to change than to change myself, I have been using change is for other people as a mantra,

Situated Software - revisited

I was planning to use my keys left for something different today, but found myself in an associative storm of tweets, possible conference sessions to be proposed and some situated software I’ve been working on for a few years, intermittently.

Back to basics with React

For a production application I’m using PUX, a purescript wrapper around React. In the way we use it for WeReview we are experiencing performance and usability issues, beyond the slow rendering.

Hot reloading a purescript Halogen UI with minimal configuration

Hot reloading a Halogen app with Parcel requires almost no configuration. Demo

Hot reloading a purescript Halogen UI with minimal configuration

Hot reloading a Halogen app with Parcel requires almost no configuration. Demo

Hot reloading a purescript Halogen UI with minimal configuration

Hot reloading a Halogen app with Parcel requires almost no configuration. Demo

Why red-green does not keep you clean

Red-Green-Refactor is broken, because the psychological reward happens at green. When you get that reward, you feel the task has been completed, and are inclined to stop. Therefore refactoring is a lot rarer than it should be.

Why red-green does not keep you clean

Red-Green-Refactor is broken, because the psychological reward happens at green. When you get that reward, you feel the task has been completed, and are inclined to stop. Therefore refactoring is a lot rarer than it should be.

Change is for other people

To remind myself that I often find it easier to encourage others to change than to change myself, I have been using change is for other people as a mantra,

Situated Software - revisited

I was planning to use my keys left for something different today, but found myself in an associative storm of tweets, possible conference sessions to be proposed and some situated software I’ve been working on for a few years, intermittently.

Back to basics with React

For a production application I’m using PUX, a purescript wrapper around React. In the way we use it for WeReview we are experiencing performance and usability issues, beyond the slow rendering.

Delayed dependency. Two steps forward, one step back.

Yesterday I thought I pushed out another iteration of our attempt at making the QWAN website more accessible. Turns out I didn’t. While adjusting details, reading CSS and accessibility documentation and blogposts, I missed the fact that the shiny assets pipeline I added does not actually build on github.

A baby step in making our site more accessible

The QWAN site currently is not accessible for blind users. If you were to use a screen reader, the page might just as well be blank. A blind colleague mentioned to us a while ago that they could not read the home page at all. I have just started improving it.

A Hexagonal Vue.js front-end, by example

In a previous post, we elaborated on why and how we apply Hexagonal Architecture in front end applications.

How to keep Front End complexity in check with Hexagonal Architecture

Front ends tend to start out simple, often as ‘just’ a form or a grid showing data that comes from a backend. It looks like ‘just’ a visual layer on top of backend APIs. When a front end evolves and grows, it inevitably becomes more complex. We then need to take a good hard look at the UX/UI and overall architecture.

TDD & Hexagonal Architecture in front end - a journey

Over the years, we have done our share of UI and front end development. Long long time ago with SmallTalk, Visual Basic and Delphi, building web applications with server side rendering and React, and being involved in Angular projects at several clients. Recently we have been building front ends based on Vue.js. In a series of blog posts, we are going to share how we approach (hexagonal) architecture, test driven development, and incremental design in the front end.

A baby step in making our site more accessible

The QWAN site currently is not accessible for blind users. If you were to use a screen reader, the page might just as well be blank. A blind colleague mentioned to us a while ago that they could not read the home page at all. I have just started improving it.

Lean Agile Exchange - still a Community of Need conference

I was wondering if Lean Agile Exchange on 10 and 11 September would be as much a Community of Need conference as e.g. Lean Agile Scotland or Agile Cambridge were. I was not disappointed.

QWAN sponsors Lean Agile Exchange

We are sponsoring the Lean Agile Exchange Conference happening online, 10 and 11 September (UK daytime).

Hexagonal architecture at XP Days Benelux

Marc and Rob are running a Hexagonal Architecture workshop this thursday at XP Days Benelux, tickets for XP Days have sold out, but apparently there is a waitlist. So who knows, you still might be able to get a ticket.

Agile Camp NL

Rob and I participated in the brand new Agile Camp NL conference, a open-space-y conference on agile. Kudos to Karlijn Moll & Thomas van Zuijlen for running the conference and creating such a nice atmosphere!

Hexagonal architecture at XP Days Benelux

Marc and Rob are running a Hexagonal Architecture workshop this thursday at XP Days Benelux, tickets for XP Days have sold out, but apparently there is a waitlist. So who knows, you still might be able to get a ticket.

Agile Camp NL

Rob and I participated in the brand new Agile Camp NL conference, a open-space-y conference on agile. Kudos to Karlijn Moll & Thomas van Zuijlen for running the conference and creating such a nice atmosphere!

Slicing your Cake - Structuring your Hexagons

You are happily applying the Hexagonal Architecture pattern. You have hidden the unpredictable outside world behind ports and adapters, so you can speak your domain language. Awesome! But now your domain model grows as well. How do you keep that understandable? Imagine the inside of your hexagon was a cake. How would you slice your domain?

Wrapping dates, logging and UUIDs in concepts of their own

In our previous post on Hexagonal Architecture in a back-end, we mentioned wrapping ID generation and timestamps in concepts of their own. This might feel a bit over-designed, but we have reasons to do so. In this post, we share the trade-offs and rationale behind wrapping the standard stuff in abstractions of your own.

Hexagons in the back-end - an example

Hexagonal Architecture allows us to continuously evolve a web back-end. In this post, we’ll show you how we do that. It is a continuation of a series, previous instalments demonstrated how Hexagonal architecture facilitates automated test architecture, and development of a Vue.js based front-end. In this post, we will share how we applied it in the back-end for the Online Agile Fluency Diagnostic application.

What To Put Where?

Deciding What To Put Where is half of the work of software development. What should I put where, in such a way that me and my colleagues will be able to find it back later? Finding a good place for things in code greatly helps or hinders maintainability of the code later on.

Deploy a blank page with Dokku

So you want to quickly deploy a small experiment to production. How do you do that? Dokku is one way of doing that. Here are my first impressions.

Fast browser tests with Cypress - First Impressions

Imagine your UI and end-to-end tests could run an order of magnitude faster than they are now? Oh, you don’t have end-to-end tests, because they would be too slow and brittle? I have had that too, don’t worry. Imagine then if you could have cost-effective end-to-end tests. How would that impact your product development?

Logical vs Deployment Architecture

When we visit clients and discuss the architecture of their software systems, we often notice that people conflate different concerns under the term ‘architecture’. They tend to mix logical concerns with deployment concerns. Examples of logical concerns would be domain logic, domain dynamics, and how these are connected. Deployment concerns can be for instance REST APIs, components, microservices, and lambdas. The recent ‘cloud native’ movement has made this even worse, especially with serverless infrastructure concepts.

Test driving a command line interface in Python

Testing a command line interface (CLI) should be just like testing a REST interface. A CLI is an adapter concern that we can test drive, separate from the business logic. In this post I’ll show an approach to test drive the command line interface of an application in Python.

A Hexagonal Vue.js front-end, by example

In a previous post, we elaborated on why and how we apply Hexagonal Architecture in front end applications.

How to decide on an architecture for automated tests

In this post, we will share another benefit of looking through the Hexagonal Architecture lens: it supports making decisions about the architecture of automated tests in your application landscape. It can guide you in questions like:

How to keep Front End complexity in check with Hexagonal Architecture

Front ends tend to start out simple, often as ‘just’ a form or a grid showing data that comes from a backend. It looks like ‘just’ a visual layer on top of backend APIs. When a front end evolves and grows, it inevitably becomes more complex. We then need to take a good hard look at the UX/UI and overall architecture.

TDD & Hexagonal Architecture in front end - a journey

Over the years, we have done our share of UI and front end development. Long long time ago with SmallTalk, Visual Basic and Delphi, building web applications with server side rendering and React, and being involved in Angular projects at several clients. Recently we have been building front ends based on Vue.js. In a series of blog posts, we are going to share how we approach (hexagonal) architecture, test driven development, and incremental design in the front end.

Hexagonal Architecture

Hexagonal Architecture, also known as Ports and Adapters, is getting quite a bit of (well-deserved!) attention recently, especially in the Domain Driven Design community. Hexagonal Architecture is not a new thing: it was originally thought up by Alistair Cockburn (of Agile Manifesto fame) in the 90ies.

Hexagonal architecture at XP Days Benelux

Marc and Rob are running a Hexagonal Architecture workshop this thursday at XP Days Benelux, tickets for XP Days have sold out, but apparently there is a waitlist. So who knows, you still might be able to get a ticket.

Test Driven Development with Java course in Utrecht, NL, March 19 and 20 2020.

Happy new year! We are restarting open enrollment courses this year. The first one up is our test driven Java course. This will take place in Utrecht, Netherlands in March 19 and 20 in 2020.

When (not) to use feature toggles

In this post, we will reflect on the practice of using feature toggles. As more and more development organizations are moving towards continuous delivery, we see them using feature toggles more and more. It is, once again, not a best practice, but one that comes with trade-offs. We are not implying feature toggles are bad, but we urge you to be aware of the trade-offs and risks involved, and to take a critical look at how you are using them.

Paying the price of fast(er) tests

We are fans of Test Driven Development (TDD). It has served us well over the years. The TDD cycle - test, fail, run, refactor - is all about getting rich feedback fast, feedback about design decisions, about the test, about your code. We thrive on fast tests. We also want to test-drive our adapter integration and UI tests. These tend to be slow and fragile with low quality feedback, so we try to keep these minimal.

Dimensions of Features - An Example

In this next post in our series on Dimensional Planning, we will share how we applied Dimensional Planning to the Online Agile Fluency® Diagnostic application we have been working on since spring.

Dimensions of Dimensional Planning

In a previous post, we introduced the Dimensional Planning technique, and shared how we used this for a product we worked on. In this post, we will go more in depth and show how you can use the roads metaphor not only for releases of a product, but for individual features as well. This provides a fine-grained mechanism for planning and delivering small, valuable increments.

Deploy a blank page with Dokku

So you want to quickly deploy a small experiment to production. How do you do that? Dokku is one way of doing that. Here are my first impressions.

Under pressure

Are you regularly holding retrospectives, but they do not result in improvements? In this post we will highlight how a team can move to a virtuous cycle of continuous improvement.

Fast browser tests with Cypress - First Impressions

Imagine your UI and end-to-end tests could run an order of magnitude faster than they are now? Oh, you don’t have end-to-end tests, because they would be too slow and brittle? I have had that too, don’t worry. Imagine then if you could have cost-effective end-to-end tests. How would that impact your product development?

Test driving a command line interface in Python

Testing a command line interface (CLI) should be just like testing a REST interface. A CLI is an adapter concern that we can test drive, separate from the business logic. In this post I’ll show an approach to test drive the command line interface of an application in Python.

Dimensional Planning - a story

In this post, we will explain how Dimensional Planning can work by sharing a story of how we applied it in a project and how it helped us to steer the project towards delivering its desired outcomes in time.

How to decide on an architecture for automated tests

In this post, we will share another benefit of looking through the Hexagonal Architecture lens: it supports making decisions about the architecture of automated tests in your application landscape. It can guide you in questions like:

Deploy a blank page to production

Continuous delivery is valuable, but where do you start? At the start of a greenfield development you have no software, and if you had any software, you would not know how to put it into production.

Dimensional Planning - good enough software, early & often

Starting new product development with the question ‘What can we leave out?’ may seem paradoxical. We do this to start a conversation between customers and developers. As we go we develop a shared language, so that value can be delivered early and often. This is called Dimensional Planning.

Delayed dependency. Two steps forward, one step back.

Yesterday I thought I pushed out another iteration of our attempt at making the QWAN website more accessible. Turns out I didn’t. While adjusting details, reading CSS and accessibility documentation and blogposts, I missed the fact that the shiny assets pipeline I added does not actually build on github.

Stringing words together.

Work has, once again for me, become more personal. I’m getting back into writing. This is a quick, rambling, update, so you can at least get some idea of what we are up to at the moment.

Stringing words together.

Work has, once again for me, become more personal. I’m getting back into writing. This is a quick, rambling, update, so you can at least get some idea of what we are up to at the moment.

Hexagons in the back-end - an example

Hexagonal Architecture allows us to continuously evolve a web back-end. In this post, we’ll show you how we do that. It is a continuation of a series, previous instalments demonstrated how Hexagonal architecture facilitates automated test architecture, and development of a Vue.js based front-end. In this post, we will share how we applied it in the back-end for the Online Agile Fluency Diagnostic application.

Deploy a blank page to production

Continuous delivery is valuable, but where do you start? At the start of a greenfield development you have no software, and if you had any software, you would not know how to put it into production.

TDD & Hexagonal Architecture in front end - a journey

Over the years, we have done our share of UI and front end development. Long long time ago with SmallTalk, Visual Basic and Delphi, building web applications with server side rendering and React, and being involved in Angular projects at several clients. Recently we have been building front ends based on Vue.js. In a series of blog posts, we are going to share how we approach (hexagonal) architecture, test driven development, and incremental design in the front end.

Hexagonal Architecture

Hexagonal Architecture, also known as Ports and Adapters, is getting quite a bit of (well-deserved!) attention recently, especially in the Domain Driven Design community. Hexagonal Architecture is not a new thing: it was originally thought up by Alistair Cockburn (of Agile Manifesto fame) in the 90ies.

Experiments move you forward

Even when it doesn’t feel like it.

Takeaways from Making Decisions in Turbulent Times

I enjoyed watching Container Solutions’ Jamie Dobson present an introduction to their pattern language for strategy yesterday, titled “A framework for strategy, making decisions in turbulent times”. I recommend viewing the recording, ‘A Pattern Language for Strategy’. Below are my main takeaways.

Cargo cults and angry chaos monkeys

Upaated 21 november 2020, added some more notes on Simon Wardleys segment.

QWAN sponsors Lean Agile Exchange

We are sponsoring the Lean Agile Exchange Conference happening online, 10 and 11 September (UK daytime).

Experiments move you forward

Even when it doesn’t feel like it.

Takeaways from Making Decisions in Turbulent Times

I enjoyed watching Container Solutions’ Jamie Dobson present an introduction to their pattern language for strategy yesterday, titled “A framework for strategy, making decisions in turbulent times”. I recommend viewing the recording, ‘A Pattern Language for Strategy’. Below are my main takeaways.

Takeaways from Making Decisions in Turbulent Times

I enjoyed watching Container Solutions’ Jamie Dobson present an introduction to their pattern language for strategy yesterday, titled “A framework for strategy, making decisions in turbulent times”. I recommend viewing the recording, ‘A Pattern Language for Strategy’. Below are my main takeaways.

Simple acts of kindness and love

Today we’re writing about how simple acts improve feedback loops, which has a compounding effect in development teams over time.

Paying the price of fast(er) tests

We are fans of Test Driven Development (TDD). It has served us well over the years. The TDD cycle - test, fail, run, refactor - is all about getting rich feedback fast, feedback about design decisions, about the test, about your code. We thrive on fast tests. We also want to test-drive our adapter integration and UI tests. These tend to be slow and fragile with low quality feedback, so we try to keep these minimal.

Under pressure

Are you regularly holding retrospectives, but they do not result in improvements? In this post we will highlight how a team can move to a virtuous cycle of continuous improvement.

Experiments move you forward

Even when it doesn’t feel like it.

Experiments move you forward

Even when it doesn’t feel like it.

Lean Agile Exchange - still a Community of Need conference

I was wondering if Lean Agile Exchange on 10 and 11 September would be as much a Community of Need conference as e.g. Lean Agile Scotland or Agile Cambridge were. I was not disappointed.

QWAN sponsors Lean Agile Exchange

We are sponsoring the Lean Agile Exchange Conference happening online, 10 and 11 September (UK daytime).

Lean Agile Exchange - still a Community of Need conference

I was wondering if Lean Agile Exchange on 10 and 11 September would be as much a Community of Need conference as e.g. Lean Agile Scotland or Agile Cambridge were. I was not disappointed.

QWAN sponsors Lean Agile Exchange

We are sponsoring the Lean Agile Exchange Conference happening online, 10 and 11 September (UK daytime).

Slicing your Cake - Structuring your Hexagons

You are happily applying the Hexagonal Architecture pattern. You have hidden the unpredictable outside world behind ports and adapters, so you can speak your domain language. Awesome! But now your domain model grows as well. How do you keep that understandable? Imagine the inside of your hexagon was a cake. How would you slice your domain?

Hexagons in the back-end - an example

Hexagonal Architecture allows us to continuously evolve a web back-end. In this post, we’ll show you how we do that. It is a continuation of a series, previous instalments demonstrated how Hexagonal architecture facilitates automated test architecture, and development of a Vue.js based front-end. In this post, we will share how we applied it in the back-end for the Online Agile Fluency Diagnostic application.

A Hexagonal Vue.js front-end, by example

In a previous post, we elaborated on why and how we apply Hexagonal Architecture in front end applications.

How to decide on an architecture for automated tests

In this post, we will share another benefit of looking through the Hexagonal Architecture lens: it supports making decisions about the architecture of automated tests in your application landscape. It can guide you in questions like:

How to keep Front End complexity in check with Hexagonal Architecture

Front ends tend to start out simple, often as ‘just’ a form or a grid showing data that comes from a backend. It looks like ‘just’ a visual layer on top of backend APIs. When a front end evolves and grows, it inevitably becomes more complex. We then need to take a good hard look at the UX/UI and overall architecture.

TDD & Hexagonal Architecture in front end - a journey

Over the years, we have done our share of UI and front end development. Long long time ago with SmallTalk, Visual Basic and Delphi, building web applications with server side rendering and React, and being involved in Angular projects at several clients. Recently we have been building front ends based on Vue.js. In a series of blog posts, we are going to share how we approach (hexagonal) architecture, test driven development, and incremental design in the front end.

Hexagonal Architecture

Hexagonal Architecture, also known as Ports and Adapters, is getting quite a bit of (well-deserved!) attention recently, especially in the Domain Driven Design community. Hexagonal Architecture is not a new thing: it was originally thought up by Alistair Cockburn (of Agile Manifesto fame) in the 90ies.

Glanceable tests

As we spend more time reading code than writing it, we’d like our code to be glanceable. By glancing at the code, we want to quickly understand its intent. Glanceability is a useful property, for production code as well as test code. Test code is there to help us out, so being able to quickly grasp what the test is about will help future us, and others, keep our tests habitable.

TDD Heuristics: Given-When-Then or Arrange-Act-Assert

How do I structure my tests, so that they are understable and focused on the behaviour of the system under test? Given-When-Then and Arrange-Act-Assert are two similar ways of structuring your test cases to make them easier to understand at a glance. This test structure also helps to keep your test focused on a single concern.

TDD Heuristics: One Assert Per Test

We do not like long test scenarios with loads of different asserts. A test case that has many expectations is difficult to understand when it fails. We then have to dig inside the test’s implementation to see what exactly went wrong where. Before we know it, we fall in to a lengthy debugging session.

TDD Heuristics: Test name describes action and expected result

We use test names or test descriptions to tell what the test is about: what is the action or event, what is the expected result.

TDD Heuristics: Faking & Cheating

Once we have a failing test, how do we get to green quickly? If we can get away with faking it, we do that. It is sometimes the simplest way to get the test to pass, and to remind us to write the next test case.

TDD Heuristics: Act Dumb in Implementation

When we have written a failing test, we try to make it work in the simplest possible way - do the simplest thing that could possibly work. We prefer baby steps, so at each step we understand precisely what we are doing, even if we have not solved the whole problem yet. Cheating and faking are allowed.

TDD Heuristics: 0, 1, N

Where do we start when test-driving a new piece of code? All options are open, but we risk getting stuck because of the blank-piece-of-paper feeling. Because we want to take baby steps towards the end result, use the 0, 1, N guideline: we start with some ‘zero’ or edge case, then make it work for a single case, then generalize it to multiple cases.

TDD Heuristics: Start with the expectation

Write the last part of your test first: start with the expectation (or the assert) and write the test bottom-up.

TDD Heuristics: Wishful Thinking

Write a test based on how you wish the object under test could be used. Then make it work. Don’t let yourself be limited by constraints and implementation details… nothing is holding you back! Just write it as you’d wish it to be.

TDD Heuristics: Think about design in test

When writing a test, we don’t just think about how to formulate the test. We think about design - the design of the code-under-test and the context in which it fits. Writing a test is an act of design.

Test Driven Development - Still Relevant in 2021

The practice of Test Driven Development (TDD) has been around for quite a few years. It was popularized as part of eXtreme Programming 20 years ago. It has been our favourite way of working ever since, helping us to deliver multiple software products successfully. Though it’s simple to explain, it needs practice to master and to reap its benefits.

Statler and Waldorf programming

Us three, having fallen into a conversation with code:

Dimensions of Features - An Example

In this next post in our series on Dimensional Planning, we will share how we applied Dimensional Planning to the Online Agile Fluency® Diagnostic application we have been working on since spring.

Dimensions of Dimensional Planning

In a previous post, we introduced the Dimensional Planning technique, and shared how we used this for a product we worked on. In this post, we will go more in depth and show how you can use the roads metaphor not only for releases of a product, but for individual features as well. This provides a fine-grained mechanism for planning and delivering small, valuable increments.

Dimensional Planning - a story

In this post, we will explain how Dimensional Planning can work by sharing a story of how we applied it in a project and how it helped us to steer the project towards delivering its desired outcomes in time.

Dimensional Planning - good enough software, early & often

Starting new product development with the question ‘What can we leave out?’ may seem paradoxical. We do this to start a conversation between customers and developers. As we go we develop a shared language, so that value can be delivered early and often. This is called Dimensional Planning.

Wrapping dates, logging and UUIDs in concepts of their own

In our previous post on Hexagonal Architecture in a back-end, we mentioned wrapping ID generation and timestamps in concepts of their own. This might feel a bit over-designed, but we have reasons to do so. In this post, we share the trade-offs and rationale behind wrapping the standard stuff in abstractions of your own.

What To Put Where?

Deciding What To Put Where is half of the work of software development. What should I put where, in such a way that me and my colleagues will be able to find it back later? Finding a good place for things in code greatly helps or hinders maintainability of the code later on.

Test Data Builders

Updated 25-05-2021 - added link to the original Test Builder pattern post by Nat Pryce

Simple acts of kindness and love

Today we’re writing about how simple acts improve feedback loops, which has a compounding effect in development teams over time.

Paying the price of fast(er) tests

We are fans of Test Driven Development (TDD). It has served us well over the years. The TDD cycle - test, fail, run, refactor - is all about getting rich feedback fast, feedback about design decisions, about the test, about your code. We thrive on fast tests. We also want to test-drive our adapter integration and UI tests. These tend to be slow and fragile with low quality feedback, so we try to keep these minimal.

Under pressure

Are you regularly holding retrospectives, but they do not result in improvements? In this post we will highlight how a team can move to a virtuous cycle of continuous improvement.

Fast browser tests with Cypress - First Impressions

Imagine your UI and end-to-end tests could run an order of magnitude faster than they are now? Oh, you don’t have end-to-end tests, because they would be too slow and brittle? I have had that too, don’t worry. Imagine then if you could have cost-effective end-to-end tests. How would that impact your product development?

Simple acts of kindness and love

Today we’re writing about how simple acts improve feedback loops, which has a compounding effect in development teams over time.

Under pressure

Are you regularly holding retrospectives, but they do not result in improvements? In this post we will highlight how a team can move to a virtuous cycle of continuous improvement.

Under pressure

Are you regularly holding retrospectives, but they do not result in improvements? In this post we will highlight how a team can move to a virtuous cycle of continuous improvement.

Literate adventures in C - warming up

Jez Higgins and Chris Oldwood recommended The Practice of Programming book to me when we were working on an enterprise C++ project. It is from the same vintage as Extreme Programming Explained and Refactoring, but quite different. It is multi-language, but some of the exercises are in C (not surprising, given the authors’ backgrounds). I got started on it last year, but life got in the way, and I needed to practice my C a bit before being able to do anything meaningful in it. Now that Rob and I are prepping for a C++ TDD / Legacy code training next month, I’m in the right frame of mind to also dive deeper into C.

What is a heuristic?

A heuristic is anything that provides a plausible aid or direction in the solution of a problem but is in the final analysis unjustified, incapable of justification, and potentially fallible.

Literate adventures in C - warming up

Jez Higgins and Chris Oldwood recommended The Practice of Programming book to me when we were working on an enterprise C++ project. It is from the same vintage as Extreme Programming Explained and Refactoring, but quite different. It is multi-language, but some of the exercises are in C (not surprising, given the authors’ backgrounds). I got started on it last year, but life got in the way, and I needed to practice my C a bit before being able to do anything meaningful in it. Now that Rob and I are prepping for a C++ TDD / Legacy code training next month, I’m in the right frame of mind to also dive deeper into C.