Chimps are vicious bastards—but smart

A chimp in a Swedish zoo has been observed not only to use rocks as weapons by flinging them at zoo visitors that annoy him, but also stockpiling stones and using rocks to break off bits of concrete to use as projectiles. The real significance is that

while many apes have been observed collecting stones for nut cracking or other planning behaviour, it has been unclear whether the ape was doing the work to meet a current or future need: that is, is the ape looking to crack nuts because he is hungry now, or because he expects to be hungry?

Santino's stone-gathering however, is a clear case of planning for the future, [a researcher] said, since the calm manner in which the chimpanzee collected the stones differed from the agitated state in which he later hurled them.

Given all of the above, I also think that Santino is a very appropriate name…

Seriously, though, I find this rather fascinating, and it serves to strengthen my conviction that the difference between human and non-human animals, in intellectual terms, is quantitative, not strictly qualitative. It may be a very great quantitative difference, mind—I’m under no delusion that they’re just like us; but notions that the intelligence of animals has some strict limit where we set up a qualitative criterion to differentiate ourselves from them—such notions have a consistent tendency to fall apart.

What is the responsibility of the advisors?

The Abu Ghraib torture scandal was exploding, and fellow panelists learned that Mr. Yoo had written secret legal opinions saying presidents have sweeping wartime power to circumvent the Geneva Conventions.

Charlie Savage and Scott Shane, New York Times

Communication and assumptions

When I was hired to write the assignment module for eRezLife, in 2007, it had a fairly different scope than it does now. The core is still the same—we have a set of students and a set of residences; students have preferences about the sort of rooms and roommates they want, and residences have rules (preferences) concerning what sort of students should be assigned to them; and we want to efficiently produce a good mapping between the sets. That core hasn’t changed.

What has changed is everything around it—so that we now want to track history, run multiple concurrent sessions, and so on. This doesn’t entail a lot of fundamental changes, but the algorithm does now have to track the state between subroutines, and a lot of the selection procedures are affected (parallel and consecutive sessions affect room availability). Additionally, the need for an event history necessitates the creation of a whole bunch of new tables, more logic at certain junctures, and so on.

Of course, none of this is very surprising. Projects have a way of growing, and new requirements emerge; additionally, even though we have some pretty solid write-ups by now defining the behaviour, workflow, UI, and so on, there are always minor details where it turns out that my boss had implicitly assumed something that just wasn’t so. This is not a criticism of the development process, requirements gathering process, or any such thing—we started out weak but have worked out a pretty solid process by now; it’s been a very real process of growth and learning for the company.

My current frustration comes from communication issues, mostly from the higher-ups a bit further from the development process, but occasionally from co-workers. Let me prefix this by saying that a very big part of this is my own psychology: I’m not trying to assign blame; I’m trying to figure out why it is that I keep feeling irritated in order to see what I can do about it. That said, here’s what happens:

When I started working on this project, alone, and with a different scope, I naturally designed it to meet the requirements as they were formulated at the time. Since then, they have changed both in what they are and in terms of how explicitly and specifically we have laid them out, so that I now work towards a different set of requirements. This is fine and natural and how things are. The problem occurs when someone says something like We’re going to have to display X. Our system tracks that, right? or I assume that the system can do Y. Quite frequently, I do not in fact track X, and I have not designed the system to do Y. I don’t feel guilty about that, since those were not part of the original requirements as presented to me. However, when you present it in the form of an assumption rather than a question (Do we track X? Can we do Y?), I can’t answer No, but I’ll make it so, Captain; instead I am put on the defensive—No, your assumption is flawed; the system can’t do that because it was never specified in such a way.

This may sound a little over-sensitive, but I think it’s a fairly natural way to feel. Suppose that you and I are flatmates and handle the dishes communally; suppose that on a given day, it’s unclear whose job it is. If I ask you Have you done the dishes? you can answer No; I can then ask Could you do them today, please?, and there needn’t be a problem. If, on the other hand, I come up and say I assume you’ve done the dishes, odds are that you’ll be a bit put off by the notion that I’ve made this assumption without your consent.

Additionally, I’m a bit extra sensitive because the backend system of this project is my baby—no one has worked on it but me, and while it’s rife with flaws that I see in retrospect, and doesn’t match the changed requirements, I’m still fairly proud of it: I think it’s fundamentally a good system. Present an idea as a request for something new and I can happily say I’ve already done that! or Sure, I can make it happen. Present it as an assumption and non-compliance looks like a flaw in what I have created, a criticism of my work, and I’m easily offended by that.

Of course, there is one fundamental problem in expecting communication to work the way I wish—viz, the reason why these things are framed as assumptions is presumably not out of a desire to communicate offensively, but because these things are assumed, which is a problem of knowledge diffusion (inescapable in some cases, as my boss is not an engineer and wouldn’t understand the technical details, nor has any need to). Ultimately, I suppose, the take-home lesson from this would be something like the following: Be conservative in making assumptions, and err on the side of posing questions.

I do not think that the utility of this is limited to communicating with me.