Collaboratively Testing Enterprise Management Webware

Montréal.
It's a day of keynotes today, but for the last one we're back in the smaller WikiSym 2007 setting, for a talk by the inventor of the wiki, Ward Cunningham. He is also a pioneer in software design patterns research (the field for whose uses he invented the wiki, of course), and in what's called agile software development, however. He begins by noting that wikis are ultimately an exercise in simplicity - focussing on some very simple processes upon which large structures such as Wikipedia can be built.

There have been some studies recently on what happens in human brains as questions of trust are considered - a study published in Science, for example, used PET scans to examine what parts of the brain were exercised in two participants in an economic exchange trust game. Over time, this found, such patterns changed, and trust responses took place more quickly. Trust-based systems therefore need to be built on repetition and feedback, even if they transcend the simple rules and simple behaviours of the trust game. A wiki, for example, also has simple rules, but supports some highly complex behaviour. Software development, indeed, has complex rules and complex behaviour - and additionally, complex behaviour is often undesirable: simple solutions should be pursued.

In the Wiki Wiki Web, there exist feedback loops at many levels - for example at the text formatting level, where text is encoded through wiki markup, transformed to HTML code, and rendered by the browser; there are possibilities for errors at each of these stages. In programming, too, the agile software model allows for feedback loops at many levels; the icon for extremely agile programming is the unit testing programme JUnit (or now XUnit, across multiple languages), which reports back on the quality of the code subroutine being tested. In the process, software developers create almost as much code for the testing software as they do for the software project itself, but this is a worthwhile investment, as the resultant software can be designed more quickly and reliably than it can under other models.

To satisfy more people than only developers with such models, it is necessary to enlarge the loop, and Ward developed the Fit system for integrated testing for this purpose. This assumes that there are people outside the programming community who know what results they want and can check the Fit output. A new system called Swim operates in a similar fashion, and takes a simple table as its input. What Swim and its Process Explorer tool (as well as the Fitnesse tool for Fit) allow for is to create a community-focussed environment.

Further, the Eclipse Foundation Portal is a project to extend the agile boundary to an enterprise level, to develop and test the organisational processes for programmers and others developing the Eclipse software. A problem with such projects is that they lead to a multiplication of Web forms requiring users to enter more and more information in more and more diverse formats and contexts, and Ward and his team developed a test which ran across the entire project to identify the forms used. This tracks what happens both in space (across different participants) and time, and can be presented in a two-dimensional matrix as a kind of process flowchart showing the actions of different actors as columns, and time as a progression down the page (which because of the way it looks is called a swimlane diagram in business logic analysis). This can be done for a large number of different use cases, and can be used to check the entire business process of an organisation.

Such Swim research forms the basis of an evaluation, and relies on the trust of users in the process; in non-Swim testing, commitment to testing is often quickly exhausted, and quality control suffers. What happens here, on the other hand, is output-side reasoning, as it studies the output, not the programme which produced it. Such reasoning has been difficult because of the complexity of programmes and processes, but the Process Explorer helps here - it expands Swim to become the basis of the community. Process Explorer adds an 'explore' option next to every form button, and finds every use case for that button - enabling the person exploring the use of a form to identify whether their specific use case has already been considered by the developers or not.

Is this system open enough to sustain a community, then? This requires us to examine the question of community itself. Wikipedia, for example, is an open community, but it is not fully transparent; the Eclipse Portal system is open and transparent, but not permeable: users cannot join the project and contribute. Ward now points to the Graffle experiment by Brian Marick, which provides a graphical representation of processes and from this produces an assessment of processes - Graffle operates as an alternative to Swim's model, but the two may be combinable. The idea is that the programme is made available to users, users can explore that programme using Swim, they can develop contributions, and through Graffle submit those contributions back into the programme.

Overall, then, trust in such collaborative development processes arises from repeated positive outcomes. Swim can be used to visualise use cases for complicated processes, using output side reasoning across space and time, and makes this process open, transparent and permeable. Graffle addresses such permeability as a complement to Swim, and together they can become a basis for more trusted programmes. The Eclipse Foundation Portal demonstrates this vision.

Technorati : Eclipse, Graffle, Swim, WikiSym 2007, collaboration, community, software development, wikis
Del.icio.us : Eclipse, Graffle, Swim, WikiSym 2007, collaboration, community, software development, wikis