Humane Interfaces: Fowler vs. Harold

Today I noticed an interesting exchange between two of my regular reads: Martin Fowler's blog and Elliotte Rusty Harold's Cafe au Lait web site. I respect both of the authors for their interesting view points which spark many an interesting thought, but on this occassion Elliotte has disappointed me.

Martin was discussing the value of what he terms 'Humaine Interfaces' - software interfaces which are designed to provide the methods you need with names that are easy to remember and type. Apologies for my explanation which is probably an oversimplification.

Elliotte comes in with an unsubstantiated expression of disapproval and claims that simplicity is key, and that too many methods is a bad thing.

Well in short, I disagree.

Do more methods automatically mean more complexity? No, they allow the methods to provide a better reflection of the underlying intention. Martin gives an example of the Ruby code:

anArray.last

compared with the Java:

aList.get(aList.size - 1)

Martin comments that the former is simpler to use, whilst Elliotte says that it presents a larger and therefore more complex API to use.

My view is that there is nothing to be lost by providing alternative and more specific methods within a class to deal with specific cases that users may require. The user of a class doesn't have to understand or memorise every method in order to use it. Scanning through method names isn't a chore as long as they are presented alphabetically. There are no significant processor cycles wasted by only using 2 out of 78 methods of a class.

Getting into the detail you start to see some real valuable reasons for using a more specific method rather than applying a more minimal set of methods to a task. In some implementations of a list, getting the size of a list, or getting the last element by it's index number might be very expensive, whilst a dedicated method for getting the last item may be able to be optimised in some useful way because it represents a special case.

It also avoids some of the silly mistakes that you get from forgetting whether to use:

aList.get(aList.size) or aList.get(aList.size - 1)

Of course there are no perfect answers. Being required to provide 78 methods to conform to some interface standard could be extremely frustrating, so I wouldn't advocate it for abstract methods / interfaces. Similarly, there's no value in having a rag-bag mix of every method name the author thought of over the last 3 years of development - the methods should be there for a good reason, well named and suitably documented.

Finally, if I'm going to agree with Elliotte at all, I guess I should express doubt in the value of method aliases. One of the values of Java over C is that it provides fewer ways of expressing the same thing. I can't see any great value in having two methods with different names that do exactly the same thing. In a collaborative project it would inevitably lead to situations where code confusing uses of both method names for no apparent reason. On the other hand, aliases in the method documentation would be good, e.g. you look for a method length() and it says "see method size()".

ITNow: XP, Agile or set in stone?

I've just received the latest edition of the British Computer Society's Journal ITNow (formerly called The Computer Bulletin). I confess that I rarely read it, but this month had an article on XP which caught my attention, so I thought I'd take a look. Unfortunately it was a bit of a disappointment, as was another article under the category "the future of computing".

To XP or not to XP?
The article on XP (eXtreme Programming) is primarily a disappointment because it is supposed to present two opposing views, but the first view is a fairly loosely written advocation of the use of CM (Configuration Management) with Agile methods, whilst the counterpoint view is a very robust criticism of XP (far too robust in my opinion). To someone unfamiliar with this area it would be easily to miss the fact that XP is only one Agile method and it would be a surprise to then discover that the author of the counterpoint—Matt Stephens—is actually an agile practitioner who's views may well coincide with the author of the first view.

I then turned over a few pages to find an article entitled…

A new approach to business computing

I'm sure I'm probably missing something here, but this article seemed like something that might have been better entitled "An historical look at computing". It seems to present a long explanation of how networked computing and increased computing power enable fully automated real-time processes. It then goes on to suggest a single iteration waterfall approach to software development, e.g. to quote: "design, engineering spec., build, operate". Somewhere down the line he seems to have completely failed to recognise the existence of "change" and the fundamental fact that "design, build, test, crash, fix, test, crash…" is actually a very suitable model for software development (where a crash is a very fast and low risk operation) compared with airplane design where a crash is a massive cost in time and money.