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.

Getting Things Done

Perhaps I live in the dark ages, but somewhere down the line I’ve missed the “Getting Things Done” (GTD) movement and it appears with recent reading that I’m missing out, so I feel overwhelmingly obliged to read “Getting Things Done: The Art of Stress-free Productivity” by David Allen.

The final straw that lead me to this conclusion was reading one of today’s “Cutting Through” entries, “Prince 2, product and Getting Things Done”, which was about the 10th reference I’ve read to GTD in the last month.

Multi-platform VNC based automated testing

Following the automated software testing theme I've just run across Eggplant an automated testing package which uses VNC to remotely control and watch a computer system under test. This allows it to work across a range of platforms. It can even record movies of the test taking place for later review.

For those unfamiliar with VNC, it is a cross platform solution to controlling and viewing the screen of another computer across a network connection.

There are two issues. Firstly, they don't give any pricing away on their web site, so it could be ridiculously expensive, but that said they do claim it is "affordable", so there's a basis on which to beat them down! The other issue is that it only runs from a Mac OS X based system, so development teams without Macs may have to fork out an additional £500 to buy a testing machine. Given the price of some other testing packages, this may not matter much, and at least it won't required daily patching to render it virus free!

Automated Acceptance Testing

Yesterday I managed to get a long to the Agile Scotland meeting, here in Edinburgh which was looking at automated acceptance testing, and in particular, FIT and Extractor.

Although the talk was interesting, I wasn't entirely convinced by some of the points made.

The idea of automating acceptance testing seems extremely valuable. Acceptance testing is a chore and in reality the customer often fails to do it or to do it effectively. Indeed, in the worst cases the developer relies on the customer failing to do the acceptance testing properly! So, providing an automated tool for doing this testing allows the customer to fulfil their role with the minimum of effort, and provides the developers with a tool to guarantee that their code is up to the test, whenever they want to check it.

The distinction between unit testing and acceptance testing is a little ambiguous. Unit testing is distinguished in that it should be testing smaller units very quickly so that it can be performed as part of every compilation/build cycle. Acceptance testing should be testing the entire package (including the interface) to ensure that everything works together in the way that the customer expects. Acceptance tests do not have to be carried out all the time so they can take longer to perform. In reality a quick test that exercises the whole application would be a useful unit test, and automated acceptance testing is not always easy to do, so it is sometimes necessary to exercise units in isolation: perhaps bypassing the interface, or directly injecting data to provide as test input.

So one of the main advantages of FIT and Exactor is that they present the tests in a form that is more user-readable than your average bit of unit testing code. This allows customers to see and understand the tests as well as seeing and understanding the test results. In theory it also allows customers to write tests, but it was acknowledged that this rarely happens in practice.

Despite some of the ways in which the information was presented, it would appear that these acceptance testing tools are basically layered on top of jUnit, with Exactor being an abstraction of FIT to provide plain text entry of tests rather than using HTML tables as FIT requires.

My main concern is that this solution fails to acknowledge reality. If customers are not really going to write tests themselves, but may do so with the help and assistance of professional testers or developers, then it makes more sense to provide tools which automatically present automated tests and their results in a user friendly way, rather than asking programmers to use yet another entry syntax to code the tests. Having said this, I can see genuine value in the way that these tools enable customers to subtly amend existing tests directly.

Ultimately I think that Apple's scripting technologies provide a nice analogy that is worth looking into.

For many years Apple has provided end users with a scripting language called AppleScript which was designed to allow users (not programmers) to script and automated repeated or complex tasks. The language had a very plain English feel to it that made it easy to understand existing scripts, but gave the illusion that you could write scripts by writing plain English when in reality it was just as demanding of syntax and structure and was very bad at explaining your coding errors when you went wrong.

Apple is just about to release a new version of their operating system (Mac OS 10.4, code-named 'Tiger') which contains a new application called "Automator". This provides a GUI for building scripts which allows you to drag and drop linked operations in such a way that the interface will only allow you to link compatible operations and will only allow you to link them in a suitable order. It doesn't stop you doing pointless or stupid things, but it ensures that you produce a 'script' which works.

Automated Acceptance Testing involving the customer directly will really come into its own when the developer community spends the considerable time involved in making a friendly user interface that will hand-hold customers through the process and allow them to create and edit tests without having to understand any kind of syntax at all.

---

I almost forgot to mention that there was a reference made to Selenium - a tool for automated testing of web applications directly through a range of browsers. I haven't had time to look into how the tests are defined, but it looks very useful in principle.