Monomorphic

In his first amendment to Human, All Too Human (1886), entitled Miscellaneous Maxims and Opinions, Friedrich Nietzsche states that

300. HOW FAR EVEN IN THE GOOD THE HALF MAY BE MORE THAN THE WHOLE. — In all things that are constructed to last and demand the service of many hands, much that is less good must be made the rule, although the organiser knows what is better and harder very well.He will calculate that there will never be a lack of persons  who can correspond to the rule, and he knows that the middling good is the rule. — The youth seldom sees this point, and as an innovator thinks how marvelously he is in the right and how strange is the blindness of others. (Helen Zimmern transl.)

Friedrich Nietzsche did not describe software making – I can only assume that he was describing authors and ideologists – but this seems to capture the difficulties of software development only too well. And it seems to give a recipe for how to overcome the communication difficulties (abandon exotic, over-refined solutions and focus on an easily understood middle ground, so that everybody can get together and comprehend the architecture). This was originally published in 1886.

With that, merry christmas!

Recently I watched a friend give a presentation on a research topic he’s been working on for years. I found the presentation to be fascinating, and the clearest explanation of his work that I have seen to date. But I felt compelled to criticise him on one point.

In order to lighten up the speech a bit, he had chosen to include characters from a popular science fiction movie on every other slide, using them to explain the results he had attained in theoretical computer science. The link between the characters and the results was nearly non-existent; the pictures were clearly only there to lighten the presentation up a bit. I had been irritated by people’s tendency to do these things for some time, so I decided to point it out. One extreme example of this tendency gone too far occurred recently in a presentation about the database CouchDB – readers can Google for the slides to see the full controversy, though they are somewhat NSFW. (I don’t want to make moral judgments in this context, but I think the academic/professional domain can be kept free of these controversies. Save those battles for where they belong!)

So there’s a tendency for people to sugarcoat their presentation topic sometimes. The arguments in favor of doing this are that it can lighten an intrinsically heavy subject a lot, and save people from nearly falling asleep from compounded boredom (such as a conference where 30+ presentations about results in theoretical computer science are given). Essentially it mixes in some sugar with the sour stuff, yielding what might be called a sweet and sour talk. The medicine becomes easier to swallow.

But isn’t there something essentially contradictory about mixing contemporary pop culture so freely with results that, in this case, were about essentially pure mathematical theory? For one thing it takes the essentially perennial and debases it, linking it up with images that are hopelessly stuck in a short timeframe. For another, it can be seen a vote of non-confidence in your own ideas. It can be seen as saying “I know this is boring and useless to you, so please bear with me, and look at these amusing pictures until it’s over.” I’m not a good presenter, but in order to become one, I think I need to have sufficient confidence in my ideas to present them unsweetened unless the circumstances are extreme. I need to make my audience see the value in my ideas. Also, it’s quite different if the sugar coating is of the kind that helps people get into your idea, or if it’s the kind that just distracts (this case).

My view is therefore that one should use one’s lumps of sugar with restraint. Maybe a situation where this is called for is when the audience necessarily contains some people who are on the level that you need to be talking to, and many other people who are not on that level, and cannot possibly be brought up to it. In this situation, the sugar might be used to keep the second group somewhat alive and alert. And this is in fact the kind of situation my friend wrote the presentation for originally. So, no scorn on him, just a word of warning to the general public!

Following a comment on my previous foray into bibliography management systems, I had a look at the product known as Mendeley.

In order to evaluate Mendeley, let’s ask ourselves what we want from a bibliography management system in the modern research environment. At a bare minimum, we want an easy way to catalogue and search PDF documents, and of course compile the all-important reference list at the end of the laborious writing process. Mendeley does this, as well as bring a social networking aspect into the picture. It tries to recommend papers that are relevant to your work, as well as give you an easy way of sharing interesting papers with colleagues.

In contrast to Aigaion, which I wrote about previously, Mendeley is not a web based system but a desktop application. This definitely has benefits as the interface is quite slick. I can set the application to watch my “papers folder”, and any PDFs I save to that folder, or its subfolders, will automatically be scanned and entered into Mendeley. Metadata, such as author, title and references, is automatically extracted from the document in most cases, though I found I had to manually revise it sometimes. There’s a built in command that searches for the metadata by paper title on Google Scholar, which comes in very handy in such cases.

Mendeley is built around an internal PDF viewer where the user can highlight text, add little stickies with notes, and so on. This works quite smoothly, but on the Mac platform, it’s definitely not as polished as the Mac’s built in Preview PDF viewer. Mendeley is using its own PDF rendering layer, and it shows in the slower loading times when you scroll the documents. Some additional work could be done here. This is my only major complaint so far, though.

Much like the Evernote application, Mendeley has the option of storing all the papers on a central server, so that I can easily access them (and any annotations I might have made) from a different computer by signing in with my user name and password and then syncing the files. This means I don’t have to give up the benefits I get from a centralized server. It might be nice, however, to have the option of running my own Mendeley server, so I’m not dependent on the Mendeley company’s server somewhere – but then I would forgo the social networking benefits of course.

This application has similarities to how last.fm is used for music, in that people build a profile based on what they consume. Indeed, Mendeley is describing itself as a last.fm for research (video presentation). Let’s compare research and music as forms of media.

• Most music listeners probably don’t make their own music – most people who read research papers probably write their own papers.
• Songs sample other songs (the remix culture), but it’s relatively recent – researchers have always done this in order to establish basic credibility.
• The atomic unit of music is the song. The atomic unit of research is the research paper (the PDF in today’s internet based world, at least in my discipline) – but could this change in the future? Do we have to constrain ourselves to the article format?

In summary, Mendeley is probably the most useful, workflow friendly bibliography system I’ve tried so far. If you’re in research, I’d recommend you give it a try. If I get time, I plan to also investigate a more Mac-centric tool called Sente in the future.

The Savage Minds blog recommends that you don’t use Mendeley as your main tool yet due to its relative immaturity, but I have seen no showstopper bugs so far.

A senior manager at a company I used to work at once said that (making) software is a very social activity. I didn’t have much experience, and was very surprised at the time, since I had never thought about the human aspect of software development. But of course this aspect is extremely important. For example, in any setting with more than one programmer working on a project, the need for well functioning communication is huge, as much as in any other job I suspect. Projects often fail due to a lack of communication.

Another human side to software development is that some developers, this author included, easily start seeing the code they write as their own intellectual turf. If somebody challenges the developer’s practices or code, offering a better solution, it will be met with massive resistance. Partly out of laziness, but partly, I think, out of a desire to protect their territory and their legacy.

I do this myself more often than I would like. And it leads to bad results because it creates obstacles to communication and means that team members pull in different directions. Thus, somehow the incentives are wrong. If everybody’s goal were to allow the team to deliver a good product quickly, this would not happen. Why is it that your goal after some time with a project sometimes becomes to defend what you have created? Why do we identify with the code we wrote, and not with the bigger project?

This doesn’t mean that looking to your own interests or to your ego is a bad thing – rather that it’s easy to be shortsighted about what is in your best interests.