TITLE: Trade-offs in Software Development AUTHOR: Eugene Wallingford DATE: July 14, 2004 6:11 PM DESC: XP on trade-offs -- ancient wisdom ----- BODY: Some of my colleagues become uncomfortable when I teach our students agile software development methods. "That's just trendy hogwash," they want to say. (They mostly don't, because they are too polite.) Of course, folks from the Smalltalk and Lisp communities say just the opposite -- many of the ideas and practices of the agile software movement have their roots in ideas and practices found in those communities back in the 1980s and even earlier. I was reminded of just how fundamental some of these ideas are when I read one of the early chapters in Gerald Weinberg's The Secrets of Consulting, which I first blogged on yesterday. Weinberg talks about the necessity of recognizing trade-offs and making them explicit in the projects one does. Whenever the client asks for some optimal something -- the minimum cost solution, the shortest possible time, the best possible way -- the wise consultant asks, "What are you willing to sacrifice?" This sounds an awful lot like what Extreme Programming says about The Four Variables: cost, time, scope, and quality. To maximize or minimize one of these fundamental variables, you have to give up something for at least one of the others, maybe all. Trade-offs of this sort aren't a new idea at all, even in the world of software development punditry. Weinberg wrote his book in 1985. I especially like one of the examples Weinberg uses to make his case, the Trade-off Chart. Here is such a chart, updated to 2004: This chart shows the trade-off between speed and distance in the product category "world's fastest runner". If you want a runner to maintain a faster speed, then you will have to give up distance. If you want a runner to maintain a speed for a particular distance, then you will have to accept a slower speed. This is true of the world's fastest runners -- the upper bounds on expected performance for most -- and so it is generally true for other runners, too. As an erstwhile runner, I understand just what Weinberg is saying. And I am nowhere near the upper bound at any distance! Yet, like many people, I sometime forget about the fundamental trade-offs I face when working on a software project. I sometimes forget when I'm running, too, and pay the price later, in the form of fatigue or injury. Weinberg goes on to show how a developer or consultant can use such a chart to begin asking the right questions about the requirements for a project, and how these questions can help both consultant and client follow a reasonable path toward a working system. I wonder what a four-dimensional trade-off chart for XP's four variables looks like for typical kinds of software? Even two-dimensional chart showing pairwise trade-offs among the variables would be useful in understanding the forces at play when building software. These are the sort of pictures that Kent Beck draws with words in his book Extreme Programming Explained. So, no, dear colleagues, I'm not teaching only the latest fads in my Agile Software Development course. We are learning the basics. -----