[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Moyoman, a Go playing program
Ah, software engineering, a very difficult task!
There are three major things in my opinion that mess up big projects.
1. Politics
2. Top down thinking
3. Feature creep.
Item 3 makes a complicated project more complicated than it needs to
be. It's almost always the case that a lot of "nifty" features go
unused and add tremendous dead weight to a project.
Item 1 can't be fixed so I won't talk about it other than to say it
involves peoples ego's, power struggles and whether leaders actually
have leadership ability. The more people involved the bigger this
problem becomes in general. If EVERYONE involved had an abundance of
humility probably most large projects would flourish.
Top down thinking is the idea that you can specify a project with some
high level description and then have all the low level details just
fall into place naturally. I think you have to pay a lot more
attention to the small but important details before you can even know
what the overall design should be. As Chrilly says, you can't really
know everything in advance in big complicated projects.
- Don
>There is also the fact that these systems were mostly designed and =
implemented before I was even born. Back then, >most designers probably =
didn't even hear about modular design, object-oriented programming, or =
perhaps even >something as simple as code reuse. Every big old system is =
a mess because of that.
Dear boy, we old guys were also not completly stupid in these days. =
Things have improved somewhat, but 1 million lines are still a big nasty =
monster. E.g. also in a modular design one has to define the interface =
between the modules. Nobody knows in advance exactly how this interfaces =
should be. It is like an earthquake, if one detects during development, =
that the defined interfaces are not practical. One consequence is: =
Everyone avoids such changes, although no one is happy with the =
interfaces and has the fealing that there should be something changed. =
This is only done, if a major change is unavoidable.
A simple example: In a big system for process control I worked with the =
meaning of a parameter was implemented against the specification. "Up" =
was in interpreted as "down". Some day someone detected the bug. But the =
other developers had learned to live with this behaviour and fixing the =
bug broke everything. After very long discussions it was decided to =
leave the module as is and change the initial specifications.
The point here is "after long discussion".=20
It is well known, that the average producivity in such systems is about =
3000 lines/man year or about 9 lines/day. One can ask, if the =
programmers are drinking just coffee. Yes they drink most of the time =
coffee. This is what you do when you sit in a meeting. Or you write some =
reports or answer some emails from other project members. Doing =
programming becomes a minor point in these projects. Y=F3u do it at the =
evening or when the boss is one holidays and you have finally some time =
were nobody disturbs you.
These limitations of big projects are deadly for a game-playing =
programm. Doing game development is essentially a trial and error =
process. Even after 10+ years of professional chess programming, I =
usually do not know the full consequences of a new feature. I have just =
to try it out. Only 1 out of 10 ideas are then really an improvement. =
There is also a close interaction between the parts. E.g. If you =
implement some selective search techniques like the NullMove, the =
evaluation function and/or the quiesence search must be clever enough do =
detect threats. You can seperate the parts on the syntactic level, but =
you can not define away this semantic dependencies.
Best Regards
Chrilly Donninger
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/