Too close for comfort, the late miss Patsy and Mouse

Summary: pair programming has never been as popular or widespread as other agile practices. The practice of sacrificing up-front design and go straight to code is likely a factor. While I am still not a fan of pair coding, I do believe there’s a lot to be gained from more explicit design in regular group session between the developers in the team.

Pair programming has a long and respectable history. None other than Frederic Brooks of Silver Bullet fame practised it as early as 1953. In terms of seniority it makes Scrum, CI/CD and BDD look like recent fads by…


TL;DR
Pushing for test coverage is a bad incentive. It favors quantity over quality. You should prioritize your code with regard to test-worthiness. I discuss three such categories. First there is code that processes unmanaged and possibly malicious (user)input. You should test this for robustness. Secondly there is complex business logic with possible implementation errors. Test this for correctness. Thirdly there are quirks with trusted frameworks running code that doesn’t perform at scale. Run performance tests under realistic production loads to capture these.

If you like to get serious with test automation there are lots of great tools to pack…


Story point estimations get much of their bad reputation from poker sessions where team members are either ill prepared or the variety of skillsets is too great to say anything meaningful. The extraverts then bully the rest into reaching a consensus, or worse, split the difference.


This rings very true. We are tempted to just dig into the code far too quickly at a new job. But then again the question "where can I find your documentation?" is all too often followed by an embarrassed silence from the team..


I love reviews. When it comes to consumer equipment and whether it’s worth your money, it’s a blessing to have so much free advice to choose from. Last year I bought a new 3000-euro Casio Celviano digital piano online during the pandemic, purely based on internet reviews. Not my choice, but retail was locked down and I couldn’t try it out anywhere. Most reviews were favourable to raving, so I found safety in numbers there. Now you have to accept that reviews by retailers of their own wares are biased, but then again nobody would go to the trouble of…


Table Mountain in Crickhowell

In agile development we don’t like to specify to the tiniest detail before we begin coding or estimate the cost down to the last euro. It is a pointless exercise because building complex software is like travelling uncharted territory on foot: you cannot tell how hard the journey will be from a reconnaissance flight. Until you get your feet wet you cannot predict how hard it will be or how long it will take. That’s the definition of a complex, adaptive domain. Like the time I decided to climb Table Mountain in Crickhowell (Wales). …


You don’t need Orthodox TDD to code well

Orthodox TDD: start with a skeleton and slowly dress it up with functionality.

There is plenty of opinions on how to do Test-Driven Development well. Today I want to discuss the drawbacks of the orthodox TDD school, let’s call it OTDD. Although as a development method it lacks a how-to bible like the Scrum Guide, some proponents defend their take with a religious level of conviction. To my understanding OTDD has the following characteristics:

  • You start by writing a failing test against a skeleton implementation. Then you dress it up by implementing the scenario, making the test pass. …

Knole Park, Sevenoaks, Kent, UK

Roy Braam wrote an interesting article in the latest Java Magazine 1/2021 that I wholeheartedly agree with about the dubious usefulness of en-to-end testing. Sorry, no link: it’s a Dutch print magazine, but take my word for it. Just to make it clear: an end-to-end test is not to ensure the integrity of your own software components, but to make sure that they cooperate well with everything that is outside your sphere of influence. As these concerns are opaque and fickle by nature you would think they merit very thorough testing. In practice however you will benefit more from building…


I have always been an advocate of proper unit testing. I believe it is a necessary attribute of building maintainable software. I also thought myself pretty experienced in writing sensible (unit) tests, but reading Unit Testing Principles, Practices and Patterns was an eye-opener in several ways. Vladimir Khorikov spends his 300+ pages teaching us what distinguishes high-quality tests from the time wasters. He assumes you know your way around the tooling already. It’s not a hard book and if you have testing experience you should get through it quickly. The examples are in C# but translate easily to Java. …


I’ve been in IT for 20 years, without a CS degree (MA in English and former teacher). What I lack in mathematical prowess I make up for in analytical insight and people skills, I like to think. I really despise having to re-invent a linked list on a whiteboard, indeed, and suck at it.

Jasper Sprengers

I have been working in software since 1999, writing on whatever fascinates me about the craft, usually with a focus on testing and sensible agile practice.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store