Bowling league: discussion

[Frank Carver]

Many of you will have read the interesting "monologue" by JUNILU LACAR. I thought about putting some discussion in among the posts, but it seems a shame to break the sequence with general comments, so I've started a third thread, for general discussion of the problem and its ramifications.
From my own point of view, I've already learned quite a lot about bowling just from reading the introductory design notes. I've been bowling maybe twice in my life, and the scoring has always puzzled me - I type in how many pins I knocked over and the machine at the bowling alley comes up with some magic answer telling me how much I have lost by. I guess If I had started work on this problem, I would have been in the position of the theoretical development team - unfamiliar with the problem domain, and unaware of the intricacies.
But maybe this is the point of XP. Build a simple version which implements a simple version of the rules, and add complexity as needed at later iterations. I look forward to seeing how this develops, please keep it up!

[Junilu Lacar]

Frank,
I'd like to thank you folks at JavaRanch for letting me do this bowling league thing here. The thread for the first story is getting long and I don't really know if anybody other than myself can make any sense of it or even have the patience to read through it all. I still haven't seen a whole lot of feedback and discussion from anybody else after three days. Anyway, I will take this through to its conclusion just in case any lurkers find it useful.
Thanks again.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Frank Carver]

Oh, please do continue.
It's a fascinating study which I'm sure will be prime "see this thread" material later. As soon as I get some time to think things through properly, I have some comments about your choice of tests and your iteration plan, but it want my message(s) to add to your study rather than distract from it.

[Junilu Lacar]

Nothing like a freebie to stimulate discussion. Hasn't been two hours since I got the email about the book giveaway and already the place has seen a spike of activity. Oh well, whatever works I guess. I've actually been saving my posts to the bowling league thing so that they could get counted in the drawing Doesn't seem to be anybody interested in bowling though.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Frank Carver]

OK, here are some of my comments. All off the top of my head, of course, so feel free to refute, discuss, dismiss.etc.
I'm particularly interested in your choice of unit test cases. I would probably have started with an even simpler test case, as I like to start with one which I am really sure will work, just to validate the build environment. Maybe test adding 0 pins to a new game and check for a 0 result.
Also interesting is your choice of a sequential test suite. I wouldn't have done that, but then I'm not familiar with bowling, so it probably wouldn't have ocurred to me. I still feel a greater empathy with the handful of rules given by your first attempt at requirements, as I can see much more clearly how they map to independent unit tests. I don't really mind that they are incomplete, that's where the power of XP lies - grab a few stories and start working; the rest will follow later, when we show the customer.
Imagine I had done that, and taken your stories in order (assuming your business customer has prioritized them as such).
1. The object of the game is to knock down as many pins as you can. Maybe rephrase this (in discussion with the customer) to The winner of a game is the one with the highest number of pins knocked down, which implies that a game can have more than one player each of whom has a score, and build a test case:

import junit.framework.*;
 
public class TestGame extends TestCase 
{
    public TestGame(String name) 
    {
        super(name);
    }
 
    private Game g;
 
    public void setUp() 
    {
        g = new Game();
    }
 
    public void testWinner() 
    {
        g.setScore("Frank", 201);
        g.setScore("Junilu", 366);
        assertEquals("Junilu", g.getWinner());
    }
}

As you can see this is already taking a quite different approach to yours (and to the Bobs). I may be missing something important because of my unfamiliarity with the game, or it may be that I'm free to look at it without any preconceptions.
Here's a simple implementation to make it work:

import java.util.Map;
import java.util.HashMap;
 
public class Game 
{
    private Map scores = new HashMap();
  
    public void setScore(String player, int pins) 
    {
        scores.put(player, new Integer(pins));
    }
 
    public String getWinner()
    {
       int best = -1;
       String winner = "Nobody";
       
       Iterator it = scores.keySet().iterator();
       while (it.hasNext())
       {
           String player = (String)it.next();
           Integer score = (Integer)scores.get(player);
           if (score.intValue() > best)
           {
               winner = player;
           }
       }
       
       return winner;
    }
}

In what I consider to be the true spirit of XP, this is not only very simple, but it is also useful in a real customer-focussed business way. It provides the service of taking a whole bunch of player scores and telling you who is the winner, which could be tedious to do by hand for a large number of players. And it came directly from the first customer story. Disregard the customer stories at your peril!
I'll move on to the second user story in my next post.

[Junilu Lacar]

