SJS's Journal: Proactive versus Reactive coding philosophies.

One of the ways to divide the programming community up is to consider the role of proactive and reactive coding philosophies. That is, do you look ahead and try to guess the sorts of changes that you may have to make in the code, or do you worry not at all about such things until the time comes to actually make the change?

Critics of the proactive approach (and generally proponents of the reactive approach) often sneer when asking if it's actually possible to see the future. Crystal balls are a favorite metaphor. Eventually, someone talks about "programmer efficiency" and the "inevitable" requirement to 'back out' a generalization or an abstraction.

Critics of the reactive approach (and generally proponents of the proactive approach) scoff at intractable codebases and point out that rewriting everything is only suitable for trivial problems anyway. The phrase "highly coupled" may be heard.

Like most things, a balanced approach is probably best. Somewhere in the middle -- where we peer into the dim future with the lenses of past experience to choose a path (but not rails).

I believe that one's experience has a strong effect on which stance we generally disapprove of least. If we've been burned by Process, or vacillating customers, or non-existent requirements, we're going to have less objection to the looser, more reactive approach. If we've been burned by trying to maintain code written by people who know they won't be the ones to maintain it, and who eschew structure in favor of "make it mostly work then ship it", we're going to have less objection to the more constrained, deliberative approach.