David's Blague

Okay, so Ed posted a note about a conversation we were having, that ranged around on a few different topics. All of the topics were interesting, but at the time, the most interesting to me was my discovery of a lost work of Robert Louis Stevenson. In all my searches of all the historic databases in The Library, and The Google, I couldn't find any other references to his story titled "For the Love of a Woman."

Worst of all, I got to the end of chapter five, and I couldn't find any more chapters. A more thorough search of The Evening World, which published the first five chapters, seems to indicate this is not entirely atypical (e.g. publishing the first five or so sections, promising a "to be continued," then failing to continue). Here are the chapters I found:

• Chapter 1
  
• Chapter 2
  
• Chapter 3
  
• Chapter 4
  
• Chapter 5

Robert Louis Stevenson knows how to tell a good story, so as you can imagine, I was hooked. Wondering what became of the story, I searched high and low for the title, finding nothing. I searched for the name of the main character. Still nothing.

Eventually, I found it.

I am, alas, not destined for fame for accidentally discovering the lost work of a great genius. Hell, I was just looking for knitting patterns for my wife, anyway. Note the knitting pattern on the same page as chapter five: "The Fashionable Fad for Knitting and Crochet Work."

Yeah, but back to the story. Basically, from what I can tell, this was eventually published, in a polished form, as "The Pavilion on the Links" in The New Arabian Nights. There are, however, at least two mysteries that remain. Why was a draft of that story published more than twenty years after it first appeared? Why were there only five chapters?

