Tonight, I reached a good point with my coding of Tetris: I managed to get falling pieces that I could move horizontally. Some big things are missing: boundary detection, the creation of the "mound" (the pieces that collect at the bottom of the playing field), and the randomization of the pieces themselves.
One of the things I have learned in my day job is the importance of good requirements. Simply put, requirements tell me what to build. It's not a blue print, but more of a list of needs and wants. Some Examples: The system needs to accept XML. The system's screen should be light green.
When I started this, I thought I could code up this game from scratch. Instead, something as simple "what colors should I use for each shape" kept nagging at me. For my "requirements", I cast about the Internet and happily found Tetris Concept, a Wiki and a Forum for all lovers of Tetris. On this site, I've found not only the colors of the shapes, but the conventional names of the shapes. These details, along with many others, constitute the "requirements" for my version of the game.
Of course, having a good "reference implementation" helps. I've been relying on the Tetris that I downloaded for my iPod. I also found a very nice Tetris clone on Google Code. I've enjoyed playing this version, but I've so far refrained from looking at how the author (exeQtor) implemented his game. As he puts it: "The good thing about Tetris is that it has a very well known gameplay mechanic and it is relatively simple to program but challenging enough for not being trivial." Precisely why I'm doing this!