CUPID - WHY EVERY SINGLE ELEMENT OF SOLID IS WRONG
SOLID is THE standard that comes to my mind when it comes to Guidelines of Software Design and Architecture. In March 2021, Dan North, a pioneered Software Consultant, wrote a blogpost about SOLID and it's downsides while critically analyzing it.
I found this topic when listening to an episode of the .NET Rocks podcast. Dan is good in describing things and he has an absolute fantastic humor.
He created a 5 minute presentation for an alternative to SOLID and the result was this slideshow about CUPID.
As SOLID was quite hard to apply and gave you specific techniques on how to do certain things, his new approach CUPID, he suggested as an alternative, aims to be 'properties' instead of 'principles' for the code you're writing. It seems much more easy to understand and doesn't give you strict techniques. In his words he gives a leightweight guide on how code should be to be 'joyful'.
In the mentioned podcast episode he gave the example that fresh software engineers coming from university applying SOLID to legacy production code will sometimes end in a mess because they're too enthusiastic about applying the technical rules, SOLID contains.
I know this problem very well because when I learned about SOLID, I sometimes found code that was not designed to follow at least one of the principles but it was well working code that had a structure that someone has thought about catchy.
If I would have applied the properties of CUPID, I would have seen the code with other eyes, I guess.
I see why Dan North rethought the SOLID principles. Not everything about SOLID is bad, that's why it proofed to be an unstated standard.
I, for myself, will try to apply CUPID to code I change and write because in my eyes it has the potential to be a new standard. Additionaly it is a lot easier to explain to coworkers, trainees and students.
I think it can bring even more joy to coding and thats what we all need so badly.