Adventures in Geekland

Support Languages

My current fascination with support (and incorporating Agile approaches into support processes), suddenly chimed with the MPS system (from JetBrains) that Martin Fowler was talking about.

The basic unit of business value is the Story. Stories are written for all functionality, but they can also be used for issue reporting. The process by which a defect is reported can often be poorly communicated, leading to unclear (and therefore unreproducible) issue reports.
Issue reporting would benefit from pairing (all issues could be written up jointly by reporter (the customer) and support analyst. The offspring from this pairing would be a well written issue story.

Can we provide any tools that would allow this story to be written in an effective way? It seems to me to be an ontological issue - if we have a vocabulary which describes all aspects of a system, then we can start to write bug reports using that vocabulary. This language could appear very similar to the language used to describe functional tests. For instance [using Java and the Abbot framework] if you had written the following functional test (created during an early iteration of the software)


class LoginRequirement extends ClientFunctionalTest {
public void testSuccessfulLogin(){
LoginScreen login = new Login Screen();
login.enterUserName( "jim01" )
login.enterPassword( "password" )
login.clickLogin();
MainScreen main = new MainScreen(); //asserts that MainScreen is showing
}
}

you could express a reproduction of the bug in a similar way, albeit with indication of the failure points:

LoginScreen login = new Login Screen();
login.enterUserName( "jim01" )
login.enterPassword( "password" )
login.clickLogin();
/** @language = support
fail( new ErrorScreen("NullPointerException") );
**/

This has obvious limitations:

• a knowledge of Java is required
• a knowledge of the Abbot screen objects
• non-functional requirements can't be expressed easily (e.g. performance)
• knowing where to express environmental context (e.g. time of day, which version of software, IP address of client, etc)

We can generalise these issues:

• The story markup language
• Ontology of the application
• Issue-tracking related concepts

There are many possible story markup languages. Some will deal with distributed enterprise applications. Some will deal with rule based systems. Some will deal with user interface design. An "overdue library book" in the ontology can be expressed in each of these languages - by a database row, by a business rule, by a screenshot. The language used to express story cards uses all of these languages - and they should be linked together.

A general support language would be used across multiple applications and domains. A enterprise application language is useful to engineers. An EPOS language would be useful to retail system analysts. Linking these languages together would bring true domain driven design closer. Languages such as UML, Java, Junit, XSD, are just mechanisms for representating part of the ontology. Collectively this concept is known as meta-programming, or language oriented programming, or even literate programming.

As discussed above - bug reports use two languages - one for expressing user behaviour (I clicked the red button), and another for expressing issue context (On thursday afternoon, from IP w.x.y.z., as an admin user) and non-functional effects (took 2 minutes to respond).

The ontology is a shared domain model of the application. Different roles (e.g. users, developers, support engineers, business analysts, sponsors) within an organisation understand subsets of the ontology. Traditionally it has been very difficult to share different views of the ontology across these roles since different roles use different languages. For instance, how do you link a story card written in Word to an area of functionality in the code, in such a way as this link can be maintained over time. How do screenshots relate to runtime behaviour?

Here's an example story: Jim sees a fault while scanning in a returned DVD. Imagine a system that tracked the user actions that had occurred, and generated a bug report in the same language in which the business story was written (e.g. a bug report written in Abbot, as above). This bug report could be easily (manually) transformed into a functional test that could be run against new builds of the application.

By allowing defects in the application to be expressed in higher level languages, we can support this example. We might add elements to the bug report:

• Rules (expressed in a rule language) that matched the DVD code (is it a 3 day rental, does it have any related offers)
• DB scripts invoked (SQL)
• The DB script would relate to some object/relational layer, so the referential integrity violations could be expressed in UML (or some textual equivalent).
• A representation of the current UI (either as a screendump, or by inspecting UI component states)
• The path through the application so far could be expressed as manipulation of screen objects (like in the Abbot example).

All this will provide better information than a simple Java stack trace or core dump.

If these ontological elements are stored as part of the defect, then we can start annotating ontological elements in the model with multiple defects. For example, we may index defects by the stack trace reported, or we may search for defects depending on which button was last pressed, or which table is updated.

There are some trade-offs to such an approach

• the mapping of state into multiple representations will have some impact on raw performance of a running system
• there will still be issues which are caused by defects outside the current ontology (e.g. power failure).
• Tools that support the whole ontology must be available to all (or else the bug reports are going to be pretty abstruse)
• A support language to be generally applicable will be complex to write (although languages can evolve over time as requirements arise)

posted by Nick Drew @ 11:33 am 0 comments

Support

Nouns...

A military operation (often involving new supplies of men and materiel) to strengthen a military force or aid in the performance of its mission (Example: "They called for artillery support")

The act of bearing the weight of or strengthening (Example: "He leaned against the wall for support")

Aiding the cause or policy or interests of (Example: "The president no longer had the support of his own party")

The activity of providing for or maintaining by supplying with money or necessities (Example: "His support kept the family together")

Any device that bears the weight of another thing (Example: "There was no place to attach supports for a shelf")

Supporting structure that holds up or provides a foundation (Example: "The statue stood on a marble support")

Something providing immaterial support or assistance to a person or cause or interest (Example: "The policy found little public support")

The financial means whereby one lives (Example: "He applied to the state for support")

Financial resources provided to make some project possible (Example: "The foundation provided support for the experiment")

Documentary validation (Example: "The strongest support for this view is the work of Jones")

A subordinate musical part; provides background for more important parts

Approaches
Being in support feels a bit like a David Attenborough monologue:

"Here, at the arse end of the software lifecycle, evolution has reached its pinnacle. Selection pressures are so intense, that there is no niche left into which to mutate. Exotic creatures throng and thrive in complete darkness. It is a world untouched by progress"

I've been looking for ways of dealing with the issue of support and maintenance of software in a commercial environment. This blog has considerable insight and has a colllection of very good links to other good discussions.

The key issue as I see it is that support deals with issues that have two important properties: they are business critical, and unpredictable. Any issue that has these two properties is almost certainly to be treated in a "hand-to-mouth" manner - e.g. resources are allocated to deal with the issue without significant planning. After a while of living like this, the support organisation becomes resistant to change since changing the "process" is percieved as high risk. It is not possible to change the fact that someone will be screaming down the phone when the system stops delivering business value, and it seems that conventional support processes are designed to reduce the impact of a screamer.

Another aspect of being in a support organisation is that by definition, one is always dealing with defects. This leads to a somewhat warped view of a delivered system, and a subsequent tacit hostility towards the original development organisation. This is particularly true when members of the support team are not involved in the development process. From this, one may create a hypothesis that better integration between development and support personnel would improve the "bravery" of the support process.

I haven't even begun to understand all the issues related to maintenance. I recognise that, as developer, I have placed delivering functionality (and maintainability of source code) over maintainability of the system as a whole. It is time for me to address this personal deficiency.

One of the idioms in Agile development is the phrase "If X is so good, let's do X all the time". This applies to testing, code reviews, planning, etc. Let us, as developers, now see how we can incorporate support and maintenance issues into the development process.

posted by Nick Drew @ 2:25 pm 5 comments