Update: read Steve Freeman's follow-up

Many debates in software development are underpinned by whether the speaker has a DirectingAttitude or an EnablingAttitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.

Here's some examples of this dichotomy:

• A debate a while ago triggered by Joel's post on exceptions. He didn't like exceptions because they could be misused badly, leading to confusing code (directing). Bill Caputo pointed out that exceptions, when used well, make life much easier (enabling).
• Some of the static/dynamic typing debate brings up these points. Some arguments in favor of static typing talk about how they prevent people from making certain kinds of mistake (directing) while dynamic typers point out how static typing restricts some useful idioms (enabling).
• Agile processes are PeopleOriented (enabling), while plan-driven methods seek to ensure that even a poor team can do an acceptable job (directing).

These aren't hard-wired attitudes. Often people are directing in some cases and enabling in others. But I think there is a deep strain running through here, often a personality issue, that runs underneath much discussion on how we do software. (I'm very much in the enabling category, as if you can't tell.)

You might think that all restrictions on what a developer does imply a directing attitude, but it's not that simple. As an example, consider memory management. You can think of this as a directing feature: programmers can't be trusted to manage memory correctly so take away their ability to allocate memory. But I look at memory management as an enabling technology - it takes away something I don't want to worry about, so I can concentrate better on those things I do care about. Steve tied this thought nicely onto the difference between problems and difficulties.