Finally... Now we can simulate the discussion that two developers doing pair programming might have.
The task is to score a single game. A game is played by one person (perhaps we need to add that to the list of requirements). If you had two people, you would have two games. We don't want to complicate matters just yet so we focus on just the one game. I have often bowled by myself. In fact, one could say that in bowling, you are really just playing against yourself. Getting a better score than somebody else is just incidental. You could probably say the same thing of golf.
If you play against somebody else, that would be a match. So, we discover a new term. This is where the on-site user would be useful. We'd go and ask them what the right term would be so we could name our class correctly. Or maybe just note that down for another story.
Now some points to ponder:
- If I knew as little about bowling as you do, it is possible that I would have gone along with your line of reasoning. As you said, you would have tried to rephrase the rule in discussion with the customer. If we had customers like some of those that I have, they might very well say "Yeah, that sounds right." I think that underscores the importance of an on-site customer who is both knowledgeable and critical. A critical customer would have pointed out what I said above about "one person per game"
- The "one person per game" rule might have eventually been discovered when the issue of payment for the games came into consideration. This probably would not have happened until much later since payment for the games isn't even mentioned in the original user stories.
- When you try to rephrase the story, you run the risk of taking on a responsibility that is (in XP) rightfully that of the user: to specify the requirements. User stories have to be in the user's own words, that's why it's important that they write them, not the developers. If developers write down the requirements, they might introduce subtle twists that may seem harmless on the surface but will later become a source of misunderstanding.
- We seem to have discovered something that might be useful later. Since we are looking to implement team scores and comparisons eventually, do we want to keep the test that you just wrote for later? It would be a shame to throw it away now and then have to rewrite it later. Or somebody else might be doing the task of keeping track of two games. Then again, YAGNI (You ain't gonna need it) may apply.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Junilu Lacar]

Frank,
Additional comments about the first test you suggested:
I would be OK with a test that created a new game and asserted that score == 0. This would test the lower boundary condition. That might even lead to the upper boundary condition test: a perfect game, 12 strikes in a row, score: 300.
However, I would have to question the validity of testWinner(). A unit test is useful in that it helps codify requirements. It also helps you spot flaws in the design. In this case, testWinner() demonstrates how you expect to use a Game object. However, g.setScore(name, totalscore) doesn't seem like an appropriate interface for Game for the given requirements. One thing we get from it though: it highlights the misunderstood notion that a Game can have more than one player.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 03, 2001).]

[Frank Carver]

This is really getting interesting now! Looking at your bowling league story thread again, I realized that I missed the bit where you jumped straight from the overall problem (running a league) to the sub-problem of scoring an individual game. This is what puzzled me, and I feel that it is not really a very "XP" thing to do.
My aim was to produce something useful to the customer as soon as possible, from the very first iteration. It looks a lot like both you and the Bobs have got hung up on the details of the problem, and are not really doing the simplest most useful thing.
As an aside: If I do a "global substitute" of 'Match' for 'Game' in my example code, is it then domain-correct? I still hold that (with the addition of a dozen lines or so of minimal-UI) my first iteration is a useful, though very limited, first delivery.
I have found, over long soul-searching, that the hardest thing about doing XP without a real, demanding, customer is that developers have an extremely strong drive to get into the detail first and build useful, flexible frameworks. Real customers want working, useful deliverables first, and don't care what's inside them. For me the shining light of XP is that it gives developers a way (testing, continuous integration, refactoring etc.) of resolving this conflict, but the developers really have to buy in to the users idea of what the problem is rather than their own.
In my own, very limited, bowling experience, people didn't need to worry about the details of scoring a game, or even a match if there were less than six players - the bowling alley had a machine built into the lane to do that for you. The hard work that someone organizing a league would have to do all involves marshalling teams, deciding which team plays which, keeping overall rankings and scores and so on. Any of these "big customer payback" tasks would make a good user story to start with, so I'm somewhat puzzled that you went straight for the techie detail of scoring an individual game.

[Johannes de Jong]

Must make the time to read the document and get involved.

[martin fowler]

And of course the real problem with this argument is that there is nothing you can do about it. If this were a real project - you'd have a customer who will guide you. But here on the ranch there is no customer, so it's not a good simulation.

[Junilu Lacar]

Originally posted by martin fowler:
And of course the real problem with this argument is that there is nothing you can do about it. If this were a real project - you'd have a customer who will guide you. But here on the ranch there is no customer, so it's not a good simulation.

I know. Just goes to show how much people who want to do XP remotely have going against them. That's why I was hoping someone would come along and play the part of CUSTOMER. I may have to fill that role for a while if we still want to continue this. Would you be OK with that, Frank? Are you still interested?
So far, I've been able to do this because I'm on the bench, just waiting to start my new assignment which is still a couple of weeks away. One of the reasons I started this thread was to get some kind of feel for the dynamics of pair programming. My new client has COBOL programmers who have had 1 week of formal training in Java. They want to shift to Java and OO development and are bringing in a bunch of OO people to mentor the COBOL folks. I would be happy just to able to sow some seeds of acceptance of Pair Programming and Test-first programming at that place. It would be really nice if I could convince management to send a bunch of us to an XP Immersion
Anyway, the only reason I started with "Score a Single Game" was because that's what the Bobs did in their article. That was one of the things I had to get past in their article since it didn't seem like you would actually go and try to implement a story before you had done the planning game.
Now, for the sake of continuing this discussion, let's say we go the on-site customer and he tells us about the "one person per game" rule. And let's say that he says that he'd like to see this feature implemented first since most of the other features will follow from it.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 04, 2001).]

[Junilu Lacar]

Originally posted by martin fowler:
If this were a real project...so it's not a good simulation.

Martin,
On the other hand, I don't think the discussion is entirely pointless. One of the reasons I started the bowling league thread was because I felt that the "Extreme Programming Episode" article, while supposedly a faithful re-enactment of a real-life situation, somehow still seemed a bit orchestrated, like one of those professional wrestling matches.
With this discussion, we get to see real feedback. Notice Frank's confusion about the choice of the first story and jumping right into the techie details without doing planning or estimating. That was an obvious gap in the article and I think this discussion gives us a chance to fill in those gaps.
If we try to look past the aspects that obviously would or wouldn't exist on a real project, I think we can still learn a few things (aside from the fact that we don't know a whole lot about doing XP ) I for one learn a lot from looking back at what I did wrong and I'm sure others do too.
For instance, we've demonstrated where an on-site user would come into the picture when requirements aren't clear to the developers.
We've also shown how things may not always go smoothly when discussing the direction for design or unit tests. What do you do when there is a marked difference of opinion on the design and/or unit tests? Call a meeting? Pull in the coach or architect or chief designer? These are the types of questions I hoped would come out.
J.Lacar

