Level: Introductory Scott Plamondon (comments@speditorial.com), Freelance writer, Scott Plamondon Editorial
17 Jun 2003 Extreme Programming (XP) founder Kent Beck likes to say he made up XP's fundamentals during a particularly troubled project in 1996. While strictly true, from talking to him you sense he'd really been formulating the process for quite some time. Find out what Kent thinks about the contribution of the Java platform to software development's success (or lack thereof) in this exclusive developerWorks interview.
In a scene near the end of the 1973 movie the Paper Chase, four first-year law students, sitting around an antique table, present each other their outlines summarizing the year's work. One student's outline, comprising thousands of pages, clearly cannot aide anyone's studying. When challenged, he indignantly states that his outline represents a work of genius that he's unwilling to share. He clearly had lost sight of the goal -- create a study aide -- in favor of his own brilliance. That scene comes to mind while listening to Extreme Programming (XP) founder Kent Beck explain how software development frequently goes off track. You can imagine Kent railing against becoming enamored with clever complexity while failing at making the grade.
Kent, born and raised in Silicon Valley but now residing in Oregon, hails from a family in which technology permeated the household. He says his grandfather was a "radio geek," while his electrical-engineer father worked on discrete components and ICs and showed Kent ham radios. "I come to it all honestly," he says.
While at the University of Oregon, Kent alternated between studying computer science and music before graduating with a computer science degree. In addition to such XP-focused books as Extreme Programming Explained: Embrace Change, Kent has authored numerous books on such topics as Smalltalk, refactoring, and test-driven development (see Resources). But XP, with its emphasis on team relationships, simplicity, testing, and so on, remains his best-known, if not most controversial, accomplishment.
developerWorks had the opportunity to ask Kent questions about design patterns, the Java platform's utility for producing quality software, pair programming, and what developers can do to improve their software efforts. And Kent didn't disappoint.
Creation
developerWorks: How did XP come about?
Beck: In the first part of 1996, I was a consultant for Smalltalk performance problems. I received a call about a [payroll] project for Chrysler. When I asked for their tests so I knew if I broke something, they said that they weren't actually computing any answers yet -- not a good answer. Until you care about answers you can make any program go really fast. But the point is to get the correct answer. Any project that's lost sight of that is a project in trouble from the get-go.
The project had serious problems -- everything from the contractual arrangement, to exhausted people, to lowered voices. After three days I told the CIO of Chrysler, Sue Unger, that she had three options: keep going, which no one wanted; cancel the project and fire everyone; or give everyone a week off and start over. She picked option "c" and said "but you're in charge."
Up until then I believed better programming would solve all the world's ills. Yes, you can screw up the programming so badly you kill the project. Usually, however, the problem concerns relationships between the business people and the programmers, the budget process, poor communications -- factors unrelated to the programming. The context in which the software development takes place proves as important to the project's success as the programming itself.
Now, the payroll program would handle Chrysler's entire payroll, representing 1/10 of 1 percent of the entire US gross national product -- at that scale, with union rules and all the places they operate, it's a complicated program. They had a crying business need; it had to work. At the same time, this wasn't rocket science -- we just had to execute.
So, after a couple of weeks I interviewed everyone one-on-one. I told the first guy that we'll divide the project into three-week intervals called, say, iterations. In each iteration we'll implement a few new features called stories. We'll write down all the stories we need, slot them into the iterations, then do it.
I told the next guy [I interviewed] that we have these three-week iterations divided into stories. For each story we'll write these, um, acceptance tests to demonstrate that the stories meet the customer's expectations.
With each person I interviewed I added a little more. By the end of the day, I'd interviewed 20 people and had laid out Extreme Programming's basics.
dW: What had they done wrong?
Beck: They didn't work end-to-end. They worked their way through the system such that in 18 months they had done the data import part, had done some calculation work, and were getting around to the export part. Lo and behold when they spit out numbers, [the results] didn't reconcile with anyone else's numbers.
Their biggest problem: they treated the requirements as a fixed set of tasks. The tasks would grow over time, like a mirage. At some point the project recedes as fast as it progresses. Instead, we made the project's scope visible with stories with costs and a fixed budget.
So, I said that at the end of the first three weeks we'll print a live, cashable check. They said that's impossible -- we must import data from 18,000 systems. I asked if there was one person whose check we could print. "Well, for most people it's not that difficult." After three weeks, we printed a live check with correct data. They framed it and put it on the wall. That's the XP creation myth.
Design patterns
dW: Before we get further into XP, let me ask a few questions about design patterns. First, you've said that patterns demonstrate "generativity -- the idea that patterns don't merely exist, they also create the thing they describe." Can you explain what you mean?
Beck: One way to look at patterns examines 1,000 programs and catalogs the kinds of solutions we see over and over -- patterns are analytic tools. I can look and say, oh, look, here's State or here's Strategy or whatever; but that doesn't help me write the 1,001st program.
So, imagine we're playing basketball and we watch two players do the give and go -- when a player passes to another player then runs to the basket because the defender isn't watching.
You and I can watch basketball on TV and see them do the give and go. Now imagine we're playing. We're on the court with the ball in our hands. Just because we know people can do the give and go doesn't mean it's a thing we can do. OK, we're in this situation, I pass the ball to you, you're thinking give and go, I'm thinking give and go, so I'm going to do this thing -- that's generativity. It's the part of the pattern that causes us to create the pattern, not just recognize it exists in the world. So, there's a sense of patterns as analytical tools, but there's a complementary sense in which the patterns are synthetics that causes us to create something in the world. I was at a client the other day; boy, they had a zillion patterns in their design, but none had been done in quite the right way and the result was a mess.
XP redux
dW: Moving back to XP, the XP mantra seems to be communication, simplicity, feedback, and courage. How do Java developers practice each in a development process? Do they carry equal weight?
Beck: Which one of those don't you want on your development team? Yes, they all come into play every day. Three have little do with Java or not Java. Simplicity, on the other hand, does have some technical effects. My partner and I were looking at some generated [Java] code the other day trying to figure out what it did. A super class required knowledge of the subclass being used. I said that I bet they're using reflection to go down the call stack to figure out which class is calling this. Instead, in the generated code they could have just put the class name. Now it's very clever to use the Java Security Manager to do all this, but it cost us half an hour instead of doing something blindingly simple like putting the name of the class right there.
So, simplicity is about acknowledging the tricks exist but not using them. Wouldn't it be cool if we could use the Java Security Manager here? Yeah we could, but let's just put the name of the class. I used to feel proud of myself when I used something no one else knew about. Now I'm disappointed -- I apologize when I can't think of a simpler way.
dW: So, the developer asks, "Isn't it cool that we can use it" as opposed to "do we really need it?"
Beck: Right -- each trick comes with costs and benefits. The designer with perspective understands that. You're not a designer until you know the tricks, but you're not really a designer until you know when not to use them.
Folding it back to the patterns discussion, some patterns come with much higher costs -- Singleton, for example. Some development cultures use Singleton all over the place, but it's just a global variable. We used to know that global variables are bad, but that's somehow been lost. So, we could do this with a Singleton or we can rearrange things so we needn't use a Singleton -- and the code will be more valuable as a result.
dW: Why do developers need courage?
Beck: It takes tremendous courage. Let's say I'm the senior developer and you're the junior. You say let's use the Java Security Manager. I need courage to say I know nothing about security manager -- I'm deliberately looking ignorant to you. I need courage to say, no, we don't need that here. I need courage to tell you this will take two weeks even though I know the only acceptable answer is the end of the day.
dW: The inside flap of your book Extreme Programming Explained: Embrace Change states: "If you read this book and correctly decide not to use XP for your project, I will have met my goal just as much as if you correctly decide to use it." When is XP not appropriate?
Beck: I haven't encountered a system -- whether it's embedded or a complicated business application -- in which XP won't technically work. It's more the social or business environment. If your organization punishes honest communications and you start to communicate honestly, you'll be destroyed. I'm not going to tell someone to march in the CEO's office and tell him what's on his mind.
dW: Of all things, XP's insistence on pair programming seems to produce the most resistance and controversy. Detractors complain of personality clashes, productivity losses, naturally developing superior/junior roles, and so on. What does pair programming deliver and does it outweigh the problems?
Beck: I'm working on an Eclipse book with Erich Gamma. When we're together, a chapter takes about 2 hours; when we're apart, a chapter takes about 20 elapsed hours with tremendous back and forth. We show much higher productivity and quality when we're together than when we're apart.
Teams go more smoothly when they pair -- you make fewer mistakes, the designs are better, you're much more likely to automate tedious processes than if you're alone. Somebody called it programming naked. It has all these wonderful effects once you get over the nudity aspect. For me, everything is a plus with pairs. I simply ask people to make an informed decision.
The Java programming language -- friend or foe?
dW: How does the Java language's advantages -- built-in security, OO principles, safety, emphasis on reuse/productivity -- fit into XP methods? Do they complement each other?
Beck: The biggest thing in the XP world is to build systems that can absorb change. And with Java code you can have lots of little objects, garbage collectors that support many objects well, support for polymorphism -- those things lead to systems that allow for change.
dW: Is the Java language a good tool for producing quality products?
Beck: Java is so pessimistic. You have this compiler saying, "I'm not sure this program isn't going to run so I won't run it." I find that attitude disturbing in a program. I notice that the safety in pessimistic languages is an illusion.
Can we do better?
dW: What do you think about software quality?
Beck: I wish developers would consider the enormous consequences of their actions. When I got my driver's license at 16, I was both elated and terrified; I had newfound freedom and responsibilities to go with it. Now, compare that feeling to when Microsoft sends me a new operating system. Do I have the same feeling? No, I think it's going to screw up my life for months. For how many decades and for how many millions of people has that negative emotion been created around software. I think it's such a shame we set our sights so low. Either you're stuck with software that works the way it works because you don't want to break it, or you get an upgrade that causes pain and anguish. I just want my stupid computer to work and it doesn't. That's not computing.
That we accept the status quo says such negative things about us as humans. If our laptops degrade at half the pace as before, that isn't progress. Sucks less isn't progress. What would it be like if you bought new software and you had that sense of increased responsibilities but also of infinite vistas? Our ambitions are so, so small compared to the opportunity.
Resources - Kent Beck is the founder and director of the Three Rivers Institute.
- For a great introduction to XP concepts, see Roy Miller's Demystifying Extreme Programming column (developerWorks) and its associated discussion forum.
- Find out why VisualAge for Java is a great tool for XP teams in "Extreme Programming with IBM VisualAge for Java" (developerWorks, April 2001).
- Read "Extreme programming: A gentle introduction from extremeprogramming.org.
- David Geary's Java Design Patterns
column explains the ins and out of proper pattern use (JavaWorld).
- developerWorks offer two tutorials on Java design patterns:
-
"Java design patterns 101" by David Gallardo explains why patterns are useful and important for object-oriented design and development, and how patterns are documented, categorized, and cataloged. He also discusses when patterns should be used and provides examples of important patterns and how they are implemented.
-
"Java design patterns 201" by Paul Monday goes beyond the Gang of Four patterns introduced by Gallardo and uses additional patterns to implement a simple application. He also discusses how design patterns can help you to better understand software design and guides you through the reverse-engineering of a piece of technology, focusing on how it works from the perspective of patterns.
- Find hundreds of Java technology-related resources on the developerWorks Java technology zone.
About the author  | | | Scott Plamondon is a freelance writer and editor living in San Francisco. Prior to launching his own editorial company, Scott served as Senior Editor at JavaWorld where he learned the technology writer's craft. Contact Scott at comments@speditorial.com.
|
Rate this page
| 
