Software Craftsmanship
Software craftsmanship is an ideology, a mindset that building software is a craft just like building beautiful cars, furniture, art, etc. Initially, craftspeople would need to rely on engineering practices from extreme programming. Over time they would adapt to newer practices like object oriented design patterns, Service Oriented Architecture (SOA), Software as a service, Cloud, Microservices, etc. These new practices and ideas came up because there were some brilliant people that thought of software as a craft.
CUPID
CUPID is an acronym and according to Dan North in his blog https://dannorth.net/2022/02/10/cupid-for-joyful-coding/
is a set of properties. Properties should be easy to articulate, adopt and assess.
In this blog, I will share my understanding of CUPID and connect with it using something we already know. Connections make it easy to learn something abstract or foreign.
For learning CUPID I will use the example of assembling furniture (a bookshelf or a dining table) that you bought in a store.
(C) Composable
You drive to a furniture store and buy a bookshelf or a dining table. It’s not assembled. A manual and all the parts are available for you to put it together step by step. Each part that you add is composable. The composable property means it will have a small surface area (each part on its own is small), reveals it’s intention (You know where it will fit and why), and with minimal dependencies.
If each part of the software can be constructed in such a way that it’s easy to use and use again and reuse again, that software is composable. Many open-source libraries are designed to be composable.
(U) Unix Philosophy
Each part of the furniture has a single purpose and a consistent design. Each command in the Unix operating system is designed so that it has a single purpose. Unix is used by every serious computer maker and it underpins MacOS and android. It also comes as an optional subsystem for Microsoft Windows. Software should be designed with the Unix philosophy.
(P) Predictable
Each part of the furniture behaves as expected. The holes for screws are only on a particular side. The holes line up to be assembled. Software should pass all tests all the time. Software should be deterministic (do the same thing all the time). Software should be monitored and instrumented, meaning it can be observed. Another good example of being observable is when I was installing a Ring alarm system in my house.
Although each component was small and I had to use the manual to better understand how to set the alarm system, it was relatively simple. One reason for this was that each component would send a signal to the app on my mobile to tell me if I had installed it properly or if it had an issue that I needed to adjust. Of course, this enables the component to send alerts if a window or door is opened in my house to my mobile app.
(I) Idiomatic
Consider individual parts of the furniture had different conventions to indicate which way is up, down, left or right. This would put a high cognitive load on the person assembling the furniture. Similarly, if software code does not follow the language idioms and conventions it will put a high cognitive load on others who read that piece of code. The idea is you are writing code for others to read or maintain and hence the developer should spend the time to learn the language idiom and stick to it while coding in that language.
(D) Domain
Domain is broken into three sub properties
- Domain-based language: the parts of the furniture should look similar to another bookshelf or dining table parts. The code in your software should be easy to read and understand and should mirror the domain it’s written for. For example, if you are writing code for data distribution, it should be easy to discern the source of the date, the transformation of data, and the destinations by reading the code.
- Domain-based structure: How code is structured between the different aspects (User interface, database scripts, business logic, etc.) is important so that it can be easily discovered, read, and understood by anyone
- Domain-based boundaries: When there is a clear boundary in your code between the different domains (User interface, database scripts, business logic, etc.) it becomes easy to understand, know the responsibilities of each, and easy to deploy separately as needed.
How would you define Software Craftsmanship and how can CUPID help you?
Blog adapted from my learning from Dan North’s CUPID article
Scrum, Product Management, and DevOps: Simplifying the jargon
The internet and social media are full of Agile, Scrum, Product Management, and DevOps jargon, including incorrect and misunderstood concepts. This could be problematic for a learner seeking knowledge. Without a course with Scrum Alliance, Scrum.org, or DevOps Institute, this knowledge is difficult to achieve.
