Software Principles

I have been contemplating the Don't Repeat Yourself (DRY) principle and started writing a piece around the difficulties of applying this principle within a multi-technology environment. My effort ground to a halt when I stumbled upon the following question:

What are the set of principles that I care about?

This is a relevant question because having identified duplication the DRY principle does not offer any guidance on how to resolve the duplication. The DRY principle therefore does not stand in isolation but rather is one of a number of principles that together form a cohesive unit. It then follows that application of the DRY principle will require deeper knowledge, skill and practice.

A second question that immediately follows the first is

Are these principles always relevant in all contexts?

So before answering the first question let's answer the second question as it liberates us to attempt a proper answering of the first.

Principles and Standards

When encountering a principle it is easy to fall into the trap that we need to rigorously apply the principle in a prescriptive manner. In my view this is treating a principle like a standard - forcing an execution and taking away the opportunity to consider relevance and appropriateness. It is necessary to keep in mind that principles and standards differ significantly in intention and application.

A principle provides high-level guidance on what should happen whilst a standard defines how it needs to happen.

So when confronted with a set of development principles please don't treat them like a standard. Always critically consider the principle and decide how this principle supports and enables both the functional and non-functional requirement. Applying a principle is an invitation to a dialog and a dialog is an opportunity for learning. Attempting to sell a principle to a team member is taking away this learning opportunity from both yourself and your team member.

Incidentally the requirement that I care about in the above paragraph is what a system currently does and the next user story that is being developed. Considering anything more than that smells a little like Big Design Up Front (BDUF) although I suspect that I might be applying a principle as a standard.

Principles That I Care About

How many of us believe strongly in a set of unwritten principles which we will defend with passion and righteousness. To escape this trap I would like to write down my set of software development principles so that:

  • I know what I care about and can show others,
  • I know how I care about what I care about and can show others,
  • I believe that this will make me a better craftsman, and
  • I believe that this will make me a better team member

I am under no illusion that this list and the evolution of this list will be a life journey.

Some Open Questions

The following are a set of open questions which I will need to answer as I progress along this journey:

  • What is the relationship between Values, Principles and Practices? How does this influence the whole?
  • Are all principles of the some ilk? Superficially I feel that principles are of different ilk - developer workflow principles are different to software principles are different to agile team principles are different to workplace principles. So then what principles am I interested in listing.
  • How does one document a principle? Does one use an architectural style or a narrative style?
  • Other than me - who will actually read this list? Knowing my audience is important as it directs the level of detail, style and examples.
  • Talking about a principle and the different ways of applying a principle is itself a weighty subject - how deep do I go and when is enough enough?