Blog

When you make all the work explicit, you get fewer surprises.

When people work in product-based teams, the product development work is front and centre. It is easy to see how this work adds value and where it should live. Less obvious is where the day-to-day “Business As Usual” work sits, how it gets prioritised and measured, and how to ensure it is not neglected.

I like to make this kind of work explicit, as one of several types of demand. Making all the work visible means we can measure our real capacity and prioritise for changing business needs, rather than having “ghost” work hiding in the system.

This is a story about amazing customer service being undermined by poor software, in the form of simplistic business rules and fragile systems. I am telling it because I made a promise to someone who features prominently in the story, and whose manager should be aware just how fantastic their staff are, and just how much their poorly designed computer systems and cost-cutting are letting their company down.

What started as lighthearted iconoclasm, poking at the bear of SOLID, has developed into something more concrete and tangible. If I do not think the SOLID principles are useful these days, then what would I replace them with? Can any set of principles hold for all software? What do we even mean by principles?

Or how programmers and testers can work together for a happy and fulfilling life.

Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?

“If you had to offer some principles for modern software development, which would you choose?”

At a recent Extreme Tuesday Club (XTC) virtual meet-up, we were discussing whether the SOLID principles are outdated. A while ago I gave a tongue-in-cheek talk on the topic, so ahead of the meet-up one of the organisers asked what principles I would replace SOLID with since I disagreed with them. I have been thinking about this for some time and I proposed five of my own, which form the acronym CUPID.

My friend Gojko Adzic has been running a series of BDD quizzes illustrating different ways to approach some interesting BDD situations. I noticed on Twitter that Seb Rose, another BDDer (Cucumberer?), had gently taken issue with one of Gokjo’s solutions so I thought I’d take a look at them both. Before reading on I recommend reading Gojko’s solution and Seb’s response for context.

I recently found myself in yet another circular Twitter discussion of estimation, in which the One True Way to scope work in uncertainty ranged from entirely abandoning estimation to applying formal Cost Accounting methods and nothing less would suffice. I’ve talked about this at length and I will happily excise any comments that get into #noestimates.

Most of my work these days is helping organisations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.

Over the last year or two I have been exploring OKRs—Objectives and Key Results—with several organisations, from a few hundred people in size to a couple of thousand. Some are well over a year in, some are just starting out. There doesn’t seem to be much out there in terms of experience reports or hands-on advice so I have tried to capture the advice I wish I’d had when I started out.

tl;dr ¶

• I like JUnit. It is simple and clean, and it is ubiquitous in the Java world.
• I like Go’s testing package. It is even simpler and cleaner, and distinguishes between failed checks and fatal test failures. It doesn’t use exceptions to do this.
• I wanted to see what Go’s testing semantics would look like in JUnit, so I wrote JGoTesting. Some people helped me.
• I’m quite pleased with how it is turning out so I want to share it with you.