Rule-following and software development

NOTE HXA7241 2013-06-09T09:17Z

“This was our paradox: no course of action could be determined by a rule, because any course of action can be made out to accord with the rule.” – Philosophical Investigations 201a.

The ‘rule following’ ‘puzzle’ is soluble by appreciating what ‘rule’ means. It is really just this: rules are not exact.

And how could they be? The meaning of ‘rule’ is that it applies in various circumstances to various items. Essential to the very concept of ‘rule’ is some leeway. Rules are not wholly determined – it is not a puzzle, it is just what they are. Every ‘puzzle’ that might seem to appear is just an elaboration of misunderstanding that.

Rules might be nested: we might follow rules to decide how to apply rules, and maybe rules for them in turn – like “a complicated network of similarities, overlapping and criss-crossing”. That does not mean we have nothing, nor does it mean there is a puzzle: it means we have rules. And the whole sophisticated system just behaves with the essence of all rules: there is something fixed, and there is something flexible, open-ended.

(Crispin Wright: “How and when is it settled . . .” – it is never settled. “How is the once-and-for-all division . . .” – there is no once-and-for-all division.)

A rule is an abstraction.


To learn a rule is not to learn exactly every possible detail, it is to ‘find’ a groove that is already there.


To worry about ‘interpreting’ a rule, and that there seems an endless regress is to misunderstand what a rule is. It is not about specifying absolutely precisely. Rules essentially apply to various cases: if everything were exactly specified it would no longer be a rule.

It is like the question of, if every atom in your body is continually in flux, what is your identity?

But going down that route does not work. To suggest it would only make sense if everything were precisely atomically specified is really to say there is no regularity, no pattern, no structure, in the universe – that is, no way to understand.

There is regularity (in various, elaborate, nested ways). And that is what gives personal identity, and allows rules to be followed.


Whether you know you are following/applying the rule correctly is a separate question. The answer is, of course, you do not absolutely know. You can feel confident, for various circumstantial reasons, but some rules are defined by having external authority.


Rules can always be re-interpreted, so what is rule-following? Rule-following is just what you do until you re-interpret.

In software a program is a rule. We know from experience that software is never final. someone can always find a new reinterpretation of the requirements at some point and want something else.

Rules are not eternal. Rules are incremental, like software development. That is what rule-following means: following until it changes, then following in a new way. Following a rule is not ‘tuning-in’ to some platonic form, it is just using an abstraction at some moment.

Abstractions are not eternal. They suggest infinite extent – because the fixed part encompasses unlimited variations/instances – but that should not lead us to think they exist in some transcendent realm.


Software is a good explanation of rule-following; it can help resolve the perplexity. (Because software is made of nothing but rules – abstractions – that is all it is.)

Software is never finished, there is no final definition for some particular software, no final decision of what is wanted that could never be reconsidered. But this does not mean we cannot build any software at all; we simply build a version, then later change it, and so on again. We do not see the unfixedness, the lack of a final definition, as a fundamental block, a deep problem that must be solved. It is just software work.

Requirements here are language-games or rule-following, and software-development is philosophy or trying to understand what we do. Perhaps the difference is that software-development is closer to simply accepting what it is really doing. (Well, except the delusion tries to re-assert itself whenever someone wants to design an ‘extendable’ component: the feeling that it might be possible to make an abstraction that will never need changing.)