I've been discussing the finer points of how to provide software to faculty, staff, and students at work lately. There's two schools of thought to software provision: one is to find an application that is extensible and can be modified to support a user's request for a type of functionality; the other is to provide focused software installations that meet the user's functional needs. It's hardly a new argument, as can be seen through the seemingly generations-long debate between vi and emacs, among other things.

The side that I've come down on is that it is a more effective strategy to provide users with a focused solution when they come a-knockin', and base that solution on a good sit-down with the users to see what their real requirements are. My colleagues have the opinion that repurposing an already-supported tool is a better solution, because it a) makes use of technologies we already support, and b) is a good promotional tool to get them to use the technologies we have in place for other purposes.

I have a bit of a problem with this last argument. Tim Bray recently posted a bit about screwdrivers; Bray talks about the benefit of having several different types of screwdrivers, each with a specific use, rather than a multi-bit screwdriver when working around the house. On the surface, a multi-bit screwdriver is a great idea; it takes up less space, can conceivably do the same things a range of screwdrivers can, and conveniently carries everything it needs with it. Of course, it doesn't always work well; sometimes the bits fall out, sometimes they're too short to fit in the area you're trying to drive the screw in, etc.

I think the same thing is true in software choice; the example that I brought up in the discussion was blogging software. When you present a piece of software to a user to solve a given problem, such as blogging, you inherit a set of user behaviours and expectations around that software. For example, if you provide someone with a piece of blogging software -- regardless of what it is -- the user expects that there will be comments, trackbacks, categories, the ability to save drafts, and chronological posts. The user also expects a certain kind of workflow, and if the software you present them with doesn't match their expected functionality, or works against the type of workflow they are expecting, they won't accept the software.

Another issue is primary and secondary focus, and the affordances each provides. Most software is written around a primary focus; Movable Type's primary focus is blogging; Word's primary focus is word processing, etc. Sometimes these packages have add-ins that add secondary functionality. Movable Type can be used to publish a journal or magazine, for example. The problem with this secondary functionality is that it is invariably guided by the primary functionality. To bring forward an example, we could look at Moodle and its blogging add-in. Moodle, for those who are not aware with the software, is a learning management system. This is akin to a content management system, but geared towards classes and educational use. One of Moodle's central pieces of functionality is its forums; it was, in fact, some of the very first functionality of the software. And this is clear in the approach Martin Dougiamas, its chief architect, takes towards blogs. Blogs in Moodle do not - and if Martin has his way will never - have comments. Martin suggests that if people want to comment on a particular blog entry, that they should create a forum post to discuss it.

The important thing to make note of, and address, is context. The way I argue it is thus: if a person is already using a product and wants to add a piece of functionality to it, then choosing an add-in is the way to go; if someone is looking for a specific piece of functionality, then focused software is a better solution. A couple examples of this have come up recently: one faculty member wanted a blog, and another wanted a wiki; both wanted each outside of the context out of the classroom. As an institution, we are currently very invested in Moodle, and some of our CS staff immediately suggested that we install it for both cases. I had a problem with this, because Moodle's primary focus is learning management (for those of you not in the know, learning management systems are similar to content management systems).

I understand that there are very real issues with regards to systems maintenance. It's untenable to install and maintain a new system for every single user, and there are occasions where it does make sense to extend an existing piece of software. That being said, installed software that doesn't match the user's expectations and behaviour is software that is set up for failure. And what's worse - maintaining several active systems, or maintaining a bunch of orphaned systems?

I think that the way to get people to use the software you install is to install software that people will use. It serves an IT department's purpose to repurpose existing software and try to shoehorn it into the user's requirements; but it doesn't serve the user's needs.

What do you think is the better strategy?