Disciplined Agile

Core Developer Skills: Code Qualities

What is “good code”? It depends on what you want from it. In the beginning of the software development profession, computers were extremely slow and expensive, and developer time was considered to be a less-critical commodity. Not surprisingly, we did whatever we could to make things easy for the computer to do, even if it made the system very hard for the human developer to work with.

This dynamic has fundamentally changed. Computers are fast, cheap, and software is therefore pretty much everywhere. Developer time is the primarily expense of most development organizations. “Good Code” today, generally, is code that requires less developer time to change, reduces the risk of change, and which will help the system to maintain its ROI for as long as possible.

Code Qualities

These are some of qualities of code that make for more flexible, maintainable, and extensible code:

  • Coupling. The connections between units should make sense and be manageable.
  • Cohesion. All the parts of a unit should be very strongly related to one another and, therefore, a unit should have a very limited scope of purpose.
  • Encapsulation. A unit’s visibility into the details of other units should be as limited as possible to prevent, among other things, accidental coupling.
  • Focus. It should be easy to find everything having to do with a single purpose.
  • Readability. Code should be easy for a professional, up-to-date software developer to read and understand.
  • Avoiding Redundancy. Anything that needs to be changed should be able to be changed in a single place.
  • Testability. How testable something is reflects on the quality of its design and implementation.


Knowing the qualities that define the nature of the code that you seek is useful, but we also need to know the underlying principles that will, most reliably, lead us to those qualities. Principles help to keep us aligned with qualities when unusual, unforeseen, and unfamiliar problems arise. Principles are general guidance about creating good software; there is no “end” to following a principle, you could always “do more,” but in following them generally we find that everything gets incrementally easier to change, scale, and extend. Some helpful principles are:

  • Encapsulate by policy, reveal by need
  • Open-Closed principle
  • Separate use from construction
  • Single responsibility principle


A practice is something we, as a community, have discovered is simply always a good thing to do. For something to be promoted as a practice, it must be truly universal (we can always do it, and everyone should do it). Therefore, it must be:

  • Easy to do. We don’t want to burden ourselves or slow ourselves down because of a practice.
  • Easy to teach. If we want everyone to do them, it should not be a burden to propagate their use across the entire team, organization, and the profession itself.
  • Highly valuable. A good practice should pay back over and over and over again.


Our profession is a young one, especially compared to others like the law, medicine, and so forth. However, we have enough history now to be able to draw upon the experience and wisdom of our senior members, those “grey hairs” who have encountered and analyzed many of the issues that confront us. Where we can, we should draw upon this wisdom, and then build upon it for those who follow us.


Wisdom applies generally, as principles do, but also in specifics ways when confronted by specific kinds of problems. When these specifics repeat, there is value in sharing the patterns that we discover, giving them names to make them more shareable, and thereby creating a professional vocabulary.

It is not necessary to learn all patterns; rather, it is more important to understand the principles, practices, and wisdom that underlie all patterns. 

May 2023