QWAN

Reflections - Blog

Impressions from Agile Manchester 2023

I went to Agile Manchester 2023 because I have a lot of things to think about. And sometimes the best way to think is to have a conversation with someone. At QWAN we like our rubber ducks to talk to, but actual people add that little extra.

Read More

Productivity is systemic

Productivity of software development teams is difficult to get a grip on, but virtually everyone wants teams to be more productive. We often talk to managers, who say they’d like their teams to be more productive, or in their words ‘go faster’. Today we write a bit more about what we see around productivity in software development, and how seeing productivity as a property of a system can help you spot symptoms, fire-fighting and work towards more durable solutions.

Read More

TDD Heuristics: One failing test at a time

When you are changing an interface or API that is widely used, it can be tempting to do the change in one go and break a lot of tests at once, assuming you can just fix them. You risk ending up chasing failing tests around for hours, with lack of good feedback why they fail. Furthermore, you risk breaking something along the way, because you have created holes in your safety net!

Read More

Team Fluency Feedback with Systems Thinking

To get better insights in how a team can grow and what support they need from their organization, we use the Agile Fluency® model and associated tools. In this post, we’ll share how we run an Agile Fluency team diagnostic workshop and how we use systems thinking techniques to arrive at recommendations for both the team and management.

Read More

Christopher Alexander

Being alive
The search which we make for this quality, in our own lives, is the central search of any person, and the crux of any individual person’s story. It is the search for those moments and situations when we are most alive.
– The Timeless Way of Building, p. 41

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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?

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

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.

Read More

An experience in Mass Pairing

A Mass Pairing is a coding dojo that takes over all sessions for a slot during a conference. We’ve found it a great way to introduce participants to each other, and explore an aspect of programming at a conference. We had some pleasant suprrises, and still have some questions.

Read More

FP Days London 2014, November 20 and 21

I’m glad to be part of the organizing cabal behind FP Days London this year. I hope to have some time to go to sessions. I’ve programmed in Clojure, Scala and Haskell this year, and there’s something from all of that on the programme, and it’s cool to be able to find out more about languages I haven’t used in anger yet like F# and Erlang.

Read More

So, how is that lean call for /dev/summer sessions working?

So we are trying a leaner way of creating conference programs . How is it going so far with /dev/summer, the free one day event for developers? We took just two weeks to advertise the program of /dev/summer. Not too bad. We’re not facing a deluge of sessions on one hand, on the other hand, we got some nice sessions coming in, so after tomorrow night we probably can put together a program without turning many sessions away. On the one hand it’s great if you can be selective, on the other hand, it feels wasteful to have people propose and review sessions and then only run half or less of them. On the other, other hand, this also enables us to give feedback fast to the presenters.

Read More

What we seek in a /dev/summer session

I’ve received a few questions as to what we are exactly looking for in /dev/summer talks or sessions. Imagine you are talking to another developer about what you do (can be a tool you use or make, a practice etc.). This developer may or may not have heard about your tool, but has not had the time to explore it in depth, let alone try it out in a real situation.

Read More

Categories