This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
I see there is a section called "say no" in the Passionate Programmer book. Is that about the risk of burnout because of taking on too much work, or about the risk of taking on work beyond one's capabilities and experience?
I haven't read the book, myself, but I can think of a couple of good reasons to "say no". Most of them having to to with that fatal phrase "All you have to do...".
1. Overcommitting. Both users and developers are perenially optimistic and grossly underestimate both all that really has to be done and the odd snags that can come up along the way. The snags, in fact, often get cancelled when the "hard" part of the project turns out to be less trouble than anticipated (in my experience). But forgetting how totally dim computers are and how much effort it takes to get them to do things that any person could do easily is a great way to end up committing to more work than the time or budget allow.
2. Buckling to pressure. A variant on theme #1. The user has a fixed concept of time and expense and it becomes a Procrustean bed. Even when the developer isn't him/herself overly optimistic, the user pressures the developer(s) into committing to unrealistic deliverables. However, the user doesn't want a truncated result, just truncated time/expense. This is pretty much guaranteed failure for everyone.
3. Feature creep. Even when when the "little additions" actually do turn out to be simple and easy, they add up. Feature Creep amounts to stealth overcommitment. One of the advantages of the Agile approach is that you can subvert a lot of this: instead of saying "no", say "Milestone X". It won't actually make anything go faster, but at least the effects are more tangible and there's less room for recrimination.
4. Feature shuffling. This can be a downside to Agile. If a milestone is actually going ahead of schedule, there can be a temptation to slide later features into the current milestone. But again, every feature has its price, and succumbing to this temptation can end up delaying deliverability of the current milestone, thereby turning all those attaboys for being ahead of schedule into a .
5. Must Haves. Some things are key to the project, but often someone with the ability to exert pressure gets a pet feature with minor utility but major impact. Unfortunately, by definition, that's the kind of thing you can't "say no" to except by walking out the door. That's a difficult thing to do these days, but sometimes the personal costs involved in leaving outweigh the benefits of sticking with the job.
Customer surveys are for companies who didn't pay proper attention to begin with.
Tim sums it up pretty well (more thoroughly than I would in fact)
An important part of learning to say "no" is that it ultimately gives you credibility when you say "yes". I think of one of my roles on software projects as that of an adventure tour guide, leading those who don't necessarily know the dangers of the terrain safely to their destinations. Imagine booking a tour through the forests of Uganda with a guide who agreed to every idea you had and never pushed back. It would actually be unsettling and negative because you would be putting your safety in the hands of a person who is supposed to know better than you but isn't showing you where the boundaries are.
Saying "no" helps our customers learn the boundaries of software development (or any IT/technical domain).
The Passionate Programmer: Creating a Remarkable Career in Software Development
Joined: Oct 13, 2005
Thank you; that should be helpful for everybody reading here