Models don't kill projects, people kill projects. Regardless of what the name may imply, modeling is a fundamental part of the Extreme Programming (XP) software process. However, many developers are unsure how they can include modeling while remaining sufficiently "extreme." The answer lies in the fundamental principles of the Extreme Modeling (XM) methodology ("Extreme Modeling," Thinking Objectively, Nov. 2000).
XM is a lightweight methodology built on existing and proven modeling approaches that are adapted from common heavyweight software processes. The secret to XM isn't the modeling techniques themselves, but how they're applied on a software project. And to understand XM, you must first understand its values, principles and practices.
XM Values
The values of XM are the values of XP: communication, simplicity, feedback and courage. Models promote communication between project stakeholders (for example, developers, users, project managers, senior management and so on). It's important that developers understand that models are critical for simplifying both software and the software process—it's much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code. With respect to feedback, Kent Beck says it best in Extreme Programming Explained (Addison Wesley Longman, 2000): "Optimism is an occupational hazard of programming, feedback is the treatment." By communicating your ideas through diagrams, you quickly gain feedback, enabling you to act on that advice. Finally, courage is important because you need to make important decisions and be able to change direction by either discarding or refactoring your work when some of your decisions prove inadequate.
XM Principles
Where XP includes principles such as incremental change, assuming simplicity, open and honest communication, local adaptation, and traveling light, XM extends them with several modeling-specific principles. If a picture is worth a thousand words, then a model is worth 1024 lines of code, a term I picked up from Karl Wieger's Software Requirements (Microsoft Press, 1999). You can explore design alternatives more effectively by drawing a couple diagrams on a whiteboard with your peers than you can by sitting down and developing code samples. Using multiple models to develop software is another XM principle that you need to apply, because each model describes a single aspect of your software. You should also apply the right model; for example, a UML activity diagram is useful for describing a business process, whereas the static structure of your database is better represented by a physical data or persistence model. And to be successful at applying multiple models, you must both know your models and know your tools, the tools in this case being the various models that you have at your disposal, as well as any diagramming or CASE tools.
It's important to model first, that is, think through a problem before you begin to code the solution; 10 minutes of modeling can often save you several hours of coding. Software professionals also reuse existing artifacts: Perhaps you can take advantage of an existing enterprise requirements model, business process models, physical data models or even models of how systems are currently deployed within your user community. It's true that these models either don't exist or are out of date in many organizations, although you're often likely to uncover reasonably accurate models with a bit of research.
A crucial principle of XM is that you should have a limited number of contract models. Contract models are often required when an external group controls an information resource that your system requires, such as a database, legacy application or information service. A contract model is something that both parties should mutually agree to and mutually change over time if required. Examples of contract models include the detailed documentation of an application programming interface (API), a file layout description, an XML DTD or a physical data model describing a shared database. As with a legal contract, a contract model often requires a significant investment of resources to develop and maintain; you must ensure that it's accurate and sufficiently detailed. Your goal is to minimize the number of contract models for your system to conform to the principle of traveling light.
XM Practices
The practices of XM are also a superset of those of XP. XP's small releases, metaphor, simple design, refactoring and other practices are all applicable to modeling. Very likely XM's most important practice is simple tools: The vast majority of models can be drawn on a whiteboard, on paper or even the back of a napkin. Whenever I want to save one of these diagrams (because I want to explain my design approach for a component to others or I need to erase the whiteboard so I can work on something else), I take a picture of it with a digital camera. I've also worked on several projects where we posted our drawings on an internal Web page, improving communication within the team without introducing the burden of redrawing the diagrams using a drawing package or CASE tool. In my experience, most diagrams are throwaways; their value comes from drawing them to think through an issue, and once the issue is resolved the diagram doesn't offer much value.
Most of the time, a whiteboard and markers are my best modeling tool alternative. I'll use a drawing tool such as Visio if I need to create "pretty" diagrams to present to important project stakeholders. And occasionally, I'll use a CASE tool such as TogetherSoft's Together/J (www.togethersoft.com) or Rational Rose (www.rational.com)—if and only if they provide value to my programming efforts. Both of these tools generate scaffolding code—to manage associations between objects, for example—a tedious task that I prefer to have automated. If you find that you primarily use your CASE tool to document your system then you probably aren't getting much benefit from it. You're not following the XP and XM principle of traveling light, either. Your goal is to develop software, not documentation; therefore, simple tools such as a whiteboard and digital camera are often a better choice than a complex CASE tool. Another downside of CASE tools are the licensing costs and the cost of training and education to learn how to use them appropriately. If a tool doesn't provide positive value then it doesn't make sense to use it.
XP's simple models practice is related to XP's simple tools practice. When you consider the diagrams of the Unified Modeling Language (UML), or traditional diagrams such as Entity-Relationship Diagrams (ERDs) or structure charts, you quickly realize that most of the time you only require a subset of the diagramming notation available to you. You could choose to create complex diagrams using any of these techniques, but if a simple diagram that uses a subset of the notation, or even a modification of it, suffices then apply the simple approach. Simplicity is a fundamental value of XM.
A critical question is why do you model? The most important application of modeling is to explore the problem space, to identify and analyze the requirements for the system, or to compare potential design alternatives to identify the potentially most simple solution that meets the requirements. In other words, you model to understand. Following this practice you often develop small, simple diagrams that focus on one aspect of your software, such as the life cycle of a class or the flow between screens. This practice is supported by the XM principles of knowing your models, understanding the multiple models at your disposal, and then applying the right model for the specific issue you are trying to understand.
The secondary reasons to model are related to the XM practice of modeling for others: You model to communicate with people external to your team or to create a contract model. Because the customers for some models are outside your team, you may need to invest the time to make your model(s) look "pretty" by using such electronic tools as word processors, drawing packages or even sophisticated CASE tools. For example, your project team may need to go to senior management to obtain the necessary resources to continue a project, which might require you to present models that your manager can understand. In this case, your hand drawings are likely not sufficient, requiring you to transcribe critical diagrams into a product such as Visio or PowerPoint. Having said that, I've found that better managers often appreciate rough drawings because they realize that you didn't waste several hours or even days on cosmetic issues. However, you will almost always use an electronic tool to develop a contract model because the model must be maintained over time.
These two XM practices, model to understand and model for others, go to the heart of how much permanent documentation you should develop while modeling. I use the term "permanent documentation" to represent models that you keep for posterity's sake, either because they are contract models or because your organization's software process insists that you develop specific models. A model should be permanent if someone will need it in the future. Whenever I'm asked to develop a permanent model, I first ask who will use it and what they intend to use it for, and then I work with them to determine what critical information needs to be contained in the model. This approach helps me to keep things simple and travel light: Modeling doesn't have to imply the creation of excessive documentation. Furthermore, whenever I run across an existing permanent model, I question whether I still need it. If not, I retire it as quickly as I can to lighten my load. Your goal is to have just enough documentation and no more.
XM also includes the practice of collective modeling in which your development team works together to develop models. Most of the time you model to understand, and the best way to do this is to talk the issue through with one or more people. Often you and your modeling partner(s) will first develop throwaway diagrams to think through your design before you code. To develop the metaphor or architecture for your system, you will often need to model with a group of people to develop a solution everyone agrees on as well as one that is as simple as possible.
The final two XM practices are called modeling wall and apply patterns. A modeling wall is where you post your models for everyone to see; it should be accessible to both your development team and other project stakeholders. Your modeling wall may be physical, perhaps a designated whiteboard for your architecture diagram(s) or a place where you tape a printout of your physical data model. However, modeling walls are often virtual—for example, an internal Web page that is updated with scanned images. The apply patterns practice is exactly what it sounds like: You should learn and then appropriately apply common architectural, design and analysis patterns in your models. The application of patterns allows you to reuse the thinking processes of other developers (Thinking Objectively, Feb. 2000), providing significant benefit to most projects.
Extreme Modeling in Practice
So, how does XM fit into your overall development picture? If you're practicing Extreme Programming (XP) then it fits in quite well. If you're following a less adaptive software process, such as the Unified Process ("Effective Software Deployment," Thinking Objectively, Nov. 1999) then you may decide to adopt the XM principles and practices that fit in best with your organization's culture. To learn more about XM, check out www.extreme-modeling.com, where I'll continue developing the concepts I've described here. Also, I would love to receive any feedback you have about XM, good or bad, via e-mail at [email protected].