TRIZ and Extreme Programming

By John W. Stamey

Abstract

The problem-solving foundations of Extreme Programming mirror a number of inventive problem solving principles found in TRIZ. This paper is a first step toward understanding powerful software development methodology as a technique of inventive problem solving.

Introduction

This paper begins by comparing the software development/management methodology Extreme Programming (XP) to Genrich Altshuller's Theory of Inventive Problem Solving (TRIZ). Both methodologies are used to generate a solution to a problem that has never been solved before. Use of the XP methodology is equivalent to saying that a new and original software system is being developed. Use of TRIZ is equivalent to saying there is a problem to be solved and the solution is being generated through some sort of inventive problem solving.

In the next section of this paper, we outline the basics of XP and describe how it differs from the more traditional waterfall model of software development. In the third section, we provide some background about Altshuller and TRIZ. The fourth section provides a comparison between the methods found in XP and a subset of the inventive principles found in TRIZ. The fifth section points the direction of further research in this topic.

Extreme Programming

The waterfall model of software development was first proposed by Winston Royce in 1970. Steps included in this traditional software development methodology include:

• Requirements specification
• Design
• Coding
• Integration
• Testing and debugging
• Installation
• Maintenance

Each phase is completed before the next one begins. In a sense, the deliverables of one phase "fall" into the next phase much like the waterfall metaphor used in the name of the methodology. Also termed a linear sequential model of software development, the waterfall model fails because: software projects rarely follow the sequential flow; change management is not an inherent part of the waterfall model architecture; all requirements are not easily elicited prior to coding and testing; and, a working version of the project is not available until the end of the development process. (Pressman, 2001, p. 30)

The waterfall model is frequently called a "heavyweight method," as it provides for a heavily regulated, regimented, and frequently micro-managed strategy for software development. The steps of the waterfall model can be bureaucratic and slow, contradictory to the reality of software development. (Cockburn, 2001)

XP was developed by Kent Beck, who understood that any team's software development methodology needs to be customized to the team and their circumstances. (Beck, 2005) There are twelve key practices of XP that are procedurally and culturally different from the waterfall model:

• The Planning Process: The XP planning process allows the XP customer to define the business value of desired features in units of analysis called User Stories.
• Small Releases: XP teams put a simple system into early production and update it frequently on a short cycle.
• Metaphors: XP teams use a common system of names and descriptions to help guide development and communication.
• Simple Design: All programs are designed to meet, but never exceed, the requirements. Code is not written for functionality not set forth in the requirements.
• Testing: Programmers write unit tests before they write the code to be tested (white box testing). Customers direct acceptance tests (black box testing) to make certain that the needed features have been provided.
• Refactoring: Duplicated and bad code is removed and/or consolidated as soon as it occurs.
• Pair Programming: XP programmers write all code in pairs – one programmer "drives" while the other "codes." Roles are frequently switched to keep the programmers fresh.
• Collective Code Ownership: As all of the programmers own (control) the code in the project, any programmer can change another programmer's code when necessary. This practice speeds up the programming process.
• Continuous Integration: XP teams integrate their code into the main system several times per day. This practice helps eliminate integration problems.
• 40-hour Week: As tired programmers make more mistakes, XP teams are not allowed to work more than forty hours per week. This practice is intended to keep the programmers fresh, healthy and effective.
• On-site Customer. An XP project is steered by a dedicated individual who is empowered to determine requirements, set priorities and answer questions as the programmers have them. The effect of being improves communication and reduces hard-copy documentation – often one of the most expensive parts of a software project.
• Coding Standard: For teams to work effectively in pairs, as well as share ownership (joint responsibility) of the code base, a strict set of coding rules is put in place. All programmers must write the code in the same style.

TRIZ: The Theory of Inventive Problem Solving

Examining more than 200,000 patents through the years, Genrich Altshuller concluded there was a process by which many inventions were developed. In reviewing the patent applications, he identified contradictions that existed before the inventions were created. He then identified a set of inventive principles used to remove these contradictions.

For Altshuller, a problem to be solved was equivalent to a contradiction between two opposing factors. Given attempted solutions to a problem, one factor would improve while one factor would worsen. As an example, we consider the problem of making a table stronger. If the attempted solution is to add more material to the top of the table, the additional material makes the table stronger (a potential improvement) while it also make the table heavier (a potential worsening).

Years of work resulted in the development of the TRIZ (the Russian acronym for the Theory of Inventive Problem Solving) methodology. In total, Altshuller found 39 different contradictions, when properly paired, could be solved with 40 inventive problem-solving principles. (Altshuller, 1998) The forty problem-solving principles have been found to produce many innovative solutions for companies such as Intel, Michelin, HP and Samsung.

TRIZ and XP

When the 12 principles of XP are compared with the 40 problem-solving principles for TRIZ, clear relationships are found:

