DRY/OOAO(‘once and once only’)/(full-)factoring is realising similarities, relations, patterns, in code – expressing with code, understood structures.
This is good because it makes perceptible/recognisable structures manipulable. But there is a detraction: each factoring, each realisation of pattern, by adding another abstraction, adds complexity.
And the problem is that there is no upper limit, generally, on possible abstractions – there is always a new way of seeing things, largely because there are always other new things to compare and relate to – it is always possible to see some other kind of structure that the code half represents that perhaps should be properly factored out. So the guidance of ‘dont repeat yourself’ / ‘once and once only’ / fully factor cannot simply be maximised – there must be some limit put on it. Otherwise it would unendingly add ever more complexity.
• • •
Also, simple non-factored repetition has a robustness.
A house made just of bricks is non-factored (in that sense): it just repeats the elements. But this allows easy modification of local areas. It imposes no favoured or difficult direction or areas of change. Real change – change against what you originally thought – is easiest in general with non-factored structure.
This is because factoring (abstraction) is dependency. The more factored, the more dependencies there are across the structure. When a perceptible structure is made manipulable, by factoring (abstraction), there is effectively a kind of articulation or ‘amplifying’ of control over a larger structure. And so that larger structure, its parts, are dependent on the factoring.
• • •
So how much ‘latent’ structure (simple stacks of bricks) do we want, and how much ‘realised’ structure (factored into abstractions)?
The answer is that we should realise exactly and only the structure we need for the particular project. Then each abstraction is doing a job and not just uselessly obstructing.
It is being clear about the bounds of ‘knowledge’ – having a strict meaning for it. DRY says each piece of knowledge should have only one place, but the important thing is what counts as knowledge. Knowledge is not what could possibly be interpreted into the code – it is what is truly known in this case, for this project.
And by getting the ‘realised’ structure right, the ‘latent’ structure is made right too. They are complimentary (not antagonistic, nor sympathetic). By not overburdening the structure with abstractions, the non-factored structure is maximised – that is the amenability to real change is maximised.
• • •
This indeed fits perfectly into eXtreme Programming. The technical core of eXtreme Programming could be seen as two-fold: 1, embrace change: the cost of change does not rise much over project life – “This ... is the technical premise of XP”; 2, simple design: only what is needed, nothing predicted – which is a way of working with or taking advantage of 1.