March 9, 2004
Enablers and Problems
Martin Fowler writes about Software Development Attitudes, distinguishing between Directers and Enablers. That links nicely with something Ward Cunningham said about problems vs. difficulties.
As Martin says, some people like tools that force the issue, so you can't do Bad Things or ignore failures, and some people like tools that make new concepts possible. Then he says,
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.
Which, to me, maps nicely to Ward's view on problems.
A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.
And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.
To me, memory management is a difficulty. A fiddly task to perform because we don't after all have infinite RAM. It once took me three weeks to chase a memory smash in a (very well written) runtime library I was working with. Do I miss it? Hell, no. I think the same case could even be made for static typing. A good type system, such as the one I trained on, should help to focus your code and make it more expressive.
Posted by stevef at March 9, 2004 12:13 PM
I personally prefer the word "challenge" over the word "problem" when used in the way that Ward Cunningham refers to it. "Problem" can mean "challenge", but it can also mean "difficulty". Like when one says, "that's no problem", they mean that there is no difficulty in accomplishing something, not that there is no challenge.
It's Ward's term, and I think it's a standard term in the scientific community.
I think another challenge is how to present DirectingAttitude as an EnablingAttitude. My experince as an Architect has been that, when one is repsonsible for everything that is significant to an application, one has to take a stance and specify a direction even when one does not have a buy-in from everybody on the team. Presenting a decision as enabling can help in getting the buy-in.
You get me to think of my own experience with MFC (Microsoft Foundation Classes, now an almost defunct framework): at first glance, conformance to the Doc/View pattern really looked far-fetched and constraining. With some months of using the pattern, it clicked into a real stress-releaving and enabling solution. (Hey congrats on a great Weblog).
Dinesh: I understand your position, but that's a very difficult path to walk. You'd better be right and they'd better not figure what you're doing. Sometimes, it's best to let people make their own mistakes ;-)
Ignacio: Thanks. I'll always open to flattery ;-)
"It's Ward's term, and I think it's a standard term in the scientific community."
I seriously doubt that Ward Cunningham invented the word *problem*, but hey, you're entitled to your own opinion. :)
In the sense that he is advocating a problem as a positive thing, I would think that he might agree that the word challenge is a more positive, less ambiguous term.
The word "problem" can be ambiguous in many cases: "there is a problem", "the problem is as follows ...", "we worked on the problem for 2 days". All of these uses of the word problem can mean either difficulty or challenge. Using the word challenge just helps to clarify which definition of problem you mean.
I meant it's Ward's term /in the article/.