Those that are interested in the open-source world have probably heard of
Eric S. Raymond's paper entitled "The Cathedral and the Bazaar":
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
Those that did not read it - I can recommend them wholeheartedly to. One
thing I did notice was that I did not apply the bazaar model he proposes
too much. I believe it is a safe estimate that I did at least 90% of the
coding involved in working on the Freecell Solver core, and some issues
involved in integrating it into existing programs. (albeit I cannot thank
Stephan Kulow, Markus Oberhumer and Adrian Ettlinger enough for their
contributions and input). But here are some reflections regarding the
lessons learned from it: (I'm not going every one)
1. Plan to throw one away. Done. The initial (and badly designed) Perl
version is no longer operational. Since then, the code has not been
entirely re-written once, which would make Joel Spolsky happy. Nor do I
intend to re-write it in the future.
2. Smart Data Strucutures and Dumb Code. I'm really proud of the data
structures in Freecell Solver, but then again I'm not an AI expert. I
tried to avoid using Linked Lists as much as possible, and I don't have
classes to abstract arrays and linked lists. But then again, I'm not sure
I can afford to. Of course, Freecell Solver was not designed with smart
data structures in mind, and part of the code was quite innovative due to
the fact it used meta-moves instead of atomic moves.
3. Always start from something someone else wrote. Was not luckily
followed. I believe we will see more Freecell Solvers to come, each one
boasting something else.
4. Borrowing ideas from other people. I can happily testify that I follow
it. I mention the people in the AUTHORS file, albeit should also dedicate
a web-page for them. PR counts.
5. Treating your users as co-developers. Not too much here. I do post
descriptions of what I did, what I plan to do and how it will affect the
users to the mailing list. However, I don't expect too many of you to
understand it, because it is rather internal stuff.
One way to make the situation better is to have better social engineering
skills. Congratulate people for whatever effort they took, etc. This is
something I need to work on, because my first instinct is to say "nice,
but I would have done it this way and that". I often phrase critiques or
Suggestions as accusations. (that may have been the case of two of the
wars that happened here, albeit I still think that using an
MS-Freecell-like move representation internally was a bad design
decision).
Another way, which requires more effort is to maintain an architecture
document. I believe the Freecell Solver architecture is sophisticated
enough to justify such a thing. While seasoned programmers (who are
willing to get used to some macro hell) may be able to understand the code
based on the comments alone (once I make sure there are such where
appropriate) eventually, I still think you need to understand the top-down
way in which things are falling apart.
So an architecture document with some pseudo-codes, explanation of terms
(Freecell Solver has a lot of jargon which I associated with it), and
stuff would go a great way. Also, an LXR image (Linux Cross-Reference) of
the Freecell Solver code would also go a long way. I know where to find
everything, but most people could use a hyperlinked version. This will
require very little effort as CVS does the hard job for me. (God bless
tags)
6. Being friendly to users and newbies. I could say I was. I answered
questions politely or either noted it was a bug or a misfeature. In case
the situation repeated itself, I looked for a workaround.
I now think it could be a good idea to integrate the MS-Freecell moves
adjuster code into the command line executable. Not the library for now,
albeit make sure it is available for people to use. Also, I should put a
note to windows users somewhere on the site where everyone can see.
7. A Category Killer. Bazaar or no bazaar I can humbly claim that Freecell
Solver has become the category killer as far as the niche of Freecell
solvers is concerned. Whether it stays this way has yet to be seen. (that
depends on Bill Raymond as well)
One thing that is important to realize at this point is that you still
have to listen to the users. I plan on integrating Patsolve's logic next
so Freecell Solver will have a more decent support for solving games using
Atomic moves. I am indebted to Tom Holroyd for coming up with the
algorithm to optimize it. (and for taking the CPU time to run the
simulation). This will also give the possibility to run several scans in
parallel, and other such goodies, as well as to specify parameters on the
command line.
I will also, on a lower priority work on integrating the mixed
depth-first-search/breadth-first-search scan. That will hopefully enable
near-minimal solutions, albeit from playing with FC-Pro, I cannot say
Freecell Solver has always fared worse.
Regards,
Shlomi Fish
----------------------------------------------------------------------
Shlomi Fish shlomif_at_vipe.technion.ac.il
Home Page:
http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif_at_iglu.org.il
He who re-invents the wheel, understands much better how a wheel works.
Received on Wed Sep 11 2002 - 16:51:46 IDT