Pattern 5: Gradual stiffening
AKA: AGILE PROCESS

You are managing the project using the discipline of TIMEBOXES (4) and you have ESTABLISHed THE USE CASES (3) in the context of a BUSINESS PROCESS MODEL (2) and a set of fixed, prioritized objectives. However...

The requirements and use cases may evolve during the lifetime of the project. How do you respond to such developments? Should you adhere strictly to the original plan? If not, what is fixed and what should be allowed to vary?

Therefore

A web site development project should start with loose design but clear business objectives, defined use cases and types and a sound project plan. Allow the site structure to stiffen the design only as the site unfolds and only completely towards the end of the project.

Taking the core ideas from XP and the patterns we have already encountered suggests the following iterative approach to site development.
1. Write tests based on the use cases.
2. Write the minimum HTML and other code to pass the tests.
3. Deliver the site to USABILITY TESTING (7).
4. Release the site and solicit feedback.
5. Modify the tests as necessary.
6. Refactor the code and add new features.
7. Go to step 2.
Remember that the business objectives and priorities must remain absolute fixed points. Stick to the timebox plan already agreed. Ensure that every use case supports at least one business objective and that every business objective is supported by one or more use cases.

Now draw an outline SITE MAP (12) and ensure that it conforms to the type model. Create a nice HOME PAGE (28). USER-CENTRED SITE STRUCTURE (13) is also indicated.

Reviewers and sources
Frank Buschmann, Kevlin Henney, Nora Koch, Oliver Vogel, Uwe Zdun

This is a process pattern of generality applicability but one all too often forgotten by web designers - which is why it is included in wu.. It is a very, very minor modification of the one due to Alexander et al. They recommend the following procedure for building houses.

"The fundamental philosophy behind the use of pattern languages is that buildings should be uniquely adapted to individual needs and sites; and that the plans of buildings should be rather loose and fluid, in order to accommodate these subtleties...
Recognize that you are not assembling a building from components like an erector set, but that you are instead weaving a structure which starts out globally complete, but flimsy; then gradually making it stiffer but still rather flimsy; and only finally making it completely stiff and strong."
(Alexander et al, 1977, pp. 963-9.)

In the description of this pattern the reader is invited to visualize a 50-year-old master carpenter at work. He keeps working, apparently without stopping, until he eventually produces a quality product. The smoothness of his labour comes from the fact that he is making small, sequential, incremental steps such that he can always eliminate a mistake or correct an imperfection with the next step. He compares this with the novice who with a 'panic-stricken attention to detail' tries to work out everything in advance, fearful of making an unrecoverable error. Alexander's point is that most modern architecture has the character of the novice's work, not the master craftsman's. Successful construction processes, producing well-fitting forms, come from the postponement of detail design decisions until the building process itself so that the details are fitted into the overall, evolving structure. Another characterization of the process talks about visiting the site with the client and, after discussion just placing stakes where the corners of the house will be and heavy stones to mark the entrance and perhaps windows. Detailed decisions. Such as where to channel the electrics, will be made much later in the project by the appropriate craftsmen- again in constant consultation with the client.

We think that software and web site design should be like that too. It is also a stance remarkably similar to that taken by the proponents of eXtreme programming.

Beck (2000) introduced the set of ideas called eXtreme Programming (XP): a method that emphasizes frequent delivery of tangible, working results. Beck called the approach extreme because it attempts to take commonplace good ideas and apply them aggressively. For example, as he puts it:

• If code reviews are good, review code all the time (pair programming).
• If short iterations are good, make them really short (hours not months).
• If testing is good, then everyone tests all the time.
• If simplicity is good, then build the simplest thing that could work.

