Tariff System

Developers: RobMee (coach), MarkMichael?, SteveWaga

Tariff System is a subsystem of a large Smalltalk/GemStone project at a major international container shipping company. Using XP practices, Tariff System was taken from inception to production in three months by a team of three.

Tariff System was a modest project. Still, it represented the fastest development of a subsystem in the almost three years this development shop has been delivering applications to production. It is unusually stable, and is very easy to maintain. The model is simple and the code is clean.

Perhaps the most valuable result of this XP experiment is the evidence that an enduring culture has been established among the developers. After deployment of the Tariff System, the team members were dispersed to other projects. Each of us took the techniques we had honed over the last several months and applied them to our new projects, and we continue to transfer these techniques to other developers.

Given the small size of the team, it is not surprising that we derived the most benefit from the development practices and somewhat less from the planning. The duration and size of the project seemed to us to obviate the need for tracking techniques. Here's a summary of how the XP practices worked for us:

UserStories. Initially we found it difficult to convince our users, who were particularly busy with other pressing issues at the time, to produce these for us. We took the approach (or perhaps the liberty) of writing and prioritizing a few of them ourselves. Upon being presented with these, the users were duly horrified and in short order took ownership, rewrote and reprioritized all of the stories.

PairProgramming. We did this almost all the time, and we found it extremely effective. The only time we questioned this practice was during UI layout sessions, which were tedious and repetitive. It was unclear in this case whether or not the partner without the keyboard added sufficient value to justify his presence.

DomainObjectGrammars. This practice is not intrinsic to XP, but was certainly inspired by it. In our efforts to refactor test cases and fixtures, we discovered that creating little languages for our major domain objects dramatically improved the readability and conciseness of our test code. We defined grammars for about ten of our domain classes. Here's a simple example used to construct a Service Offering:

newFromString: 'from Oakland to Tokyo shipping toys: 20ft containers $500; 40ft containers $1000'.

The constructor uses a parser (generated from a grammar) interacting with a builder object to produce the domain object. The equivalent code to instantiate this object using standard constructors would require many lines of code. (more to come on this technique)

UnitTests. Our UnitTests allowed us to code and refactor very aggressively. As we got into the groove of doing these in pairs (and what a groove it was) we really did write the tests first. We coded several hundred unit tests, all of which we ran many times every day. Though tests for GUI classes were harder, they're quite feasible using VisualWorks Smalltalk, and we did manage to get quite a lot of benefit from them. Yes, our parsers were subject to UnitTests too.

AcceptanceTests. The Tariff System describes services offered by the company, rates for services, and conditions under which rates apply. The information must be retrievable in various ways and for a variety of purposes. The nature of the tariff information is mostly declarative, so for our acceptance tests we composed our domain object grammars to allow users to input entire tariffs (many pages of text) in a readable format. All possible queries were run automatically against the input tariff and compared against expected results.

ContinuousIntegration. The small size of our team made internal integration nearly a freebie. Integration with the larger project presented more problems. In particular, the new tariff system allowed the wholesale replacement of a chunk of another subsystem, but we had to write a small layer of code to interface the two. Since one of our programmers was intimately familiar with the other system, he wrote (by himself) the integration layer, and didn't do our usual level of unit testing. The result was not suprising: this layer resulted in more production bugs than the rest of the system put together. We learned the lesson that when we drifted from our core practices we really felt a negative impact.

ModelFirst, LocalModel?, LocalGui?. We developed the domain model and satisfied acceptance tests before we attempted any UI. The model was developed entirely in VisualWorks, and later moved into GemStone. Also, we coded the UI to work with the local environment before we moved onto transactions, units of work,and persistence issues. The Tariff System can still be run entirely locally for test or demonstration purposes.

-- RobMee

Fantastic, Rob! Congratulations!

We took the approach (or perhaps the liberty) of writing and prioritizing a few of them ourselves. Upon being presented with these, the users were duly horrified and in short order took ownership, rewrote and reprioritized all of the stories.

I've also used and would recommend this technique in many areas other than just UserStories. It's one of the best ways of getting comments, feedback and input from busy people, IMO, as long as you try to write what you believe they would write, based on your current understanding (rather than writing stuff deliberately incorrectly to provoke a response).

If you get it pretty close, you had a good understanding and you've saved them time (and possibly saved you time as well - chasing for input takes time). If you're way off, that's a good thing to know!

-- PaulHudson

CategoryCaseStudy CategoryProject