It’s that time of year again. My favorites:

• Physics: “Kiyoshi Mabuchi, Kensei Tanaka, Daichi Uchijima and Rina Sakai, for measuring the amount of friction between a shoe and a banana skin, and between a banana skin and the floor, when a person steps on a banana skin that’s on the floor.” If I were a high school physics teacher, I’d see if my students could reproduce this.
• Psychology: “Peter K. Jonason, Amy Jones, and Minna Lyons, for amassing evidence that people who habitually stay up late are, on average, more self-admiring, more manipulative, and more psychopathic than people who habitually arise early in the morning.” Morning people rule!
• Public health: “Jaroslav Flegr, Jan Havlíček and Jitka Hanušova-Lindova, and to David Hanauer, Naren Ramakrishnan, Lisa Seyfried, for investigating whether it is mentally hazardous for a human being to own a cat.” I can’t think of something to say that might not get me in trouble.
• Arctic science: “Eigil Reimers and Sindre Eftestøl, for testing how reindeer react to seeing humans who are disguised as polar bears.” If this is one of the things you’ve wondered about, now you can find out the answer.

And Happy “Talk Like a Pirate Day” to all.

The Most Dangerous Word in Software Development

Seems about right.

The Register: Fat-fingered admin downs entire Joyent data center

As for the fat-fingered administrator? “The operator that made the error is mortified, there is nothing we could do or say for that operator that is going to make it any worse, frankly,” Cantrill said.

Nor would Joyent want to, he explained. The goal for the company is to learn from the problem and get better, not mete out punishment. “You don’t teach dolphins with a shock collar,” Cantrill explained.

This used to be the attitude throughout the University, and still seems to apply here in ITS-Systems. From what I’ve heard, though, there are places where “meting out punishment” seems to be the rule now.

Another anniversary: 10 PRINT "Happy 50th Birthday, BASIC" : GOTO 10

Today is the 50th anniversary of the announcement of the IBM System/360. Some coverage here and here.

Interesting: Context Reports

This morning I realized I might have a productive way to twist status reports into a useful exercise. Let’s call them context reports. A status report documents actions both completed and planned. A context report documents the reason why (and to a lesser extent how) you’re completing these actions and I suspect this information is far more useful to everyone involved. Let’s try it out by transforming common status report items into context report bullets.

I found this from a link from the Typical Programmer: People and methodologies in software development. The abstract:

This thesis reports on research performed over a ten-year period, interviewing project teams, participating directly on projects, and reviewing proposals and case studies. The research addressed three questions relating to people and software development methodologies (Q1 through Q3), and produced six results (R1 through R6).

1. Do we need yet another software development methodology, or can we expect a convergence and reduction at some point in time?
2. If convergence, what must be the characteristics of the converged methodology? If no convergence, how can project teams deal with the growing number of methodologies?
3. How does the methodology relate to the people on the project?

The answers are:

1. A methodology is a formula describing conventions of interaction between roles.
2. People’s characteristics, which vary from person to person and even from moment to moment, form a first-order driver of the team’s behavior and results. Such issues as how well they get along with each other and the fit (or misfit) of their personal characteristics with their job roles create significant, project-specific constraints on the methodology. This result indicates that people’s personal characteristics place a limit on the effect of methodologies in general.
3. Every project needs a slightly different methodology, based on those people characteristics, the project’s specific priorities, and the technologies being used. This result indicates that a team’s methodology should be personalized to the team during the project and may even change during the project.
4. A set of principles were found that can be used to shape an effective methodology to the above constraints. These principles deal with the amount of coordination and verification required in the project, the trade-off between rework and serialization of work, and the trade-off between tacit and externalized knowledge in use by the team.
5. A technique was found to create a situationally specific methodology during the project and in time to serve the project, and to evolve it as the project progresses.
6. All the above suggests a repeating cycle of behavior to use on projects.
   1. The members establish conventions for their interactions — a base methodology — at the start of the project. This can be likened to them “programming” themselves.
   2. They then perform their jobs in the normal scurry of project life, often getting too caught up to reflect on how they are doing.
   3. They schedule regular periods of reflection in which they reconsider and adjust their working conventions.

These results have been used successfully on several industrial projects having the usual time and cost pressures on the staff.

I think this is exactly right. I’ve had an idea for a post about humans in software development floating in my head for a while; maybe I’ll get to it soon.

An editorial in Monday’s Daily Texan ended:

… UT should hire UT staff and Texas programmers to custom build its administrative systems.

I’m not sure why the author would suggest that. After all, that’s what the University’s been doing for almost five decades, and look at all the pain and suffering that’s caused.

There are other reasons you can tell this wouldn’t work:

• You never see articles in magazines for CIOs and CFOs that talk about custom building, so it must be a bad idea.
• It would require business managers at the University to have a passing acquaintance with information technology and technology trends. They might even need to develop a vision about how technology could help the University work better.
• Have you ever tried managing programmers? It’s the proverbial herding cats experience. It’s much easier to pay other people to deal with that.
• If something goes wrong, you can’t blame it on anyone else.

We definitely need to nip this idea in the bud.

If your web application requires that my browser support Flash or Java, it’s broken, and you should fix it.

If printing copies of your slides and handing them out helps your audience, you did your slides wrong.

Just sayin’.