Christopher Duncan >> Well, the first suggestion I’d make is to avoid the tuna sandwiches in the cafeteria... To put it as simply as possible, the stress comes from one group of people being responsible for fulfilling the unrealistic promises and expectations of another group. The solution to this dilemma is for programmers to take human nature, company politics and matters of strategy as seriously as the do coding. When this happens, they learn to communicate more effectively with the people who make the decisions, giving them the opportunity to set the stage for a more realistic development cycle and ultimately, a successful release.

"Stress comes from one group of people being responsible
for fulfilling the unrealistic promises and expectations of another group..."

IndicThreads >> Most project teams would say that deadlines on their projects are unrealistic. Where do you think does the problem lie? Are estimation techniques in software development seriously flawed or is this more of a human problem?

Christopher Duncan >> You’ve really touched on the heart of the matter when you point out the human factor. As I mentioned earlier, it’s almost impossible to predict with 100% accuracy how long a non trivial software project will take because of the complexities and unknowns involved. However, neither marketing nor management cares about this because, like most people, their first concern is their personal career. Marketing wants to make sales, and they’re used to making whatever promises it takes to do this. Management is used to selling tuna, and they don’t want to be the one to tell their superiors that the cans the marketing folks are selling are really only half full because they’ll look bad when it comes time for a promotion.

"Think in terms of what’s in it for the manager to do it your way..."

Chihuahua from The Career Programmer

What’s the solution to this? As I covered in my latest book, Unite the Tribes, you have to learn to effectively promote your own agenda if you’re going to succeed in your career. For developers, this means that you have to be able to speak the other person’s language in order to persuade them to follow your scheduling recommendations. Simply put, you have to think in terms of what’s in it for the manager to do it your way. You then have to draw a straight line of logic from your proposed software, scheduling and management ideas to his personal benefit, giving him in the process the ammunition he’ll need to sell his decision to his superiors.

Does this sound like a lot of office politics that you don’t really want to be bothered with? No problem. Hope you have a sleeping bag by your desk. The person who can sell their agenda is the one who gets their way. That’s why programmers consistently lose on deadlines and a host of other issues, because they’re unwilling to learn any skill beyond the technical.

"Programmers consistently lose on deadlines and a host of other issues, because they’re unwilling to learn any skill beyond the technical..."

IndicThreads >> Another common issue is that of requirements creep. Most software teams complain that the client just doesn't know what he wants.

Christopher Duncan >> Of course the client doesn’t know what he wants! Why do you think he needs you in the first place? This is yet another area where the typical programmer thinks that the world should come to him on a silver platter so that he can just sit back and play with the computer. The client doesn’t understand the first thing about the design of a computer program. He doesn’t think in terms of structured or object oriented logic. He’s unaware of the consequences of any decision he makes, and neither does he realize that he has to spell out every little detail or the ambiguities can lead the project into months of dead ends and restarts. It’s not his job to know this. He runs a tuna distribution center. If you want to know about how manage warehouse workers, route a fleet of trucks to distribution points nationwide, or get that fishy smell out of your clothes at the end of the day, he’s your guy. He has no idea how to turn all of that into a software system, and if you sit back and expect him to do it for you, you deserve what you get.

"Requirements gathering is "What" and not "How"...

Developers have to first master the art of requirements gathering themselves, which is the definition of “what” (not “how”). When they understand how to create a clear and completely unambiguous document that leaves nothing unsaid, that’s the first step on the road to a better client relationship. However, it doesn’t end there. They must then learn how to interact with the client, ask the right questions, draw the information out, and together with the customer paint a clear and precise picture of the software system. Then, and only then, the client can look at it and say, “Yes, this is exactly what I need, except for this one thing over here, which should be exactly this instead of exactly that.”

"You have to work with your client and help him clarify his thinking so that you can do the best possible job for him...

In short, you have to work with your client and help him clarify his thinking so that you can do the best possible job for him. When you do, you’ll not only avoid scope creep, you’ll have a happy client. And that’s something we all seem to forget about these days. The customer is truly what’s all important. Without them, and their money, you have no paycheck.