|
|
Met
The first meeting went pretty well.
Well, honestly, the fact we had it was pretty neat in itself.
But we chatted, ate a great breakfast, and got some business done.
We talked a bit about a Go-Server vs. a generic game server. It's an interesting question, because our first instincts were to go for the abstract, but XP teaches to only program exactly what you need, and no more. So we were torn. Truthfully, while a generic game-playing server would be neat-o, once it was up and playing Go, we might not be interested in doing chess or checkers or dots.
Well, we liked the idea of Dots.
More important, if we got bogged down in solving problems of a generic game server, but not a Go-Server, we might lose the momentum.
On the other side (this thing had a lot of sides), none of us really play Go, so for most of us, it's an abstract concept anyway. I like Go, and actually, I'm hoping an asynchronous server will allow me to play more Go.
This one's still up in the air. Originally we decided to start with a Tic-Tac-Toe server, but after writing and erasing a paragraph that you'll never see, I'm not sure that's the write move. We'll see how it looks later.
Another discussion that came up was the idea that the server shouldn't be restricted to asynchronous interfaces.
An aside: I keep talking about the asynchronous server, or asynchronous Go playing. It's a long word for a simple concept. Most games are played synchronously. That is, you and I will sit down and play the game, one of us will win, and then we'll go do something else. Playing asynchronously means that we can play the game without actually both being at the game board at the same time. It's a bit like playing chess via the mail, or having a board set up in a study where you and I might happen to wander by throughout the day and make a move.
Also, it shouldn't be restricted to humans. What we'd like is a server that represents a game in progress, takes input, validates it, then takes care of notifying the opponent. This could be via email, as originally conceived. But it could also serve as a back-end for a more traditional web-based synchronous game. It could also allow Go-bots (heh) to play.
The funny thing is, even under XP, this decision is a no-brainer. I think it's because organizing the code this way won't cause much (if any) overhead, whereas creating a generic game server framework will. It just will.
For me, the questions in XP about whether to do it or not revolve around cost and return. If it takes a little bit longer to make it more flexible, and you know there's functionality down the line that you'll need to implement, it makes sense to work it in now. If the functionality isn't a given, or it'd take a lot of effort to do today, the return just isn't worth it. Take the more simple path.
Oddly enough, this ties into something I read just this morning on... I think, Martin Fowler's blog, where he talked about Technical Debt. The idea is that, just like financial debt, you can make decisions where you take a shortcut today, and pay off the result with interest tomorrow.
So, I can cheese out a quick and dirty solution to a problem, but I'll have to pay for it with maintenance at some point in the future.
The trick is, just like the more traditional debt, you can do this on purpose. It may make perfect sense to take the quick and dirty solution, as an investment in your software, in order to get functionality out the door faster. Even though you know you'll have to pay interest next time you need to maintenance it.
In fact, XP is sort of built on the idea that the interest you pay will be smaller when using it than the interest you'd pay in a more traditional development process. Which is why most traditional processes spend so much time trying to get all the ducks lined up in a row beforehand. They're trying to reduce their technical debt by paying for the whole thing up front.
Anyway, where was I? I got a little off-track there. Oh, okay. So, in a nutshell it went well.
Our first story will be Story Zero, which is getting the environment up and running. The story is: A hello world page, with the message read from a database, displayed by a Python app running under the Zope server, and including unit tests with PyUnit. This'll get us all up and running in the right environment and we'll be ready to tackle the real stories when they come along.
And the code needs to be checked into SourceForge. Tom thinks we might have a problem there, as it looks like Zope stores all its code in its OODB, so how will we check it in? It may be we don't need to, as Zope apparently also has version control, and you can change code via the web. Still, I'd rather go with something tried and true, even if it's something as complex as CVS.
This is due on the 30th.
Meanwhile, I'll scribe up the basic stories. We talked about how best to store these, and Cook and I think we might just store them as text files in CVS. This would allow us to version the stories, and we can use the directory structure to handle breaking the stories into tasks, separating them into Iterations, etc. It's a good solution for now. I'm sure time will help us shape a better one.
Finally, we invited two fellows from somewhere besides Cincinnati to get involved. They both were interested, but expressed reservations about being able to do anything. Hopefully we'll be able to get them over that and seriously involved. The tough thing will be doing things like estimating, breaking stories into tasks and assigning tasks without them present. I'm not sure it can happen properly without them. I'm confident we'll figure this out as well.
Is anyone interested in my setting up an RSS feed for this? I figured out how to create one. But I'm still at a loss on how to use it. Feedback greatly appreciated.
|
|
|
|
Post a Comment
<< Home