It is an implicit principle of XP that one should listen to the business all the time. However, some particularly extreme advocates of XP take this to mean that there is no need to establish the requirements before coding: 'all that matters is the code!' These people take the view that if you get it wrong you can change the code easily, so why bother. This is wrong for two reasons. First, misunderstood requirements may not bite until the development team has moved on to other projects. Secondly, it is hard believe Beck when he tells us that developers with 'ordinary skills' can make it work - contradicting Alexander's view on the craft nature of good design incidentally. Take the example of a very widely reported success story for XP - at Chrysler. In this case there were very considerably talented people on the team (including Beck himself). Furthermore, the project followed on from an earlier, failed project and many of the team from that project were used. It is inconceivable to me that these very experienced people did not have a good grasp of what the requirements were before the project started. XP is an excellent way of building systems and all its techniques are useful. However, it must be accompanied (not necessarily preceded) by sound requirements engineering techniques. Another important and useful techniques advocated (though not invented) by XP is pair programming. The idea is that no one person ever writes code or designs alone. One person sits and develops while another watches, thinks and comments. The two then swap around. Furthermore, the pairs are not permanent and anyone may (and will) alter someone else's code. This sounds as though it should halve productivity but, curiously, all the studies that have been done indicate that productivity doubles - or better. There may be some doubt if this will work on very large projects of course.
Taking the core ideas from XP and the patterns we have already encountered suggests an iterative approach to site development. This process starts at the lowest level, that addressed directly by XP, with coding. An agile process will almost certainly benefit from extreme ideas at this level. The good ideas include process hinted at in the illustration of Figure 5.1 [refer to book]: write tests based on use cases, write the minimum code to pass the tests (perhaps working in pairs - but you don't have to!), check the code in and run the automatic test harness (this is essential), run usability tests (this is forgotten by most XPers), review with the user(s), refactor, and iterate. Agility implies that this is done in very short cycles, perhaps measured in days.
Such an approach implies that the team has mastered good specification and design techniques, perhaps such as those of Catalysis (D'Souza and Wills, 1999) or UML Components (Cheesman and Daniels, 2000) for more complex server side projects. It also implies that sound refactoring methods are fully understood. The team will have read and absorbed the techniques in, say, Martin Fowler's excellent book on the subject (Fowler, 1999). However, in a COM or Java world, refactoring implies a lengthy build cycle. Suppose that the change affects a complex web service offering or, worse still, an application deployed on a mobile device. Users may not be prepared to tolerate the delay or service interruption. In an interesting development MetaDyne (www.metadyne.uk.com) has shown how to address this problem and really make XP work in such situations. They found and patented a way of doing Smalltalk-like dynamic binding in a distributed Java environment, so that (if well designed to start with) incremental changes can be downloaded as separate components without taking the application offline. I'm afraid that without this kind of technology XP will probably remain a minority pastime: the province of top class developers only.

Leaving aside the issues surrounding refactoring, responding to user reviews implies a readiness to embrace any changes requested. How can this be managed without deadlines slipping? Here we get to the stuff that the more ostrich-like XPers can't see. DSDM (Staplton, 1997), in common with most iterative processes, imposes project discipline with time-boxes (and other consequences of its 9 principles). This strategy implies that the development team has to negotiate with its customer about which features will be dropped in order to accommodate the requested changes. DSDM recommends that its MoSCoW classification of features is the basis of such negotiations, although many of our clients have faced difficulties in trying to convince users that any requirement isn't an M (must have), as we have already pointed out. We prefer a numerical ranking. But what do you rank: use cases? Clearly not, because the review will often reveal new and changed use cases as businesses evolve.
There must be some fixed points to base the negotiation on. In the first place we can regard the specification as fixed during very rapid cycles of a day of two. But some reviews will imply changes to the spec. The specification should therefore evolve at a slower pace, perhaps in two-week cycles. But still we need fixed points for the duration of an entire project; otherwise the time-box discipline will fail utterly.

Iteration speeds up with representation
Our solution has been to fix absolutely the business objectives and their relative priorities at the outset of projects: changed objectives imply a new project. This suggests a much slower iteration rate of perhaps 6 months or more. Note that hardly any published method says anything about these business objectives. In RUP (Kruchten, 1999) they are subsumed in a 'visioning' statement and are given no particular structure. The very phrase 'use case driven' suggests that the use cases are the starting point. No! Business objectives are the key fixed point in any project. Of course they are related to the use cases in the sense that a use case may support one or more objectives (if it doesn't you're doing something very wrong!) but they are quite different in kind from use cases.

The speed of iteration increases in proportion to the tightness of the representation. A business objectives and use cases model can lead to many specifications. A specification can be designed and coded in many ways, giving what mathematicians call a 'representation'. The transformation from loose to tight representation is characterized as the selection of a representation 'functor'. In mathematics every representation functor has an adjoint 'forgetful' functor which, literally 'forgets' the details of a particular implementation but preserves the invariants of the specification. If you're not a mathematician ignore the jargon; this is just a metaphor. But it does provide a framework for the management of iteration and emphasizes the rôle of traceability in a good process.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites