Home of eXtreme Programming

Extreme Programming


Philosophy

Classic SDLC implies that all the documentation for Requirements, HLD, Structural Design, GUIs, LLD and the user documentation is complete before coding begins.

In classic SDLC the user is asked to accurately communicate their needs without having anything but complex dense English in front of them. Much of this contains technical terminology particularly those parts dealing with hardware and OS exceptions.

Users generally find it difficult to describe all the data validation and corrections procedures because an intelligent human being (a clerk) generally sorts those out on the spot in the paper office.

More significantly is the use of data names in the documentation many of which look like ordinary English words but which are actually being used as Proper Nouns. [Lawyers understand this and give definitions up front and then capitalise those words.] Most of us think that a legal agreement of 20 pages to be pretty oppressive ? in software our user documentation may be 1000 pages.

Note that we are generally writing one-off code ? certainly for the user. SDLC approaches (excluding when the customer is an engineer or similar) are actually just impossible for the user to handle.

Users also learn during software development. They begin to see that new things could be achieved and transist from implementing the past into re-thinking the future. In data-driven GUI environments this problem is attacked by RAD ? early demonstration of animated screens. This approach is part of Extreme Programming but much code is written at a systems or tools or component level and is too deep for a simple RAD approach.

In e-commerce environments the pressures to deliver new code quickly become even greater.  Top

Change Management

Change Management requires 3 phases: Hitting the wall; Deciding on the new way; implementing a new methodology.

In a software house the block will show up as late delivery and bugs detected in the field. These will first be attacked traditionally: heavy working hours; ?acceptance? that there will always be bugs; blaming everyone else (users change their minds, users are dumb, the analyst left some spec out) or it is just the ?state of the art?.

It is imperative to convince programmers that they are not effectively in control of the current process. Ensure all bugs have their causes identified: Not in spec, spec inconsistent; coding, not adhering to standards, etc. Bonus a count of the bugs (including all deviations from standards and documentation not consistent with the code) per KLOCS (1000 lines of non- comment source code). Bonus the delivery time measuring the time to deliver per KLOCS. Be prepared to close out the last few resisters by termination.

The second phase is to identify a solution. Begin by getting the coders to review all standards ? there will be long debate (best done by email discussion) particularly on tabs, naming conventions and when to use exceptions.

Change the terminology from Bugs to Defects.

Build examples of best practice. Have them displayed and discussed on one afternoon per week. Let these be selected by vigorous argument. Make standards documentation and best practice collection part of a job which is remunerated.

Select tools for coverage and CPU usage and have senior programmers use them and display their use.

Introduce Code Inspection (including against standards). Ensure that the results are documented.

The last phase involves changing people?s roles and titles.

Formally adopting the changed methodology and rebuilding the source control system and build scripts irrevocably commits the team.

It is my belief that Extreme Programming matches the New Zealand psyche which is comfortable about being a team player and expecting there to be room for individual flair ? which is acceptable provides it scores points!  Top

Who Is the User?

Data-driven GUI-intense applications can be more readily followed during RAD by users. However more complex systems involving systems level code, COM libraries, tool creation, are difficult for users to follow.

In this case a Nominal User may need to be appointed. Such a user should have substantial experience in code delivery to users; change management; install issues and the management of help desks.  Top

Extreme Programming

1. Rather than detailed specifications being prepared the programmers are asked to get totally familiar with what the User wants. This process should be intense, immersive, thorough - Typically with heavy use of whiteboards. The focus is on getting the programmer to really understand the user requirements and mind sets so that the programmer can read the users mind and fill in anything not stated but necessary to the task.

2. This requires that a User or Nominal User is always (every day) close to hand, ready to discuss any item with the developers, available to review GUI prototypes, sight all test data and produce scenarios and real examples at any time.

3. Don?t write specifications ? write business scenarios.

4. Least is best! The specifications should be razored to the max! Every requirement should be marked Essential, Deferrable, Marginal. This razoring process should be ruthless ? can we actually produce some code which a User can decide is useful (and correct) even though it may only be meeting, say, 80% (20%?) of the requirement. There should be a formal process of razoring the specifications with the user?s full co-operation. User buy-in is necessary. The user needs to help identify the focal requirements which will be useful immediately.

