Time pressure when programming - what do you do?

Here is the story. We've got this project with a completely artificial deadline - manager just arbitrarily set it up 'cause he probably thinks that will make people work more efficiently. He is a big fan of pressure - he creates it even when projects don't have it naturally. There is another person on the team that does not do any programming, does not really understand it, but runs around reminding everybody how we don't have much time.

Well, what I was doing during this situation is constantly repeating to these people that the whole thing needs to be thought out carefully first. I succeeded at that, so the BS "hurry up, we don't have time to sit around and design things" thing did not pop up during the design stage, and we actually managed to develop some design.

Now we are coding things, and again soon we have a presentation to this manager who wants to see the working prototype.

I was trying to get something going, and encountered a number of issues due to my inexperience with this certain development platform, so I was spending a lot of time trying to resolve these. Regardless, I still had that theme in my mind that "no time, no time, no time".

I realized that all this theme does is basically locks me into whatever path I've chosen, so instead of pausing and thinking of a work around, I keep banging the wall hoping to succeed by brute force when there is a problem. And it ain't easy because there are all these issues I am unfamiliar with. So this is all horibly inefficient.

Alternatively, when I have no perceived pressure, I think creatively about what I am doing almost all the time,  and the workarounds are found naturally as they are needed. Sometimes the solutions occur during long breaks. Thus, whenever I perceive any pressure coming, I do all I can to diffuse the situation, and turn it into a no pressure one.

I realized that the time pressure in programming is one of the worst pressures that there can be. It is quite unpredictable how fast one can get things to work, yet the deadlines are there.

How do you guys deal with such pressure situations? Can you stay fully creative to bypass the problems, or does it take you down the "bang the head against the wall until succeed" path? Or do you just get into the "I don't care"  mode, and work at your natural pace while ignoring all the distractions?

Cunning politician
Tuesday, October 21, 2003

You can start by forgiving your manager for all of the other times that that he's done this, because it's really not his fault.  With that out of the way, you're sure to not enflame the situation by bringing up past history. 

