Tuesday, 15 February 2011

The budget

This project's budget breaks down into five spending areas:

The big alarming orange slice (indirect costs) is a standard charge required by the University of London to cover miscellaneous expenses it incurs - indeed, there is a large and powerful administration supporting us. The yellow slice (estates) is likewise a standard charge imposed by the University based on the number of FTEs (Full-Time Equivalents) involved in the project. It's essentially the rent we pay. This is an area where the University actually undercharges (did you know that Bloomsbury is more expensive than Chelsea?).

The blue slice (Staff) is the one that does the actual work. It's designed to provide yours truly and his staff with a competitive salary so that the project gets done enthusiastically.

The green slice is also very important. It might seem a bit high, but we needed to modernize our PCs for this project, and we need a beefy server to have the capability to host several PhilEvents-like sites. In actual fact, the server is going to cost about £6000, leaving us with pretty modest PCs. Since I need a Mac now, and they're absurdly priced in the UK, I'm actually going to have to wait for the machine to do my bidding sometimes.

The red slice is the party slice, that is, it corresponds to the amount of money the project management is expected to spend out of its pocket buying drinks around the various JISC events this money will buy train tickets to.

Spending of these funds is managed by the Project Manager with the oversight (and veto power) of everyone above him in the University's hierarchy.

Projected Timeline, Workplan & Overall Project Methodology


Our timeline for this project is summarized by this Gantt chart:


We are accustomed to a methodology similar to eXtreme Programming, with a bit less peer-programming and a bit more upfront specs. This methodology suits this project well, as it is the outcome of much reflection, probing, and design on the part of the project management, which happens to be from the academic milieu and well positioned to know the end user's needs. Initial specs will be designed covering slightly more detailed user stories than usual (a bit more like traditional use cases) and the key screens in some detail. But these specs will be discussed among the customer reps (including the product manager) in a series of on-paper demos. Then use cases / user stories will be implemented in 1-week or 2-week sprints using peer programming for the trickiest parts. The rest of our methodology is pretty much standard XP.


Management: On-going project management tasks such as keeping track of progress, organising meetings with customer reps, preparing documentation, participating in relevant JISC activities. (Project Manager [DB])

Release planning: Initial gathering of user stories, estimation of effort (Customer reps, Product Manager).

Development: Iterative development of features to fulfil the user stories (Programmers).

Dissemination: Taking care of the project's public representation; participation in relevant JISC events (Project Manager).

Community: Community synthesis project, DevCSI (Project Manager, Programmers).

Evaluation: Evaluation of the project (Project Manager, Product Manager).

Monday, 14 February 2011

The Project Team

David Bourget: Project Manager, Product Manager, Programmer
David serves both as project manager and as product manager -- he manages the release plan with the help of the customer reps included below. David also contributes to the coding effort and contributes most of the formal project documentation.

Vithun Kumar: Programmer
Responsible for implementing user stories, though this being a small project he will perform all roles to some degree. 

Prabhu Seerangan: Programmer
Responsible for implementing user stories, though this being a small project he will perform all roles to some degree. 

Jean-Philippe Cote: Graphics Designer

Chrissy Meijns: Content manager

Lee Walters: Customer rep (philosophy)
Lee is our appointed customer representative for philosophy. His function is to 'negotiate' the release plan with the product manager and provide regular feedbacks on feature demos.

Martin Steer: Customer rep (non-philosophy)

The IPR Question

It has been decided that this project's outputs will be licensed as follows:

Managing the Good and Bad Risks

Like any software project, this one involves a number of significant risks. Here's what we think the main risks are, and how we're trying to guard against them:

Hiring difficulties

Since planning this project, I've lost my developer, Zbigniew Lukasiak, who returned to Poland to work for Opera. JISC didn't give me much headway to hire someone else, so now I'm scrambling to find a developer at the last minute. There's a risk that this will take longer than it should, especially since in the current climate the University of London does not like to hire, even using external funds.

The good news is that the process is well on its way, we're able to pay a competitive rate even for the City, and we're able to hire for more than the project's duration thanks to the funds we've got from SAS. In the worst case the project will only have been 'shifted right' by two weeks on the calendar because of this.

All kinds of delays

Hiring difficulties are just one way that a software project can be delayed. Anything else from corrupt data to bugs in third-party software to bad design decisions can delay a project massively.  We're managing the general risk of delay by breaking down our outputs into small and prioritized packages, which is really the core idea behind Agile.


The other big problem Agile tries to address is lack of output take-up. How can we make sure that PhilEvents and xEvents are big successes? First, we'll focus on PhilEvents, because that's our main output, and its success is going to bring the success of xEvents in its wake. The general strategy to insure that PhilEvents is a success is a) to make sure our target users like it and b) to make sure our target users get to try it. The art of achieving (a) is the art of software development in general - I won't delve into that. Let us say simply that it's a matter of knowing what the user needs and wants the most, and of translating that into a working piece of software. Obviously, the Devil's in the details. As for (b), we're lucky that we can rely on the fact that almost all our target users are already users of PhilPapers, and on top of that we already have a proven marketing formula to reach these people (it worked with PhilPapers after all).

Excessive success

My title for this post alludes to 'Good' risks. That's mainly the risk of excessive success - remember Twitter's serious technical problems about a year ago. We're not very worried about that because we're not really targeting the general public. At least as far as PhilEvents goes, we know the size of the target community (in the order of 100,000 people worldwide), and we know that we can serve a community of that size with relatively modest means. The only worry is if some much larger community started using xEvents, or lots of small communities.

