Wednesday, May 6, 2009
On Releasing
Inspired by a veritable outpouring of interest (by which I mean a coworker mentioned to me that he had read at least one of my posts on the topic), today is the continuation of an occasional series on project management. It is my profound hope that by posting my thoughts here, I would be less likely to pontificate in person, when someone asks me an innocent question such as "So, project management..."
Today, I want to start with the short version of an exchange I once had with Richard Stallman (RMS), whom I idolize. I was tasked with making a piece of software, and RMS, who was looking over my shoulder, asked what I was making. I responded, "it's a content management system."
Stop me if I've told this story before.
RMS responded, "That's like saying you're doing something with stuff. What is it really?" A short chain of questions and answers followed, after which we decided I was writing a piece of software to publish news articles on the Internet. We called it an "Article Publisher." RMS talked a little more after that about how important it is to use the right words to describe software.
In that vein, the word "project" is one we should be careful with. Typically, outside of software, a project is something one does, and then one is done with. In software, however, that is called a "release." I like the word release a lot. It signifies the point at which a piece of software is let go. The word project is ambiguous: sometimes used to talk about a release, sometimes to talk about a product, sometimes to talk about something-someone-is-working-on.
On that topic, I want to offer clarification to one thing I mentioned to the coworker in question. I told him I was unsure how much common ground there is between building a tank and releasing software. In particular, I mentioned that too often people think of a release as incorporating both a scope and a deadline (when in fact it can be only one or the other).
The clarification is this: when building a tank, it's done when you've got a tank. Even if one really wants the tank very soon (which I presume is often the case), it's done when the tank is done, deadline be damned. Software, however, may be quite useful long before the full scope is completed. In fact, once a minimal set of functionality is achieved, release becomes more a matter of negotiation than of reality.
The mistake made when planning a software release is to presume this means we can have a fixed scope and a fixed deadline and necessarily stick to both of them. That's just silly, and over the long term the only thing it achieves is to get programmers to excessively pad estimates.
We get either one or the other: fixed scope or fixed deadline, and recognizing that at the outset makes the release run a lot more smoothly. There is, of course, software which has neither fixed deadlines nor fixed scope, and that software is either the best, or the worst, but certainly a topic for another day.
Today, I want to start with the short version of an exchange I once had with Richard Stallman (RMS), whom I idolize. I was tasked with making a piece of software, and RMS, who was looking over my shoulder, asked what I was making. I responded, "it's a content management system."
Stop me if I've told this story before.
RMS responded, "That's like saying you're doing something with stuff. What is it really?" A short chain of questions and answers followed, after which we decided I was writing a piece of software to publish news articles on the Internet. We called it an "Article Publisher." RMS talked a little more after that about how important it is to use the right words to describe software.
In that vein, the word "project" is one we should be careful with. Typically, outside of software, a project is something one does, and then one is done with. In software, however, that is called a "release." I like the word release a lot. It signifies the point at which a piece of software is let go. The word project is ambiguous: sometimes used to talk about a release, sometimes to talk about a product, sometimes to talk about something-someone-is-working-on.
On that topic, I want to offer clarification to one thing I mentioned to the coworker in question. I told him I was unsure how much common ground there is between building a tank and releasing software. In particular, I mentioned that too often people think of a release as incorporating both a scope and a deadline (when in fact it can be only one or the other).
The clarification is this: when building a tank, it's done when you've got a tank. Even if one really wants the tank very soon (which I presume is often the case), it's done when the tank is done, deadline be damned. Software, however, may be quite useful long before the full scope is completed. In fact, once a minimal set of functionality is achieved, release becomes more a matter of negotiation than of reality.
The mistake made when planning a software release is to presume this means we can have a fixed scope and a fixed deadline and necessarily stick to both of them. That's just silly, and over the long term the only thing it achieves is to get programmers to excessively pad estimates.
We get either one or the other: fixed scope or fixed deadline, and recognizing that at the outset makes the release run a lot more smoothly. There is, of course, software which has neither fixed deadlines nor fixed scope, and that software is either the best, or the worst, but certainly a topic for another day.
Labels: project management, scheduling
// posted by David @ 4:02 PM 
Subscribe to Posts [Atom]