devlog

I’m living in a software-oriented version of that Monty Python sketch that begins, “I’ve come for an argument.” Wilfried always accused me of being a software critic, a term I have resisted in that a critic is not usually understood to also be a practiser. But perhaps it’s an appropriate term for rattling around digging around peoples’ codebases and helping them work out how to refactor and repackag - and most crucially (or critically) to document intent - to expose more of the ongoing working of the design, decision and planning process involved in software development to people who aren’t participating in it (yet).

I am lucky to have the friends i have here in England, this is what keeps me returning here for long spells. I’ve missed out on a long cycle of the KnowledgeForge development process, having spent the last happy year in Cambridge (Mass) writing almost no software. I want to get more involved now; in helping to build the CKAN application. The Comprehensive Knowledge Archive Network can be viewed as a data-generic version of the OSGeo metadata repository project, and I think the two will eventually become the same thing for me.

In the meantime, knowledgeforge’s domain model got hived out as a separate project - a meta-model mapping layer that supports SQLObject now, and in future theory a raft of different ORM or OODB backends. It’s a nice project and just needs a dummy application to run tests against, and doc coverage fixing up, to make it really distributable.

I moved my own simple geodata metadata management engine to KnowledgeForge, and my hope for converging it with CKAN is to be able to:

• remove from geometa its direct SQLObject dependency and have it use domainmodel underneath
• remove domainmodel’s django dependency and replace it with the tiny dispatcher / CRUD interface from geometa
• eventually replicate the basic geometry support added to SQLObject in geometa now, in the metamodel part of domainmodel
• slap on OAI-PMH, WFS-Simple, etc, metadata exchange interfaces onto everything in sight.

But this all may have to stay on the back burner for now, because i’ve been approached by Tav to help him make more of ESP now. I’ve been following from a distance the adventures of “The Plex” for years, listening to Tav give presentations at dorkbot or explain to friends some elements of his vision, which taken completely is to replace everything with something better. The Plex is a kind of - a meta-framework, or a meta-architecture. In the way one becomes sick of solving a slightly different looking version of the same problem over and over, Tav’s work is an attempt to solve the meta-problem. (There’s a ring of this in the meta-ness of domainmodel too; and both remind me of my and Schuyler’s old work on the ontomatic and the epistomat. But nobody i know has an epistomat yet, not even me.)

Aside. Why this tendency towards a “framework”? Most of my friends have written one, despite the proliferation that exist. I am programming because I want to solve a meta-problem for any given problem I am working on. I stop programming because I’m bored with solving the same problem over and over. Observably, the framework is a level-of-things that We naturally wind up at. Then Rails induced a lot of people to believe the idea was commercialisable, and there was no holding back.

What constitutes a framework? John refuses to call his work a framework, though it has all the behaviours. Tav proudly calls the PlexNet a framework, though it’s envisaged to do a lot more than that. clkao would refuse to hear the word said in his presence, and insist on referring to a “frame-sausage” throughout conversation./Aside

I didn’t come here to talk about making my own meta-framework - i came here to talk about inventing my own development meta-methodology. Remember Journalling and how simple that was? So that’s one piece in a bricolage of programming practises - writing down as much as possible about why you are doing what you are doing. Another is Test First, rather crashingly so; my mind goes back to the literate programming crowd at eurofoo ‘04 and the talk of Literate Testing that I heard there. Another practise is Death By Diagram- everything gets drawn, if you can’t draw it it doesn’t exist, all this goes in the documentation trail, plus you are generating graphs from the code the whole time and the drawings are keeping you honest about the designs. Another is Be Polite, You Fucker and stresses the importance of not succumbing to unnecessary rages about things because what is the point, life is short and arguing about software should be fun.

In terms of the design process I am trying out thinking of it as “Goals, Roles and Interfaces“. (I think there is a bit of Bruno Latour’s actor-network theory in this and reference to the flashcard- and userstory- based social methods of software design from the earlier days of OO theory.) What makes it a bit less like that is it takes into account the goals and roles of everyone involved with the system - the people collaborating on designing and implementing it - prospective contributors known or unknown - the “users” of the system and their responsbilities within it and what they are trying to achieve by participating in it. Interfaces of course is where Exchange happens or Abstraction happens - something is translated or processed - something combines a set of translations, or processes, and presents a different interface to them.

This all sounds enticingly abstract, doesn’t it, and we’ll see how trying to emphasise these bits of practise works alongside strong architecture opinions which deal with the specifics. I don’t want to talk about the specifics because i can’t dictate them - situation can be so different - and often i can’t change them. So I am offering what seems to be on the periphery of a specific core. Like a framework for not having a framework, it can be a kind of methodology for not having a methodology.