|
Programming/Development Strategies
Background: Chess Strategies:
You see far enough to catch the potential problems/winning and make the moves in the right direction.
What is the equivalent when it comes to the development world.
Especially the factors when you wouldn't simply rely upon the factors and make the strategies.
Thanks.
artist
Tuesday, January 20, 2004
Risk management: think of what might go wrong, and have a plan to minimise each risk and/or to deal with each risk if it materialised ... and/or finish the riskiest bits first.
Christopher Wells
Tuesday, January 20, 2004
There isn't really an equivalent. You generally can't see far enough into the future to know what you're going to need to do.
Heck, sometimes you don't know what your business analysts will come up with TOMORROW, let alone next week, month or year.
Two golden rules:
Fix bugs first. Always be ready to release *right now*, even if you don't provide anything useful. If you're delivering nothing much, at least deliver it without bugs.
After fixing known bugs, do the one single thing that's going to get you closer to the goal as you understand it right now, and do exactly what you need to do deliver that next feature. Don't go off on a 3 week tangent building glorious infrastructure that will save 2 hours of typing every couple of weeks.
Andrew Lighten
Tuesday, January 20, 2004
i usually write the programs, then go home and drink by myself until I start weeping silently. that is my strategy.
Tuesday, January 20, 2004
I go with the backgammon strategy: play the odds and expected value.
Tom Vu
Tuesday, January 20, 2004
There IS an equivalent, it's called "decision trees" and it's a standard part of any operations research curriculum.
http://www.mindtools.com/dectree.html
Joel Spolsky
Tuesday, January 20, 2004
"What is the equivalent when it comes to the development world"
You mean when it comes to actually writing code? I usually write something that works first (or at least try to :), and then check that in. If it requires optimisation or something then I refine it 'n' times until done. The process isn't too efficient because you don't know all the possibilities up-front (new requirements, whether it will be fast/memory efficient enough, etc.), but since I don't have a crystal ball I have to go with that.
Wednesday, January 21, 2004
I wrote an article on this. For french readers: http://membres.lycos.fr/astrobe/chess.html
IMO the analogy between chess and programming lies more in the right evalation of some important factors ( in the chess game : the postion ) than in how many plies you can forsee; Paul Morphy stated that he was only computing 1 ply forward; he was playing only positionnal game.
Astrobe
Wednesday, January 21, 2004
any one want to do a transalation on the french article for non-french-speaking people, like me? :)
eddy
Wednesday, January 21, 2004
Capablanca said the same thing, 1 move. Only thing is, these guys could play about a hundred blindfold games at once, win every game, and recount the score (moves) to each game afterward.
But if you can do that, then you shouldn't have any problem. ;-)
Brian R.
Wednesday, January 21, 2004
In chess, your game plan can change in one move, you have to recognize when it has changed.
The other guys were right. Risk mgt., etc. It's more suited to decision making than actually doing something, like coding. It helps build logic skills, too.
Brian R.
Wednesday, January 21, 2004
Eddy:
I would love to translate at least the quotes from Chess masters that I've found fitting strangely well to programmers. Unfortunately ( as you see, maybe :) my english is not good enough.
Astrobe
Wednesday, January 21, 2004
> any one want to do a transalation on the french article for non-french-speaking people, like me? :)
I find a strong analogy between programming and chess. Chess has the reputation of being a game for intellectuals, for maths wizards because it seems complex mostly because of the movement of the pieces. Programming and IT have the reputation of being complicated, and of being the domain of maths wizards, mostly because of its cryptographic aspect [or appearance]. The first thing a chess neophyte must learn is the movement of the pieces. For as long as he hasn't mastered [learned] his pieces, the novice player cannot play correctly, because he spends most of his time "remembering" the movement of the pieces; he has a lot of trouble anticipating adverse play. The first thing a novice programer must learn is the syntax of the language and its primitives [low-level library functions?]. For as long as one doesn't know all the possibilities of the language, one writes bad programs; one sometimes writes a lot of code which [already] exists as a primitive [library function], which complicates the programming. Languages like 'C' seem to me like a game of chess where each of the 32 pieces have a purpose [direction, order] that is [would be] appropriate to that piece.
After the purpose of the pieces has been acquired and mastered, comes the learning [apprenticeship] of positional play. Positional play is the art of placing pieces at strategic positions, for the purpose of maximising their effectiveness. The judgement [assessment] of a position depends on certain well-identified [well-defined] indexes [criteria], for example a castle's occupying an open column, occupying the centre, or the structure formed by pawns; but the ability to combine them and to gauge some pieces with respect to other pieces is acquired as games are played. Evaluation the position is the major characteristic that distinguishes the amateur from the master. In IT, once the syntax and the primitives have been learned, it's necessary to learn to program. The art of programming can be reduced to factoring, which means isolating sequences of instructions that will eventually recur and which accomplish an identifiable operation. The most common programming error is to use the editor's copy-and-paste instead of grouping recurring statements into a subroutine. This wouldn't be a bad error if it only cost kilobytes; unfortunately if such duplicated code contains {"une faute de frappe" ... I think this this means "a typo"} or a bug, copy-and-paste has multipled the places and the time required to correct it. Another error is creating functions which fulfills several roles (in chess if a piece defends several strategic points then it's an ideal place to attack and is consequently a weakness). One can factorise a program in different ways, one can even choose to not factorise certain parts of a program (usually the most inner loops) to make it run faster. The ability to determine a program's requirements, and to factorise it accordingly, improves with practice.
Certain quotes from chess masters could well supply an equivalent to the quotes of Chuck Moore, or complete them: (from the "Breviary of Chess" of Xavier Tartakover) avoid {"touffues" ... I don't know what this means ... perhaps "complicated"} positions which make defence difficult. Economize your pieces, especially in attack. Think of your reserves. Don't waste time wanting to win one. (A. de Rivière) Help your pieces so that they'll help you. (Morphy) Don't be too dogmatic in your decisions. Hold high the banner of "rules" without at the same time lowering the tent of "exceptions". The pieces serve you devotedly [faithfully]; use them skillfully. Beware [mistrust] the brilliant, enjoy simplicity, which exists at the peak of art, and which therefore also has reason to exist in chess. Beware also plausible attacks, they don't always respond to the needs of reality. Each position, no matter how simple it seems, needs to be made deeper. Make, as soon as possible, a plan of action: it's better to have a bad plan than no plan at all. (Tartakover)
Christopher Wells
Wednesday, January 21, 2004
Astrobe, your english seems good enough to me. A mon avis, les anglophones en general ont beaucoups moins de peine en lisant un anglais imparfait que les Francais avec un tel francais.
Christopher Wells
Wednesday, January 21, 2004
> Paul Morphy stated that he was only computing 1 ply forward; he was playing only positionnal game.
> Capablanca said the same thing, 1 move.
> The art of programming can be reduced to factoring
That's why books like Code Complete and Refactoring are so valuable. I evolved one piece of software over the course of 10 years. In that situation, it's impossible to know at the beginning what the eventual requirements will be (because they evolve each year), or the consequent eventual design: so 'positional' play lets you evolve a design.
Christopher Wells
Wednesday, January 21, 2004
Christopher:
Wow! I did not expect that someone would be brave enough to actually translate the whole article ( I bet you're one of these bloody canadians :). That's pretty impressive given that it is somewhat technique.
The last quote from Tartakover is my favorite.
"faute de frappe" is indeed a typo,
"touffue" is something like clamped up, dense and messy.
Thanks.
Astrobe
Wednesday, January 21, 2004
> bloody canadians :)
That's right. If you're interested you can recognise non-American from a few spellings like "centre" instead of "center", and "factorise" instead of "factorize".
It is a good article! I'd forgotten the experience of being new to chess or new to programming, but I think you described it well.
Can you explain "Ne perdez pas de temps à vouloir en gagner un"? What does that mean, from the point of view of chess and from the point of view of programming?
Christopher Wells
Wednesday, January 21, 2004
<< Can you explain "Ne perdez pas de temps à vouloir en gagner un"? What does that mean, from the point of view of chess and from the point of view of programming? >>
Don't waste time wanting to win one:
It happens that some move seems to gain time ( by attacking one opponent's piece ), but in fact puts a piece on a lesser square, so that one will have to move it again. It is a temptation that happens often during the opening
As for the programming point of view, it can be for example writing quick-and-dirty code; cf. " The source of Bad code" in this forum.
Astrobe
Wednesday, January 21, 2004
woah many thanks to both of you, the original author and the translator.
most interesting article. this translation makes more sense than the one from altavists babel fish.
thanks
eddy
Wednesday, January 21, 2004
Try http://www.easygen.com it's a free download and makes building web scripts a dodle
Mary White
Friday, January 23, 2004
 Recent Topics
Fog Creek Home
| 