5. Dual specifications: If it is known that the code is to meet two application variants: be delivered in two languages (C# and C++), or run on both SQL-Server and Oracle then develop the code for each component and test in both options on the same day. Do NOT extend this to three options. Similarly for internationalisation.

6. Code is delivered in small increments (1 day by 2+ people) which are meaningful to the user and can be tested in front of the user every day. Therefore any deviation from what the user wants and the team delivers is detected early ? ideally ?same day?.

7. Programmers work either as ?pair? programmers ? both sitting down at the same VDU or as a pair ? one writes the code and the other the test harness ? or operate as a pair when code is corrected or brought into line with standards or ?best practices?.

8. Animated GUI interfaces can be demonstrated.

9. Any changes required by the user can be immediately agreed and the code corrected. The user has publicly agreed that the code is correct for the razored core.

10. Style and standard documents are prepared and agreed by the team. The focus is on every programmer being able to read any piece of code. The use of libraries and the practice of handling exceptions versus return codes must be agreed.

11. The FACE, assertions and the outline functionality documentation addressed to programmers should be extracted from comments and code segments automatically. It must be agreed how assertion failure is to be passed back to the invoking code and the relevant standard must be rigorously adhered to. Indeed the FACE code is the first draft of the component structure.

12. Best practice programming examples are debated, selected, agreed and then adhered to.

13. All code is written in small blocks (50-200 lines), forced through a ?pretty-print? program (or editor) and is then inspected by a peer programmer or written by a pair sitting at one screen.

14. Each block of code (method) has pre-assertions and post-assertions. The inspection is to guarantee that any invocation passing the pre-assertions will deliver to the post-assertion. The first inspection is of the FACE.

15. Test harnesses are written in parallel either by the pair together or by their ?pair?. Each block is tested through the test harness which allows regressive testing. It captures the test data and the results; allows the test cases to be re-submitted and checks that the same results are achieved. The test harnesses will be forwarded to QA who will build them into the acceptance testing suite.

16. The first test case after the FACE itself is the most common or straight forward case. It may have no IFs or CASE statements in it (except standard error handling). It contains the essential calculation or manipulation.

17. The FACE of all code blocks is described and published to other team members together with the pre- and post-assertions. This is the major technical documentation. FACEs can only be changed by the greater team.

18. Each block is exhaustively tested with tools that record coverage (lines executed) and also checked for performance (CPU time). Only lines that are only executed on environmental failures that cannot be readily invoked by programmers should not be included in the coverage. Very few code changes (less than 2%) should be made on CPU performance grounds. Standards and ?best practice? should address obvious cases.

19. Context sensitive help needs standards. The analyst documents the pervasive data descriptions. The programmers draft the functional documentation. An editor reviews the language and style. Tools insert URL links.

20. All error messages need review by the user to ensure that they are meaningful to a user and to ensure that adequate context is displayed so that the user can understand exactly what the issue is. This is difficult for messages that originate from a depth of three or more layers. Clear comprehensive rigorously adhered-to standards must address this area.

21. All errors that cause some data not to be processed as expected by the user must be logged so that they can be re-constructed. This may need other data to be logged to provide sufficient context. Indeed except for code which needs high performance all code should have logging running on all branch points even in production.

22. All code should be bullet proofed. The return codes (or exception handling) should be tested for all functions including APIs. One cannot assume that library, third party and system code will behave exactly the same through successive releases.

23. Very tight management is needed to control build scripts and source code control of libraries and other components where changes will affect multiple teams. Multiple levels of source code will need to be controlled.

24. The focus is on zero defect code. When code is released to QA the expectation is that they will not be able to get the code to fail or be in conflict with the documentation. Code and documentation must be correct, complete and consistent. The test harnesses and coverage results and documentation is all handed over so that the tests can all be repeated on the latest build. Omissions in documentation or performance not adequately described by the documentation are defects.

25. QA may need to test the entire suite on alternative operating systems or alternative locales or databases. These tests should be done by the programmers if practical and on ?same day?. But at least for some systems level code it may be difficult to provide multiple environments to every team. In this case the test harnesses must be exploited.

26. Optimum team size is 6; maximum 12. Optimum project length is 6-9 months. Optimum code changes for releases are 10-40 person days so that separate releases from the team would occur every 5-15 days. [5-20 Klocs] This means that these changes should not necessarily be published as new releases unless they contain major additions to functionality. So a method of pushing releases out as silently as possible is necessary.

27. Typical fully documented code for end-user delivery is written at about 100-200 lines per day per person. [This is about 4 times faster than SDLC including all design documentation.]

28. When the total staff is larger than say 12 the overall project must be divided by into smaller parts. Clearly how to do this depends on the nature of the project. Most critical is the design conceptualisation. It is critical to have a build mechanism which isolates the teams as much as possible.

29. Data-driven applications will need a full analysis of the data structures and hence a definition of the RDBMS schema. It may need a middle layer to give the multi-team separation or at least define the use of stored procedures or a library of database access functions.

30. Programmers must expect code to be secure in read-only directories and that much code will not be accessible to them at any one time at the source level at all.

31. Code that has been released may need enhancement. The pair responsible for the code enhancement inspect the code and the enhancement requirement and decide whether the code needs restructuring (re-factoring) before writing the additional code. They do so implementing the original test cases first in the new code and possibly releasing the code in this state. Note that it does not affect the suite as a whole.

32. If the FACE must be changed all invoking code must be inspected and a new FACE designed. The new FACE (and pre-assertions) are designed and the code changed to handle the old cases. The test harnesses may need to be changed as well. The test cases can be re-submitted and checked automatically against the original test results. The invocations are changed and the whole suite should operate on the old data and may be QA?ed again. Other team?s changes can therefore be released in parallel. Finally the new code is added, inspected, tested and passed to QA.

33. The re-factoring process ensures that the original code is as simple as possible until a user has agreed that it was correct (for those cases). The philosophy is called Parsimony ? put off today everything that is not needed until tomorrow. This allows the user to learn from early implementations.

34. Project Management is simplified because the only milestones are associated with something a user can see. QA is not expected to find any bugs so there is no recursive code-test-debug cycles which obscure how close to completion one task is. That tasks are being delivered in 5-15 day cycles also simplifies PM tracking. Nothing is ever x% complete; the milestones are Met or Not.

35. XP has a strong weight on white-boarding ? making sure everybody understands everything in the user?s terms. It also stresses coaching and mentoring as the code inspection ensures that a new team member rapidly learns the agreed style and standards.  Top

   
   
Visit AboutIT Website © 2003 - Ian Mitchell
22A Goldie Street, St Heliers, Auckland, Ph: 027 4965 608
 Top | Back | Home | Print | Save | Email | Site Policies | WebMaster | Contact Us