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.
-----