Wandering Thoughts archives

Partial entry syndication feeds and updated entries

I've written about my unhappiness with partial entry syndication feeds before. Another limitation of partial feeds that only struck me recently is that you may well get no sign that an entry has been updated after you've read it.

With a decent feed reader, any change to the text of an entry in the feed that you've already read gets flagged. With full entries in the feed, this means that updates get flagged. However, with a partial entry the update may well be made to stuff that is after the partial entry cutoff point; it seems to be common to put the 'updated:' notes down at the end of entries, for example.

(Admittedly this only applies to updates to entries that are recent enough to still be in the syndication feed.)

A good partial feed system would put in some explicit 'updated on' marker at the end of entries when the entry was modified after its initial publication. However, this would take extra work on the part of the software and I don't think I've seen a package that bothered.

(In theory you could just update the entry's Atom 'last updated' element or the RSS equivalent. In practice, I don't believe that very many syndication feed readers will flag this as an actual change, and many of them don't make this date very visible to the user anyways. Changing the text makes it more likely that the user will be able to figure out why an entry is flagged.)

One limitation of internal charges

One of the things that is popular in universities and companies is charging for internal services. The hope is that this will cause people to be 'efficient' in both what services they use and how they provide services, much as if the various groups were real companies doing business with each other. However, this is an illusion.

One of the ways that this is an illusion is that a university cannot let a consumer group fail if it cannot pay its bills or doesn't have any money, the way a real company would fail in the same situation. Ultimately, someone in the university is going to get stuck with cleaning up the messes, whether or not those cleanups are funded.

(Sometimes universities can't even really let a service provider group fail that way either, whether because of policies on staff employment, issues of morale, or the need to keep expertise.)

That everyone is actually operating in a common shared environment makes any messes worse; groups are far more affected by each other's problems than they would be if they were independent companies. In other words, messes are (to some degree) shared messes, and worse, messes that affect the university as a whole, because to the outside world we are a single organization.

(This is going to be especially acute for things that are legal requirements, such a student privacy.)

There is at least one form of company that operates in an environment very much like this: banks. For some reason I do not see anyone rushing to hold them up as a model for internal charging and operations.

One problem with distributed identity systems

From one perspective, using someone else's identity system sounds very nice. Imagine the convenience of being able to just use LiveJournal user accounts on your site, or (for an example closer to home) a central university database of campus-wide accounts.

(Yes, I am conjoining 'identity' and 'authorization' here, because I believe that it's what a lot of people do in practice when thinking about this sort of thing.)

The problem with this is that any time you use a distributed identity system, you are delegating the ability to establish and retract identities on your system to some remote third party. Even if you trust them not to be malicious, can you trust them to take (enough) action if one of their users is merely abusing your system?

The inevitable result is that attempts to use distributed identity systems generally grow at least local blacklists, and may have to go all the way to local whitelists. At this point you have less of a distributed identity system and more of a global identifier and outsourced password handling mechanism.

(Not that this is useless; users appreciate not having to remember yet another identifier and password.)

I believe that a genuine distributed identity system can only thrive within an organization, and only then when all of the bits and pieces involved have the same policies on use, abuse, and termination. This probably rules out universities, or at least large ones.

Explaining some university staff peculiarities

I think that universities not having a return on investment as such may go at least part of the way to explain some weird university behaviors around staff. The core issue is that without an ROI it becomes difficult to see the cost of how staff spend their time.

(With a ROI for projects it is easy to see how having staff spend their time on a lower-ROI activity more or less directly costs you money.)

Not only does this effectively make staff into a constant sunk cost regardless of what you have them do, it means that it is very hard to cost-justify spending more money on a problem when you could just throw staff time at it. Until something gives way explosively, one side has at most fuzzy costs while the other side has very firm numbers; unless the firm numbers are small, you can guess which side is likely to win.

(One degenerate case is that if you just use staff time, you don't have to persuade someone to give you more money.)

Without being able to clearly assign costs or benefits to staff activities, a university lacks good signals on what is a sensible allocation of staff time. As a result, it is easy to slip into what an outsider would consider very peculiar decisions about what (expensive) staff spend their time doing, because staff time is as likely to be decided by what people can do as by what people should do.

(This is not just an issue of management; even if the staff themselves are making the decisions and want to make smart ones, they can be at least as lost in the forest as everyone else.)