Playing Tetris in the early nineties, I found that there are some simple heuristics that allow you to play the game with the least amount of risk. ''Would you believe it was for an AI class?''. 1. Always leave a place to put one of the shapes that would leave no gaps, if possible. 2. Never expect a certain shape to appear. 3. Only work with the current piece and the next piece. ''Or better yet, get more points and only work with the current piece (since tetris scores higher with preview turned off).'' ''Or try to understand the random piece generator.'' ExtremeProgramming has some rules that are analogous: 1. RefactorMercilessly / ContinuousIntegration 2. YouArentGonnaNeedIt 3. DoTheSimplestThingThatCouldPossiblyWork In Tetris when you build your structure expecting a long straight piece, you open yourself to risk by building the structure too high, and you have no guarantee that the shape you expect will come into play. If it doesn't you need to madly rush to make the structure smaller. Likewise in programming if you build too much structure early expecting certain requirements, you open yourself to risk by creating infrastructure that is never used, but needs to be maintained. After a while you decide you need to ''clean up'' code. Is this maybe a pattern for areas where uncertainty exists? --FrancisTownsend High-end tetris play also has a couple of heuristics you should probably NOT apply to programming, notably: 1. Cover up your mistakes instead of trying to fix them. 2. Avoid rotating the pieces if you can make a line even if it results in covered up gaps, because at level 50+ speeds the cost of a mis-rotation is much greater than the cost of your structure being one line higher. :) LastObelus ''Level 50+ on what implementation?'' The arcade version is pretty much all I've ever played. --LastObelus [mar 2005] lately I've been playing Quinn (os x version) and today I finally scored more than a million points (1 124 000). My tetris rate was kind of low though, only 53 tetrises. Now, if I could only program at that level... ---- High-end tetris play can be thought of as working close to a deadline (where time is critically low), where getting lines (user stories) is more important than avoiding gaps (smells). Therefore, the analogy of the above two rules in XP would be, when close to a deadline: 1. Build on top of your smells instead of trying to fix them. 2. Avoid refactoring the code if you can make a user story even if it results in smells, because when near a deadline the cost of a mis-refactoring is much greater than the cost of you having more smelly code. What can we learn from the experience of high-end tetris players? [In Tetris when you build your structure expecting a long straight piece, you open yourself to risk by building the structure too high, and you have no guarantee that the shape you expect will come into play. If it doesn't you need to madly rush to make the structure smaller.]: As an experienced TetrisPlayer (at least 10 years ago) I remember, that you needed the tetrisses to get enough points. To do so, I wouldn't ''expect'' a tetris, but instead continuously keep a gap for a tetris open on the left or right. This can be done 'easily' without destroying your structure by fitting pieces partly into the gap in such a way, that it would form one or two complete lines at the top of the gap but retain the shape of the gap. Now, what would '''that''' mean in XP methodology? -- GunnarZarncke Answering myself a few years later (and with more experience with such projects): The large piece which brings a lot of points is the somewhat anticipated large epic which the project owner always wanted to sell and now did. If you didn't anticipate that by ''some'' structure you will likely be unable to do it in time by normal refactoring. Whether this investment comes true in XP depends on the real pricing involved. -- GunnarZarncke ---- I have found it more enjoyable and more productive (mentally) doing PairTetrisPlaying with a friend. --JeffDay ---- This is great! It seems like the perfect foundation for teaching a whole generation of Programmers a development methodology. AlistairCockburn(s) SoftwareDevelopmentAsaCooperativeGame comes to mind as a similar "Do the right thing given you can only predict so far into the future" kind of message. --MichaelLeach ---- To be confused with TesseractShape. ---- Tetris has now been found to be an NP-Complete problem. Draw your own conclusions. http://www.maa.org/mathland/mathtrek_10_28_02.html ---- Strangely enough, the same skills developed playing Tetris tend to serve one well when doing stack gymnastics with ForthLanguage. ---- "Tetris is so unrealistic." See also ForgeCode