Cost-reducing interfaces should be the focus
Posted by Tom Moertel Thu, 08 Dec 2005 22:35:00 GMT
I have been following with interest the debate about “humane” vs. “minimal” interfaces, sparked recently by Elliotte Rusty Harold’s response to Martin Fowler’s HumaneInterface post.
Harold writes:
Martin Fowler’s a really smart guy, and he’s pretty reliably right; but today he manages to get it 180° wrong. A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good. Simplicity is a virtue for both users and implementers. There’s simply no reason for 78 methods in a basic List class.
The problem with Harold’s argument is that he is using the wrong goodness metric. His metric is interface complexity when it ought to be overall cost.
Cost is what counts. If adding methods (or making any change, for that matter) reduces the overall cost of getting legitimate work done, it’s the right thing to do. That’s all there is to it.
Yes, adding methods to a library increases complexity and thus increases the cost of understanding and using the library. Adding methods to a library means asking users to make a small investment of their time and mental capacity in exchange for the promise of a later return – clarity and code savings. The duty of a library designer, then, is to make sure that this return is worthwhile, that the additions are useful enough and used frequently enough to pay for themselves.
In a later post, Harold implicitly acknowledges the does-it-pay-for-itself test when he lists some methods from Ruby’s Array class that he thinks are unjustified. He writes:
Do you really need any of [these methods] getting in your way? Possibly you need one or two of these methods; but how often, and how many?
The thing is, I use many of the methods he lists. Further, the ones I don’t use don’t seem to get in my way. In sum, those methods have paid me back far more than I have invested in them. Given this, why shouldn’t they be in the Array class?
I’m not saying that “humane” interfaces are better. Rather, I’m saying that focusing on “humane” vs. “minimal” is missing the forest for the trees.
Cost is what matters, so why shouldn’t it be the focus? Who cares if that focus leads us to a “humane” interface one time and a “minimal” interface another? With cost as our guide, we’ll always arrive at a good interface.
Posted in programming
Tags cost, humane, interfaces, minimal, programming
4 comments
no trackbacks
readers
