This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Autopoesis, Databases And Reference
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
On the nature of structural coupling between companies engaged in a development project. And before you ask, this is what it means. Unless you knew already. The PlayStation Project proceeds apace, along two parallel lines. One is the visionary path - the place where people sit around table and discuss the grand Shared Idea, the form (if you will) of the Thing we are creating. All essential and necessary, no doubt, but the second path is of more interest to me; the Way of Function; what it is that the Thing will do. Much of that is associated with data; many thousands of records of manually typed, carefully checked, thoughfully constructed data that lives in a MySQL database, surrounded by an attendant court of Python scripts that validate, transform and generally munge it, as well as overcoming some of the limitations of the current MySQL release[1], like replacing triggers with continually running background daemons. Our development partner, the people who are writing the bulk of the actual code that will run on PS/2s in living rooms and bedrooms worldwide, need access to this data. So, of course, does the actual game code itself, to do what it has to do; it needs a runtime version of it, a translation from the context in which the data lives now to some other, subtly different environment and set of usages. And so it begins, with me sending a snapshot of representative rows and tables, the output of a mysqldump. However often I come across it, the number and depth of unspoken assumptions that lie in any code, whether it be a program or a database definition, still amaze me. Just as the overall architecture of a system, the UML-level conceptions of objects and relationships, isn't visible from the source-code (and therein lies the subject of a rant about certain weaknesses in open source, but that's for another day), the context in which a database operates is invisible from the dry recitation of column names and attributes that define it. Passing a database to someone else involves whiteboards and a good session with a set of coloured pens. Why isn't there anything about that in the methodologies?[2] A table is not just a table. Nor is it just a set of records that record attributes of some abstract entity that maps to others in a regular and defined manner - one-to-many, one-to-one and so forth. No, a record is the capturing of a related set of data about something in the world, that messy, human-dependent network of relationships and fuzzy concepts. Without being embedded, either for real or by proxy, though conversation, in that world, misunderstandings about what the data represents inevitably arise. But our partner is based Down South, on the coast below London where old, rich people go to retire. Or something like that; we're nominally located in the Midlands and I spend most of my time even further North. We don't have a whiteboard that big, so we fall back on email and, while writing a long and careful set of comments on someone else's SQL, I remembered the Zope reference pages. In the user comments, there's this little exchange:
Anonymous User - June 26, 2002 1:43 pm: The reference describes nearly nothing when you don't know the solution! Examples are absolutely necessary.
Anonymous User - July 14, 2002 5:21 am: Strongly disagree. This is a reference, not a tutorial or explanatory text.
Anonymous User - Aug. 20, 2002 11:13 pm: A reference doesn't contain explanatory text?
Anonymous User - Nov. 12, 2003 10:52 am: Look at http://www.php.net : it's both a precise API reference for PHP developers, and a tutorial full of interesting samples. Apart from the Zope Book (which efficiently sums up the ZMI) I have rarely seen such a poor pedagogical and practical approach as among the zope documentation.
The deficiencies of the Zope project's approach to educating those who seek to learn it are well documented elsewhere, and I don't propose to go over it again, only to point out that I'm in agreement with the first, third and last comments. Firstly, you cannot sufficiently explain something without reference to how it's supposed to fit into the world. And secondly; examples reveal assumptions and contexts - the way in which the designers thought about how a system should operate. A reference document, or a SQL definition, may be exact, precise and to-the-point. Yet without hearing from the humans who wrote them, one can understand only the bare minimum from them.
[1]No, please don't email me links to PostGreSQL. Everything in life has pros and cons. [2]That'sunfair, of course :)
Previous Topic
