I had an interesting conversation over a French-language programming newsgroup the other day. This person was inquiring about "Edit and Continue", tool support which would let him do simple, one-line changes to his C/C++ system from within a debugger session, and have the new code execute without needing to exit the program, recompile, rebuild,...

Johanna argues that "Users can't know their requirements early", and illustrates with a simple but illuminating story. The term "requirements" seems to be part of our final vocabulary - we assume there's such a thing as "what the system should do" (irrespective of whether the customers know or don't know what the system should do). We don't really...

Johanna argues that "Users can't know their requirements early", and illustrates with a simple but illuminating story. The term "requirements" seems to be part of our final vocabulary - we assume there's such a thing as "what the system should do" (irrespective of whether the customers know or don't know what the system should do). We don't really...

The previous entry on models of change reminded me of something. We devise models for what we want to explain. We want to explain what is not obvious. If we have models of change, it must be that change isn't obvious. Yet change is just the flip side of stability - things change when they don't remain the same. (Mr de la Palisse would be proud.)...

The previous entry on models of change reminded me of something. We devise models for what we want to explain. We want to explain what is not obvious. If we have models of change, it must be that change isn't obvious. Yet change is just the flip side of stability - things change when they don't remain the same. (Mr de la Palisse would be proud.)...

Here is a short list of models of how people, organizations, industries and societies change: Weinberg's "naive" models: The diffusion model The hole-in-the-floor model The Newtonian model The learning curve model Virginia Satir's change model Geoffrey Moore's "Crossing the chasm" technology adoption model Kuhn's model of paradigm shifts (as...

I've always liked Frank Patrick's take on project management: Frank asks, "If project management is the answer, what is it an answer to ? What is the question ?" And the question is - "What should I be working on ?" Frank's concern with finding the appropriate question - not just the answer - stems, I think, from a frustration with discussions of...

I've always liked Frank Patrick's take on project management: Frank asks, "If project management is the answer, what is it an answer to ? What is the question ?" And the question is - "What should I be working on ?" Frank's concern with finding the appropriate question - not just the answer - stems, I think, from a frustration with discussions of...

As I noted in "Blog to print", I have an article out in the December issue of Cutter IT Journal which grew out of a previous entry here. I'm in good company - the issue, edited by Lynne Nix, has articles by Eileen Strider, Mark Keil, Payson Hall and Capers Jones.

As I noted in "Blog to print", I have an article out in the December issue of Cutter IT Journal which grew out of a previous entry here. I'm in good company - the issue, edited by Lynne Nix, has articles by Eileen Strider, Mark Keil, Payson Hall and Capers Jones.

Think of the process you undergo when you write e-mail for instance. You write something, which you intend to express your thought. The act of writing brings the realization "No, this is not quite what I wanted to say". So you revise and alter. But after a number of drafts the pressure mounts : "OK, enough dithering, this is what I wanted to say"...

Joseph Pelrine (Smalltalker, XP veteran, and ScrumMaster) has just entered the blogosphere. Welcome, Joseph !

Joseph Pelrine (Smalltalker, XP veteran, and ScrumMaster) has just entered the blogosphere. Welcome, Joseph !

Regarding the matter of a project's "requirements", many people will tell you that your customers don't know what they want. Just as many will tell you that customers do know what they want. Neither branch of this dichotomy is useful. I'm always put off by the suggestion that "customers don't know what they want", or that they "know what they want...

Regarding the matter of a project's "requirements", many people will tell you that your customers don't know what they want. Just as many will tell you that customers do know what they want. Neither branch of this dichotomy is useful. I'm always put off by the suggestion that "customers don't know what they want", or that they "know what they want...