At this stage, to address this risk satisfactorily, all we need to do is respect some basic principles of scalable web site design (principles that I learned to respect after infringing on them with PhilPapers):

Design for caching

PhilPapers' entry listings perfectly illustrate the challenge here. Whenever a paper is displayed, information from about 5-6 other database tables is displayed as well. This makes each entry expensive to render, which makes it natural to try to cache the HTML rendering of each entry. The problem is that a little bookmark checkbox sits squat into the middle of each record. This is user-specific, so can't be cached.

The best solution to that problem is what I call the 2nd Order Template pattern: the output of your template that generates a record is not HTML but another template to which you apply user-specific data. This way the output of the first template can be cached. Sometimes of course it's easier to segregate generic and user-specific content than to use 2nd order templates. Another way to preserve cacheability is to inject user-specific content through Ajax, which is typically the best choice when the content is not visible by default (the 'My bibliography' menu on PP works like that). Either way, one has to think about keeping the expensive content cacheable.

Use memcached

It's tempting to prefer a local in-memory cache (like the one provided by the Cache::FastMmap module in Perl) because that's more performant and easier to set up in a one-machine configuration. But this kind of caching makes it very hard to scale to several servers. Best to go with a caching solution that scales seamlessly to a multi-server set up.

Design for a master-slave setup if possible

It's a lot easier to scale to a multi-server setup (including multiple database servers) when you can restrict writes to a subset of your users small enough to be handled by one server. This could simply mean restricting writes to people who are signed in (as on PhilPapers). Provided your app meets that condition, you can use session affinity to make sure signed in users are routed to the master server, and you can multiply slave servers as needed to handle the large amount of anonymous traffic you get.

What to expect from PhilEvents / xEvents

The academic community can expect four main benefits from this project:
  1. PhilEvents will greatly increase awareness of academic events in philosophy both in the UK and abroad, which should lead to an increase in participation and more value for money in the field.
  2. PhilEvents will enable a new level of analysis of research trends in the discipline. A better grasp of current research trends will help researchers and event organisers determine what areas of research need more (or less) attention. 
  3. By providing a suitable dissemination channel, PhilEvents will increase the creation and consumption of videocasts and podcasts of research events, which will increase the impact of research outputs. 
  4. xEvents will empower other communities to support similar services in a cost-efficient manner.
Of course, there's also something in it for the Institute of Philosophy (and, indirectly, the School of Advanced Study): this project will help the Institute fulfill its unique research facilitation and promotion mission.

The xEvents / PhilEvents Project - Overview

Project Rationale

Conferences, workshops, and talks constitute one of the main channels of communication for research outputs. Researchers must systematically keep track of events taking place in their fields for three main reasons:
  1. Because they must attend certain events in person.
  2. Because they must watch broadcasts or recordings of certain events when available. 
  3. Because they must remain aware of the latest research trends and developments.
It is particularly difficult for researchers to consistently monitor all events they might be interested in attending (i.e. to monitor events for purpose 1). To do this, one must consistently monitor both events of general interest in the field taking place in one's region and major specialized events occurring around the world. For example, a specialist in metaphysics (a branch of philosophy) with some interest in other areas of research might want to follow all events occurring in her city (irrespective of the topic), but only want to know about events taking place outside of her city if they have a significant metaphysics component. By and large, one wants to attend to an event just in case it is interesting enough or taking place close enough. In many fields, monitoring upcoming academic events based on such criteria is currently impractical because there are no comprehensive, adequately organised listings of events combining geospatial information with sufficiently detailed thematic information.

The lack of adequate tools to keep track of academic events leads to inefficiencies. For example, sometimes the same individual will be invited to give the same paper in different departments in the same city--each time with expenses paid by host the department. This happens because members of department A are unaware of what is happening in department B.

While our focus with this project is primarily to improve access to information about academic events to fulfil purpose 1 above, we will by the same token address a growing need for infrastructure to assist event discovery for purposes 2 and 3. Good indexes of research-grade audiovisual content are lacking in most disciplines, as most videocasting and podcasting repositories which cater to the higher education and research sector focus on teaching material and are insufficiently structured to enable efficient access by research topic. This is the case of YouTube EDU and iTunesU in particular. Good tools for surveying recent events for the purposes of forming a view of the latest trends and developments in one's field (purpose 3) are also generally lacking.

Overall Aim

The overarching aim of this project is to facilitate and improve research through a better coordination and dissemination of information about academic events. This will be made possible by enriching conventional event descriptions with geospatial information and making the resulting data available both directly to end users through convenient interfaces and in interoperable formats to enable third-party applications

Products and Objectives

We will create, maintain, and support two related services: xEvents and PhilEvents. xEvents will be a hosted online service (not unlike Blogger) to build and maintain subject-centric and geo-aware calendars that assist end users in event discovery for the three purposes identified above under the heading of 'Rationale'; PhilEvents will be one such service covering events in philosophy.

Researchers will use xEvents-powered calendars (including PhilEvents) mainly to a) monitor upcoming events based on criteria which combine research topics and location; b) browse past events geographically and/or thematically to identify trends; c) search for recordings of past events; d) submit information to power features (a) to (c).
Copyright David Bourget and University of London, 2011. This blog's content is license under the Attribution-ShareAlike license.