This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Jobs Discussion and the fly likes Say no Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Say no" Watch "Say no" New topic
Author

Say no

Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38064
    
  22
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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15961
    
  19

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.
Chad Fowler
Author
Ranch Hand

Joined: May 19, 2009
Posts: 38
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
http://www.pragprog.com/titles/cfcar2/the-passionate-programmer
http://chadfowler.com
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38064
    
  22
Thank you; that should be helpful for everybody reading here
 
 
subject: Say no
 
Similar Threads
Drugs legalisation: 'when, not if'
Alternative application letter
Sun or Prometric?
H1-B activism or hope things get better?
Cost of Migration to Australia