About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2004.Jan.04 Sun
I've had an idea of a computer-mediated chess game with a twist: some of the pieces, some of the time, are invisible to one's opponent. I call the idea "Blinker Chess". Each player starts the game with approximately one-third of your chess pieces (randomly selected) invisible to his opponent. Each turn, one of that player's pieces (again randomly selected) changes state: either becomes invisible or visible. You know which of your pieces are not visible to your opponent (they show on your screen differently).
If you attempt to move your piece to some square, but an invisible piece would get in the way, that other piece becomes visible, but you forfeit that move. If you move a piece onto a square that is already occupied by your opponent, whether by a visible or invisible piece, you capture it (and you see it, briefly, if it had been invisible.) Pawns, of course, capture on the diagonal as per chess rules, but if their forward movement is blocked, the blocking piece becomes visible.
Your King is never invisible. You may not know when your King is in check, because the threatening pieces may be invisible to you. The game ends in capture of the King more often than by checkmate. The "tournament chess" rule about not castling when under threat doesn't apply to Blinker Chess.
If you move an invisible piece, your opponent doesn't see it. You can also "pass" -- not move a piece -- to give your opponent the illusion that you moved an invisible piece; your opponent will not know that you passed instead of moving.
If you've played a chess variation like this, send me an email. If you know of an open-source chess game viewer, for peer-to-peer chess playing, please let me know. My email address is keithray@mac.com.
Back in Novemenber, Laurent Bossavit wrote:
On occasion, I've asked colleagues why they choose to organize their software work as "projects", as opposed to other forms of organization. The response was : "What other forms of organization ?" Like Moliere's gentleman who had been talking prose all his life without even knowing it, many of us, including project managers, never question why software development should take the form of "projects".
Projects are defined as having a beginning, middle, and end, probably because we, as human beings, like to have stories have a beginning, middle, and end. (And that preference become reflected in accounting practices, law, hiring practices, and so on.) While I enjoy reading/watching fiction and story-telling greatly, I've always felt that real-life doesn't have precise beginning and endings (other than births and deaths). This may be the root cause of my not writing much fiction - yet.
I tend to think of software development as continuous, because I'm usually involved in developing, maintaining, and shipping multiple versions of a software product, not just one "project". After a product version ships, I'm still working on it to fix bugs, and I use it as a base for making the next version. Before one version ships, I may be involved in defining the requirements of the next version, so one "project story" overlaps the next in time. When I worked at Apple, we used the "train" metaphor for one of the products I worked on (the ETO [Essential Tools and Objects] subscription): the train leaves the station three times a year, and whatever is ready to ship gets on the train.
I've sometimes used the term "unconscious waterfall" to describe the serial process used on many projects that I've seen or heard of: a series of phases that start with requirements gathering, a design phase (this seems to be optional), has a long coding phase, and a testing (and fixing) phase crammed in at the end (and often the testing phase is too short). Quite often, the phases had beginnings and ends at prescribed calendar times, rather than when the products of each phase were really "complete". Almost all of the people involved in these projects were unaware of the possibility of iterative, incremental, software development.
How many other unconscious choices are we making?