• User Stories (The Planning Process) may be described by TRIZ Principle 1, Segmentation. Segmentation is a process of dividing a system into parts in order to isolate or integrate beneficial properties. The segments are then reassembled, or integrated, to perform the required functionality. Each user story encapsulates an important requirement. Assembled together, the user stories represent the requirements for a complete software system.
• Small Releases may be described by TRIZ Principle 30, Flexible Membranes or Thin Films. Traditional construction is replaced with constructions of thin films or flexible/pliable membranes. The development of programming systems with XP is the continual accumulation of many small releases.
• Metaphors may be described by TRIZ Principle 2, Extraction. The important properties of a system may be separated, either physically or virtually. Metaphors provide a virtual abstraction of system concepts from a point of reference that is, hopefully, familiar and meaningful to both the development team and the users.
• Simple Design may be described by TRIZ Principle 7, Nesting. Nesting is the quality of being made to fit closely, together, and/or inside each other. As simple design does not allow for additional (unnecessary) functionality, existing releases may be immediately extended, with no worry of nuisance side-effects from unnecessary code.
• Pre-written unit tests may be described by TRIZ Principle 9, Prior Counteraction.This principle suggests that we plan, in advance, to reduce or eliminate things that might go wrong. Pre-written tests help guide the development process, providing tight coupling between what we intend to test and what code needs to be written in order to accomplish that test.
• Refactoring may be described by TRIZ Principle 5, Consolidation. Functionality can be created by combining functions. Consolidation (in both physical systems and in software) can be done in space, time or contiguous operations. Refactoring is a general collection of duplicate code as well as code that needs to be optimized.
• Pair Programming may be described by two TRIZ principles: Principle 15, Dynamicity, which prescribes that a system adaptive, flexible or changeable; Principle 17, Another Dimension, prescribes translation into a higher dimension. Pair programming is a translation of programming from one person to a community of two. Roles are frequently reversed; hence both programmers must be adaptive, flexible and changeable.
• Collective Ownership may be described by TRIZ principle 25, Self Service. This principle states that an object must service itself, carrying out supplementary and repair operations. The idea of collective ownership and use of code is exactly the idea of self-service described in this principle.
• Continuous Integration may be described by TRIZ principle 20, Continuity of Useful Action. A continuous flow of action is used to increase efficiency. In system development with XP, small releases are continually integrated into the existing code base. This continuous flow of new code into the existing system will help identify problems the moment they occur.
• The 40-hour Week may be described by TRIZ principle 16, Partial Action. Excessive actions can be harmful. This identifies the ideal of limiting programmers to a 40-hour week. Work (programming) that is full of mistakes from a tired programmer is worse than no work at all.
• The On-site Customer may be described by TRIZ principle 23, Feedback. The principle of feedback is based on system output that is returned back to the system (as input) for the purpose of quality control. An on-site customer provides invaluable communication between the project owner and the project developers. (Beck, 2005, p. 20)
• Coding Standards may be described by TRIZ principle 33, Homogeneity. The interaction of two systems is best when they use the same material or information.The use of similar coding and documentation styles provides a common language through which the programming team may communicate.

Next Steps

This paper is a first step toward understanding associations between the agile development methodology Extreme Programming (XP) and inventive problem solving. The 12 principles of XP have been associated with a subset of Altshuller's 40 inventive problem-solving principles. Research is currently underway to quantify the strength of the 12 inventive problem-solving principles as homologies (Bertalanffy, 1969, pp. 84-85) when used in practice by programmers.

References

1. Altshuller, G. (1998) 40 Principles Extended Edition: TRIZ Keys to Technical Innovation. Worcester, MA: Technical Innovation Center.
2. Beck, K. & Andres C. (2005) Extreme Programming Explained, 2nd Edition. Upper Saddle River, NJ: Addison-Wesley.
3. Brooks, F. (1995) The Mythical Man-Month: Essays in Software Engineering, 20th Anniversary Edition. Upper Saddle River, NJ: Addison-Wesley.
4. Cockburn, A. Agile Software Development. Upper Saddle River, NJ: Addison-Wesley Professional.
5. Jeffries, Ron (n.d.) "What is Extreme Programming?" Retrieved May 4, 2006 from http://www.xprogramming.com/what_is_xp.htm.
6. Pressman, R.S. (2001) Software Engineering: A Practitioner's Approach, 5th Edition. New York: McGraw Hill.
7. Royce, W. (1970) "Managing the Development of Large Software Systems," Proc. Westcon, IEEE CS Press, pp. 328-339.
8. Von Bertalanffy, L. General System Theory: Foundations, Development, Applications. New York: George Braziller, Inc.

About the Author:

John Stamey is a professor in the Department of Computer Science at Coastal Carolina University. Contact John W. Stamey at jwstamey (at) coastal.edu.