Why can we not allow for a process that creates detailed requirements and design information for each feature so that we can create more meaningful estimates?

Why can we not allow for a process that creates detailed requirements and design information for each feature so that we can create more meaningful estimates? Isn’t that the professional way to approach the problem? If the schedule provides time for more detailed estimating at this time, by all means do it! However, we believe that it is crucial to be able to make some quick decisions about the scope of the activity without a more detailed estimate. Why? Because to do otherwise invests resources in what will later be determined to be “wasted inventory,”

Advertisements

The “Yes, But” Syndrome

One of the most frustrating, pervasive, and seemingly downright sinister problems in all of application development is the “Yes, But” syndrome, being the observation of the users’ reaction to every piece of software I have ever developed.

For whatever reason, I always observe two immediate, distinct, and separate reactions when the users see the system implementation for the first time:

• “Wow, this is so cool; we can really use this, what a neat job,
atta boy,” and so on.
• “Yes, but, hmmmmm, now that I see it, what about this … ?
Wouldn’t it be nice if … ? Whatever happened to … ?”

The roots of the “Yes, But” syndrome appear to lie deep in the nature of software as an intangible intellectual process.