The thinking behind CUPID isn’t hard to understand; when we develop software, we should consider the needs of those who access our code in future. That means they should find it easy to understand, develop and navigate. Or, as CUPID creator Daniel Terhorst-North would say – it should be joyful.

We were lucky to have Daniel Terhorst-North join us for a webinar recently, where he shared his thoughts on how CUPID can help developers, and what SOLID developers especially should know about CUPID development.

What are the key properties of CUPID, and do you think they are a good fit with how we develop microservices now?

At an eXtreme Tuesday Club meetup I was asked what I would replace SOLID with, if I didn’t like those five principles. I suppose that made me ask what are the common features of good code? Are there any universal principles or rules we should follow?

One useful heuristic is that if you’re writing code, you’re writing for other people in the world, and you need to have empathy for them. A number of folks have told me they’re using CUPID almost as a filter for existing projects; that CUPID gives them a vocabulary. When they started, nothing was composable; everything was written to tie into something else and it was a spaghetti of dependencies.

Someone told me they are using CUPID for a code review, or an application review in a big, gnarly system. They’re using CUPID to come up with a plan of action. I thought that was a really cool idea. It’s a case of asking how we move this code base to have more composability, that has more of that Unix philosophy of doing one thing, and does that thing well? CUPID might not give you the answers, but it’s a lens that helps you ask better questions.

Kevlin Henney did a similar deconstruction of SOLID and came up with FLUID as an alternative. What are your thoughts on that?

Kevlin was the editor of the 97 Things series, and I contributed something about writing code that’s nice for humans to read. He gave me some lovely, positive, constructive feedback about what to do with CUPID.

It may be that some ideas in CUPID and FLUID are the same, but I didn’t dip into that. There are no specific sources for CUPID, or I would cite them. I’m always very careful because I see this happen a lot, especially to women. Someone will always say, “Oh that’s very similar to this thing from the 1970s.” And it might have a passing resemblance, but they are trying to diminish someone’s contribution. Short answer, no, I didn’t lift anything from FLUID, but I’m a massive fan of everything Kevlin does!

How do you respond to the view that some individual properties of CUPID, like predictability, can be harder to apply than others?

One of the things I’d say is that as I was choosing these properties, they are deliberately framed in a way that is layered and nuanced.

If someone who’s new to this whole world asks what we mean by predictability, we say it’s something doing what you think it’s going to do, right? There are ways of checking that it does what you think, by little automated tests or examples. You can measure it as you go. You can check that by writing little automated tests or examples to guide your design; that’s a good way to know what it’s going to do.

I can look at the predictability of a function, but then I can look at the predictability of a component or a subsystem or of an entire application. And I should be able to reason about all those broader pieces based on the lower levels. If I have unpredictable components to begin with, then when I put them together, there’s no way I can build a predictable system out of that, or it’s very, very challenging.

Why is idiomatic code important to you?

When you’re talking about idiomatic code, what you’re really saying is I want you to write code that’s just like everybody else’s. But maybe I have a big ego. I’ve written a lot of stuff and I want people to see my code and say: “Daniel wrote this software, isn’t he awesome?”

But that’s the opposite of useful. It’s not just about popping ego bubbles, it’s about getting work done. If we’re moving towards small component-type architectures then what’s likely to happen is that smaller groups of people work on individual bits, or two or three people work on a particular microservice. If we all don’t have a shared way of doing stuff, then every time I look at another piece of code, it’s like joining a new company. I’ve got no reference points. That’s what the idiomatic property is about, this is really about reducing cognitive load by making it easier to think and reason about unfamiliar code.

Want to get the full story of CUPID’s development?  In this video Daniel Terhorst-North is joined by Equal Expert’s Marco Vermeulen and Natalia Oskina for a wide-ranging conversation about how CUPID was created, and how it can be applied in a modern development environment.