Some codebases are more user-friendly than others. This holds true for apps, services, libraries, frameworks, and even programming languages. Is this merely a personal preference, or are there universal software features that make coding enjoyable to work with?

Daniel has been thinking about this for a long time, especially since he poked fun at the SOLID principles a few years back and had pitchforks thrown at him. His recent post explaining why he thinks SOLID is outmoded made Hacker News’ first page!

CUPID stands for Composable, Unix philosophy, Predictable, Idiomatic, Domain-based, and it’s his own snappy five-letter acronym.

 

 

CUPID is a novel way of thinking about software design, thus Dan had to go over a lot of background material before diving into CUPID. Because I had to stop and chew over these underlying concepts and asides, it was a lot to take in. I’m writing this to assist me in doing so, so that I can examine how to apply his insights to my own beliefs about infrastructure code design. To expand on those ideas, I’ll publish a follow-up post to this one.

 

Let’s make code joyful to work with

Dan’s first novel move with CUPID is to give it the purpose of making coding fun. He borrows Martin Fowler’s phrase, “Good programmers produce code that humans can comprehend,” and takes it a step further by writing code that humans love reading and working with. Dan chose the CUPID attributes, which we’ll discuss later, since they’re useful in determining how enjoyable a programme is to work with. Dan’s first novel move with CUPID is to give it the purpose of making coding fun. He borrows Martin Fowler’s phrase, “Good programmers produce code that humans can comprehend,” and takes it a step further by writing code that humans love reading and working with. Dan chose the CUPID attributes, which we’ll discuss later, since they’re useful in determining how enjoyable a programme is to work with.

Using properties of a design rather than design principles

 

 

The second new aspect of Dan’s CUPID approach is that instead of specifying design principles, properties of a codebase’s design are considered. As a result, we must focus on attributes rather than principles. Properties, in Dan’s opinion, are:

“qualities or characteristics of code rather than rules to follow. Properties define a goal or centre to move towards. Your code is only closer to or further from the centre, and there is always a clear direction of travel. You can use properties as a lens or filter to assess your code and you can decide which ones to address next.”

What makes a property useful

We need to decide what makes a good property before we can list properties that make software happy. As a result, Dan moves on to the properties of properties. Dan aspires for the following properties with the CUPID properties:

· Practical: simple to express, evaluate, and implement.

· Read from the perspective of people (developers), not from the perspective of code.

· Layered: provide assistance for novices as well as nuance for those with more experience.

Dan goes into more depth about these in his book, so go ahead and read it. Now we can get down to business with CUPID.

 The CUPID properties

 

 

Dan defines five attributes, each of which is given a name to form the acronym for the set’s name, in one of the few ways he emulates SOLID. I’ll paraphrase what he says about each one (he’s promised to do complete posts on each one later).

· Composable: Works well in groups. Surface area is limited. Intentions are revealed. Dependencies are kept to a minimum. (This is really important to me when it comes to infrastructure code design.)

· Unix philosophy: Focus on one thing and do it well. A straightforward and consistent model. Single-purpose vs. single-responsibility: what’s the difference?

· Predictable: Does exactly what you anticipate it to do. Behaves in a predictable manner. Deterministic. Observable. (for example how can we incorporate observability into our infrastructure code and I should also make it a habit to write characterisation tests for my infra code.)

 · Idiomatic: It has a natural feel to it. (Avoid unnecessary cognitive stress.) Idioms are phrases that are used in a specific language. Idioms from the area. (I believe it’s difficult to write design properties without using prescriptive language like “Follow language idioms.”)

· Domain-based: In terms of language and structure, the solution domain mimics the problem domain. Language that is based on a domain. Structure based on domains. Boundaries defined by domain. (Another issue I’d like to think about more fully is how far current infrastructure code standards are from this.)

To know more about cupid for coding  contact info@vafion.com.

 

Similar Posts:

No similar blogs