Blog

The great thing about measuring developer productivity is that you can quickly identify the bad programmers. I want to tell you about the worst programmer I know, and why I fought to keep him in the team.

I found myself offering advice to someone recently who was giving her first technical talk, at an internal conference, that happened to be about a topic of mine. We agreed that I should share my answers with a wider audience, in case someone else finds them useful.

Whenever I arrive in a new context—a new client engagement or a new team in an ongoing gig—I seem to arrive right in the middle of something. A significant planning event, a technical design session for a major component, implementing a new productivity tool.

Phew, it looks like I am just in time! A few days later and they would have totally messed up that quarterly plan. They are going to use what technology to solve that? So much to do, so little time! It is fixable, but only if everyone stops what they are doing and listens to me right now!

Or maybe not. I want to share a couple of techniques that I have adopted over the years that have helped me to resist the urge to Fix All The Things.

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.