When I show students in my classes a particularly bad design and ask them to evaluate it, they feel uneasy but very few have language to describe what is bad (or good) about a design. Without a common language that distinguishes good code from bad code we have little power.
Reviewing a design is like critiquing art. We can recognize what we like or don’t like but we often can’t describe what makes a design good. Without this kind of language it is very hard for teams to generate good designs and quickly gain consensus.
This is why I am such a big believer in code qualities. Code qualities are specific, easily identifiable features of good code; code that has stood the test of time and proves to be easier to maintain and extend.
I talk about six key code qualities but there are many more. I point out six because they are easy to see and often focusing on just them is enough to guide us to write good code. Of course, they are only guidelines and there are times when we want to abandon them, like for performance or security reasons. But most of the time code qualities are good to strive for when we write software.
I will describe these qualities in coming posts. They are all easy to understand and you are probably already familiar with them. However, when we use them the benefits are so great that it is worth keeping them top of mind.