[This message has been edited by JUNILU LACAR (edited April 05, 2001).]

[Johannes de Jong]

Bill Bozeman has started a "real" project here at the Ranch for automating an assigmment log I update manually at the moment. see : http://www.javaranch.com/ubb/Forum19/HTML/000332.html
How about using that as a XP project. There could be two types of customers, the Nitpicker and the Student. I for one am busy doing the assignments so I'll volenteer as Student Customer.
Also something to look into Martin XP for virtual projects.
[This message has been edited by Johannes de Jong (edited April 05, 2001).]

[martin fowler]

Actually it isn't the remoteness that's the problem. The problem is that you haven't got somebody who is only concerned about business value and who isn't concerned about how you do it. You would get a better simulation if someone just said "I'll be the customer, I'll set priorities but I won't get involved in design discussions or in evaluations". At the moment Junilu is doing both, and that's what's making the simulation tricky.
The original Object Mentor article has the same problem.

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

[Johannes de Jong]

That is why I'm proposing the Assigment Log Project.
We will have definite clients. I'm a student, I know what I want to see. Marilyn is a nitpicker she knows what she wants. Both clients with specific and different needs.

[Junilu Lacar]

Yes, it is tricky. One pitfall of XP then would be having one or more user/developer on the team. Like if a team were developing a utility for internal use, such as CruiseControl. On projects like that, the team itself would be the customer. Does that preclude the use of XP then?
J.Lacar

Originally posted by martin fowler:
The problem is that you haven't got somebody who is only concerned about business value and who isn't concerned about how you do it ...and that's what's making the simulation tricky.

[Wayne Conrad]

Leo Scott and I had the same problem when we tried the Bowling Scores experiment (here). We spent a lot of effort doing things that the customer would "obviously want." For example, it was obvious to us that the customer would want to be able to display the entire score board, and therefore need to retrieve all the data it takes to display each frame -- which little number goes in each little box. We spent a lot of time trying to design the set of classes it would take to do that.
It took an hour of pain before we finally realized that the two Bob's had not saddled themselves with this faux requirement. Once we dropped it, we got unstuck and were able to code something.
Even if it had been a requirement, I think we would have done better to pretend it wasn't and just score a game first, and only then add the bit of being able to tell a UI what to display for a frame. We wouldn't have gone down the rathole of wave-our-arms-in-the-air design that way.
Wayne Conrad