There is a Wikipedia page about the story (isn't there always?), which tells me that I might find the original in some Cornhill Magazine, and I bet I know where I can find that. It's been called, apparently, the "first English short story."

In the meantime, if any of you are as impatient as me, there is a gorgeous digitized version published in 1913 available here: http://www.archive.org/stream/paviliononlinksi00stevuoft. Read it there, or get it from your own library. Or buy it on Amazon, for that matter.

I know this has been a departure from my usual posts, hopefully everyone stayed with me. And just in case anyone was wondering if the series on Project Managers is really done, it's not. I just wanted to post about this in-between, along with a couple other things. I'll get back to that eventually, really I will.

Unless I don't.

[edit: since this is kind of a book review, I feel compelled to offer a rating: I give it a solid twenty-three]

Project managers have a single superpower: to cause an incomplete project to be complete, without accomplishing any tasks. This is done by convincing stakeholders they are satisfied with the work that has already been done, and declaring it ready for launch.

But let me back up. Project managers only ever get asked two questions: "Is it done yet?" and as a follow up, "When will it be done?" The entire profession sprung into existence because this question was asked so frequently and ardently it merited a person dedicated only to repeatedly explaining that no, it is not done yet, and here's why.

So on one side, project managers have an irresistible force: curious stakeholders. On the other side, they have an immovable object: programmers. When we do our job well, we keep both sets of people happy, with some help from both sides.

Communication. Let's say a programmer hasn't finished a task, because she got drunk at 10AM on a Tuesday, and passed out on her couch. Huge problem. Unless... let's say that programmer told her project manager the week before that she was planning to get drunk and pass out on her couch on Tuesday, and that the task scheduled for that time was likely to go uncompleted until it could be rescheduled the following Tuesday.

No problem! The project manager will then send an email that says something like, "Due to an unavoidable conflict with another project, a critical task will be delayed for a week, causing one week slippage to the final schedule." And nobody will care, because they are finding out ahead of time, and can, in turn, do whatever it is they do with this kind of information when they receive it.

Which brings up a second: planning.

Project managers function best when everyone else does just a little bit of planning. We don't expect people to plan things like car wrecks or deaths-in-the-family, but we do expect people to plan things like Christmas or hiking the Appalachian Trail. Some discretion is involved, obviously.

With that, I now intend to arbitrarily and capriciously demonstrate the superpower that I explained earlier. This is my last post about project management, because the series is finished. Four posts were planned, and four posts were made. Great fun was had by all. The project was a success.

Yay!

Labels: programming, project management, scheduling, software

A second, and dramatically less useful abstraction The Meeting. Ah, meetings. Meetings are easier to define than tasks, and on some project teams, more frequent. As with tasks, I offer a definition:

meeting (n): a scheduled event, in which attendees follow an agenda

Meetings kind of suck. I think this definition gets that point across. However, there are both social and technical reasons for them. The social reason is that many programmers dislike having to tell a group of people they haven't completed a scheduled task, which is a stupid, sucky reason to have a meeting, but there it is. The technical reason is that meetings are high-bandwidth and low latency, which is sometimes needed.

A few words on how project managers can make meetings suck less... send out an agenda ahead of time. Put items on the agenda, with approximate times next to them, and people's names. If a person's name is on the agenda, attendance in mandatory. Otherwise, it's not. Start meetings on time, and end them early. Socialize afterward. Make announcements via email: announcements do not require low latency or high bandwidth. If there's nothing requiring low latency, and nobody needs to be shamed into completing a task, cancel the meeting. I don't do that nearly often enough.

And a few words to the programmers... don't be a jerk, not even if you really hate being in the meeting. Either come and act like a competent grown up, or show some intestinal fortitude and blow it off. If a programmer's name is on the agenda next to an unresolved item of business, one way to miss the meeting without making the project manager go insane is to resolve the item prior to the meeting, and let everyone know.

And a few words to the stakeholders who will inevitably also be in the meeting... if you want to ask a question or discuss a topic in the meeting, email the project manager and ask to have it on the agenda. The project manager can probably make sure there will be a good answer waiting in the meeting, and may be able to pose it in a way that doesn't piss off the programmers.

Lastly, ten words from Despair, Inc. about meetings that should always be in the back of everyone's mind when deciding whether to have one: none of us is as dumb as all of us.

Labels: programming, project management, scheduling, software

(editorial note: despite my previous post complaining about the term Project Manager, I'm still going to use it. For what it's worth, it makes me feel slightly dirty)

Tasks are one of the most useful abstractions in the project manager's toolkit. Unfortunately, they are also one of the most poorly understood. With the hope of easing some of this confusion, I propose the following definition:

task (n): scheduled work, assigned to a person, for a purpose

In my initial writing of this post, I expounded quite a lot, and realized all my explanations were detracting from, rather than adding to the clarity of that definition. I think I'll save muddying of the waters for subsequent installments.

Labels: programming, project management, scheduling, software

The title "Project Manager" brings to mind an interaction with rms several years back. I was working on a "Content Management System" for a mutual acquaintance, and he asked me (seeming innocent):

"What are you working on?"

"A Content Management System." Simple enough.

"What do you mean?"

"Well, it's a system that manages content." I hadn't known Richard long at the time.

"That's like saying you're 'doing something with stuff.' It doesn't make any sense." Richard had a very good point, but I was still stuck. "What kind of content?"

"Mostly news articles, I guess."

"What are you doing with them?" he continued.

"Uhhh... publishing them to a website?"

"So you're writing a piece of software to publish articles? Why don't you call it an 'article publishing tool'?"

Using the title Project Manager is like saying I'm somebody who does stuff with things. I've spent a while trying to come up with a better alternative, and last night while I was putting the kids to bed, it was stuck in my brain for some reason.

What I do, is schedule. It doesn't sound glamorous, and much of it isn't. I write meeting agendas and send email and set up conference calls. I am tasked with guessing when it's going to be done, for some arbitrary values of "it" and "done". Most of all, I try to figure out the sometimes complex interdependencies between tasks and personalities.

What I schedule, is software. I don't know if scheduling a tank or a road or a rocket launch is really the same. Project Management Professionals [sic] treat them as similar problems, but I don't ever run out of steel or tar or hydrogen fuel, and so far I have never run out of bits, either.

I am a Software Scheduler. Since that job title still sounds like I'm someone who predicts the future and bends the space-time continuum, I hope to make this into an occasional series about how software gets scheduled.

Labels: programming, project management, scheduling, software

I admit that about half the books I read, I read for the wrong reasons. For instance, I read Cellular Automata and Complexity because I wanted to be able to say something like "Oh, A New Kind of Science was really just a rehash of his previous work." It wasn't, of course, but I knew there would be something like that that I could say after I'd read it.

I think people thought I was joking in the previous book review when I admitted to being full of it, but that is often the (wrong) sort of reason I have for reading a particular book.

Well, this one was delightful. And if Stephen Wolfram ever comes into my office, I'm going to jump out of my chair and say hello, and ask him what his name is, and what he does for a living, pretending the whole time that I'm not peeing my pants with sheer anticipation. Then I'm going to pretend not to have read anything he's written on the topic, and try to ask one good question that makes him say to himself, "Wow, this guy is really thoughtful and intelligent, despite knowing nothing about the topic."

If you read one thing by Stephen Wolfram, get this book and start reading at page 411. It's a brilliant introduction to the field that shows Wolfram at his best. Then skip around and read a few others. Great reading for cocktail parties. On top of it all, some of Wolfram's ideas were actually easier to understand when they were a bit less developed. As counterintuitive as that is, ANKOS took for granted a very developed worldview that probably wasn't shared by most readers.

As is my practice, each book gets a rating. This one gets seven stars, for each of the seven papers I read through. I can't really comment on the remaining fifteen or so, but if I were to hazard a guess, most of them are probably okay, too. And Stephen, if you're reading this, just play along when you come to my office- it'll be fun!

According to folklore, Donald Knuth once expressed doubt that Steve Jobs had read his books. I think the term of art he used was "full of shit." Well, I'm no Steve Jobs, but I am full of shit, though I don't really believe that story. Besides, the book I'm about to review isn't really a reading book, so when I claim to have "read" it, I'm really just claiming to have it. It's a fascicle, whatever the heck that means.

Without further ado, I present: The Art of Computer Programming, Volume 1, Fascicle 1: MMIX -- A RISC Computer for the New Millennium- a tome as hilarious and subversive as it is comprehensive and groundbreaking. And that kind of an introduction is further proof that I am living up to my aspirations from the previous paragraph. I really liked this little pamphlet, and here one byte of reasons you should read it, too:

• You'll be able to read Volume IV when it comes out.
  
• In its current form, it's short.
• It is funny and poetic.
• You will Sympathize With Your Machine (SWYM).
  
• It is, after all, 2009.
• It will be a good excuse for not reading past Chapter 1 in The Original Series.
• You will have read something by Knuth.
• You, too, can be full of shit, like me and Steve.

It has been my practice, when making book reviews, to give books a rating. I give Donald Knuth 2009 gold stars for this excellent little manual, and encourage everyone to give it a read this year.

With that, I have completed Step 18 of Knuth's "Procedure for Reading This Set of Books."