Encourage Experimentation

Context:

You're an experienced programmer working on a new project.

Problem:

How do you release and maintain a good product.

Forces:

The customer wants the product now

You want good code Where "good,' in this pattern, means easy to understand, easy to extend, and with the meta-versions of those properties (e.g. even after extensions, it's easy to understand and extend).

Design flaws You've been around the block a few times. You never get the object decomposition right the first time. You never get the functionality right in the first release. And every system you've ever worked on goes through horrible contortions to patch their code (and acquires cruft along the way).

Mental blocks A lot of times, people attach cruft to the code because "doing the right thing" seems onerous. One of the biggest mental blocks is that perceived effort increases exponentially with the number of objects involved. Moreover, perceived risk is super-exponential in the number of objects modified.

Mental Modes You switch in and out of levels of detail. When you're writing code, you're at the line-of-code to three lines-of-code level of detail. When you notice a problem, it's much easier, and more natural, to insert a piece of procedural cruft than to switch levels of detail and consider the object decomposition.

Solution:

Refactor before you implement (how's that for a brash statement). Use FacadeMementoStrategy at crucial points, so that, when you notice problems, you've minimzed the MentalBlocks (you either add a new strategy; no need to think about the object decomposition) or fix the existing object.

The goal here is to minimize the effort needed to tweak things. And the place to do that is, in many cases, before you notice the need to tweak. Make it a matter of habit, a matter of routine, to build a very flexible object decomposition before starting (where the code required is entirely boilerplate and can be typed in quickly and cleanly). This minimizes the effort required for changes and code experiments. Which pays off quite nicely (in my experience).

Related Patterns:

DesignShield (?)

Seems right. It is a specific version of a ShieldPattern that helps overcome mental blocks that a lot of programmers (myself included) seem to have.

Compare RefactorMercilessly. It seems that many object designs are sufficiently flexible without adding redundant FacadeMementoStrategy type things. Is there a simpler way than inserting additional objects to attain the necessary simplicity and flexibility? --RonJeffries

You got me. I'd disagree with the "it seems" part of your comment; I've seen large chunks of code that are both hideous and hidebound. But I also wouldn't claim that my experience generalizes-- I'm neither experienced nor wise enough to know what the general OO system looks like.

I'm also neither a methodologist nor particularly interested in claiming that this "pattern" is correct. Instead, I'm merely adding a data point to the discussions of methodology ("this is what I, and some other people I know, do"), wondering if other programmers out there play the same tricks on their brains, and (incidentally) pointing out that a lot of the discussions seem to talk about what's good in code and not so much about the psychology of coders.

WilliamGrosso

I think we might be closer here than you seem to think, William. "It seems that many" designs are flexible, but certainly not that they all are. If we can learn what makes designs flexible and inflexible without building in extra layers as FacadeMementoStrategy seems to suggest, the world would be a bit better place to be. I dunno ... --Ron