Now you can concentrate on the current deadline situation and learning how to "work" your manager (they don't always come with instructions). 

The first step is to have an objective look at your position in the food chain.  Are you the lead programmer?  If so, go to Step 2.  If not, you should take your concerns the them first, they should go to step 2.

Step 2 is to determine your manager's level of knowledge in the area of the project that he is creating "estimates" for.  If youre manager is not a programmer who knows *exactly* what needs to be done to accomplished the goal within the estimated timeframe, tell your manager that since YOU are doing the work, you would like some say in the estimate. 

If he has already given you this opportunity, and you've blown it by missing the deadline or not meeting the minimum requirements, then you must try to find ways to build there confidence in you again.

Step 3.  If you've never been offered the chance to create the esitmate, go ahead and start estimating.  Make sure that you completely nail down the requirements first though.  As a matter of fact, make an estimate for getting the requirements.  Tell your manager, "I'll need <ESTIMATE> minutes of your time, to talk about some of these requirements, when you get a chance".  Allow them to say when, you say how long.

Get as much requirement info that you think you need start researching it.  Also, make sure you find out which requirements are ABSOLUTE deal makers/breakers.  Here is where your managers knowledge (or lack thereof) can help you.  At this point you can look at one of the requirements (one he definitely doesn't know about) and make a big deal about it (not TOO big). 

Say things like, "<Requirement X> might be a problem.  Can I have have a little time to look at this?".  Basically, make up ANY darn reason that you think you can pull of to get just a little bit of time.  Then, use that time to figure out which requirements you think are doable, which ones are problematic, etc.  You don't need to figure out how to do ALL the requirements, but you should break the job up into pieces and estimate the one you think needs to be done first and give THAT estimate to the manager, telling him that you need to get the first piece done to estimate other pieces, etc.  Then, work hard to meet all of your own estimates because if you miss them you lose points.

So, that's how I deal with it, by trying to prevent *anyone* (including myself) from just making up estimates.  It's hard to estimate sometimes, but that's why I just fire up the IDE and start testing theories as soon as one occurrs to me.  Knowledge is power.

I recommend reading The Career Programmer: Guerilla Tactics for an Imperfect World (cheapest price: http://www.walmart.com/catalog/product.gsp?cat=18674&dept=3920&product_id=1690897&path=0%3A3920%3A18674%3A18692%3A20257).  If you can get past some of the wierd humor, there is some pretty good advice I think.

Wayne
Tuesday, October 21, 2003

In step 2, you really don't have to tell your manager that "since YOU are doing the work, you would like some say in the estimate".  You should really not say anything that will cause any friction and stick to trying to get him to do what you want. 

Be scientific about it.

Wayne
Tuesday, October 21, 2003

Speaking as a (sometime) manager, I disagree completely with that. Actually with the first point as well. As the guy doing the work you shouldn't just have a say in the estimate - you should set the estimate. The only person who can estimate the amount of work required to complete a piece of code is the person who's going to do it.
A manager who is also an experienced engineer (as I like to think I am ;-) can advise a less experienced engineer on the estimation process, but can't just make the esimate for them

SteveM
Wednesday, October 22, 2003

Consider this, is there ever a time when you should do something slowly when there is no pressure of a deadline?

Well perhaps just to fill the time up.

Deadlines don't change the task, nor even the nature of accomplishing it but they define when it succeeds in some way other than the task itself.  Deadlines can be impossible, the people giving the deadlines probably know when they are and probably give them because they haven't found an alternative to saying yes to someone that doesn't understand what is and isn't possible but has needs and goals over and above what the actual task is itself.

All of those things are irrelevant to the people that need to do the work.  Yes they will bitch and moan about them, this is normal, as a manager you can even agree with them.

It all depends on the nature of the group which works, sometimes the 'design everything so we don't forget and then the coding will be simple' really does work, but I've found that to be rare.

Generally, I've found it better to get the bedrock of the design agreed and what is and is not a priority for whatever deadline is given.  Then its handing out the tasks and managing the flow, letting people follow their nose and encouraging everyone, including myself,  to QA everything. 

But I would do exactly the same regardless of whether the deadline was fair, achievable or just plain stupid.  As the manager its my problem to explain to the company why the feature list is going to diminish or the level of completeness is going to be reduced.  It isn't the developer's problem and I'm not going to use the deadline as a stick or convert it into a carrot by paying overtime.  Neither of those are necessary.

Simon Lucy
Wednesday, October 22, 2003

However long it takes is how long it takes, BUT you do have control in each feature you're putting in whether you do the one day hardcoded hack solution, the one week semi-hacked solution or the or the one month elegant and robust solution. Using your own estimates, line up your tasks with the time they want you to do it in by picking which you can do elegantly and which you'll have to hack. If everything has to be hacked, or it's just way out of sync with the deadline, ask your boss if he really wants you to hack everything together, or would he prefer you take the middle ground with the design and leave out some features until the "next release" (and suggest some you think can be omitted or simplified).

Ed
Wednesday, October 22, 2003

Deadlines are part of the fun of the job. I imagine most of us program to make money and turn a profit. The current economy unfortunately does not give us much credibility in our plea for "creativity" time. In the mean time, help your manager slice and dice the features to see where the priorities are. You are all (supposedly) working towards the same task of profitability.

m
Wednesday, October 22, 2003

Sounds like I worked for a similar character once.

In addition to putting imaginarly pressure on with the idea that people worked better under pressure, he went out of his way to promise things to customers that couldn't possible be done in the timeframe. Then, he would play an estimating game with the programmers. He would ask each one how long a given task would take and then either give the job to the low bidder, or use the low bid to shame someone else to commiting to doing it as fast or faster.

I tried everything that I could to work in the situation, but failed. It was incredibly stressful to me. Some of my co-workers just adopted a slow and steady attitude. Basically they ignored him and just worked their 8.5 to 9 hour days, did what they could and went home.

I ended up looking for a new job and transferring within the company until he was run out of town for pissing off the customers with unfufilled promises.

Good luck.

pdq
Wednesday, October 22, 2003

What if you could provide a working prototype or mock-up early?

What if you were providing incremental improvements and upgrades to the in-house development effort over time?

What if the manager were constantly seeing material progress, rather than having to wait until now to see even a prototype?

The Pedant, Brent P. Newhall
Wednesday, October 22, 2003

And in the time it takes to produce a prototype you can produce something that's real.  Never prototype.

Play around, experiment but never create something that looks sparkly and new but doesn't do anything, those that don't understand will believe its all but done.

Just don't do it.

Simon Lucy
Wednesday, October 22, 2003

On the topic of prototyping, here's an idea that we've used for the past ten years with great success.  (Our clients tell us the #1 thing that attracts them to our products is the ease of use.)

Use Paint to create a "prototype." If you don't have an existing product to provide "seed" control images, slap one of each type of control on a form in Visual Studio, do a screen grab, and start copying and pasting in Paint.

"Prototype" = on paper.  NEVER on the computer.  (Unless, of course, you happen to open the BMP on-screen.  <g>) You want to make sure there is NEVER any impression that the prototype actuall DOES anything. That's the key point.

Dave

Dave
Wednesday, October 22, 2003

Thanks to everybody for sharing opinions!

In this case, I could not focus 100% on this particular project and have more important things to do. The added pressure was more than I was willing to deal with. I had an option to  get out of this project, so I did, and it should not have any negative effect on me within the timeframe I care about.

  Also, we do have screenshots on paper how things should look like, and they went through several rounds of suggestions. Looking at the prototype meant seeing the whole program pretty much in a workable condition. This thing is mostly user interface with things attached to controls on the screen. Pretty much most of the things had to be ready by the "prototype" stage, which really was meant only as an opportunity  to criticize the UI and provide the all influencing managerial feedback.

For those that could relate to the story, some background. The project has really no deadline because it is an internal project meant to replace a working system which is really OK with the users. It ain't clear how the new system is gonna be accepted with the user community. On the other hand, the manager needs something for the end of the year review, so this is what this all is about. He does not want to push too much himself, so he has this pusher on the project that knows very little but reminds everybody about the time pressure. The rest of the guys are supposed to follow these "leaders". Since I knew about my option to drop this thing, I tried to make sure that there is some design before the programming starts, so such the BS does not affect too much people who are gonna do the actual work.

Cunning politician
Wednesday, October 22, 2003

I just go home in such situations. Fsck 'em, if they are going to be unrealistic then they don't deserve any more loyalty or effort than my contract says.

Thursday, October 23, 2003

If, by Rudyard Kipling

If you can keep your head when all about you
  Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
  But make allowance for their doubting too:
If you can wait and not be tired by waiting,
  Or, being lied about, don't deal in lies,
Or being hated don't give way to hating,
  And yet don't look too good, nor talk too wise;

If you can dream--and not make dreams your master;
  If you can think--and not make thoughts your aim,
If you can meet with Triumph and Disaster
  And treat those two impostors just the same:
If you can bear to hear the truth you've spoken
  Twisted by knaves to make a trap for fools,
Or watch the things you gave your life to, broken,
  And stoop and build'em up with worn-out tools;

If you can make one heap of all your winnings
  And risk it on one turn of pitch-and-toss,
And lose, and start again at your beginnings,
  And never breathe a word about your loss:
If you can force your heart and nerve and sinew
  To serve your turn long after they are gone,
And so hold on when there is nothing in you
  Except the Will which says to them: "Hold on!"

If you can talk with crowds and keep your virtue,
  Or walk with Kings--nor lose the common touch,
If neither foes nor loving friends can hurt you,
  If all men count with you, but none too much:
If you can fill the unforgiving minute
  With sixty seconds' worth of distance run,
Yours is the Earth and everything that's in it,
  And--which is more--you'll be a Man, my son!

http://stellar-one.com/poems/if__rudyard_kipling.htm

Ged Byrne
Thursday, October 23, 2003

I've worked many years on both the programmer and manager sides of the coin.  In fact, depending on the project I could be working on either or both these days.  When I'm in the developer's role, I find two lines of questioning useful in trying to manage the manager when the deadlines are unrealistic:

1. Can you explain the business needs around these deadlines?

If the manager can't explain a deadline based on a real business imperative, then it's a bogus deadline.

2. OK, so that's the deadline.  In order to meet it we're going to have to trade off features and/or add resources.  Which should we do?

Anyone with any real management experience understands these trade offs.  If you're lucky, you'll be talking with a manager with good technical understanding who would delegate time estimates to the people doing the hands-on work, and who'd engage in an intelligent conversation to understand why the schedule's too tight before making the trade offs. 

Jon
Thursday, October 23, 2003

  Recent Topics

  Fog Creek Home