Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When you are under pressure, the deadline is approaching, and a manager is breathing down your neck do you find yourself starting to write bad code? Do TDD and best practices slip by the wayside in order to get things done? What do you do in situations like that? What were your experiences?

share|improve this question

closed as off topic by Yannis Rizos Aug 28 '12 at 0:56

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

8 Answers

In a word, yes. Anyone that tells you otherwise is probably, at best, mistaken.

However, the key is to build on your experience to write code that is less bad. Resist the temptation to put in something to make it "just work" if at all possible, because it won't. You still need to follow some sort of process (be it your own, or your company's, or some mix thereof).

Experience tells me that its much better to (gasp) slip the schedule a couple of days to prevent a week's worth of fixes, especially when "under pressure" means an expedited release to production. If you are hurrying to release code, the testers are probably going to be in a hurry to rubberstamp it as well.

share|improve this answer
    
i would give plus 10 for the post, very well said –  maz3tt Dec 3 '10 at 5:20
    
It can be generalized. Please follow this proposal for that kind of question: Organization aspects –  bigown Dec 10 '10 at 20:51
add comment

If the team is in a crunch then something was done wrong.

Missing deadlines is a sign of poor planning and estimation. Acknowledge that the deadline will be missed and solve the issue. Sometimes you don't have control over the planning or estimation. Identify who does and ensure that they know this was done in error.

In a situation were the deadline cannot be moved you break out the highly caffeinated beverages and put a rush on it. Identify anything you can sacrifice and cut it out. Take what's left and implement it as fast as possible. This will cause issues such as instability, odd errors, inefficient coding practices, band-aid fixes, and all sorts of other horrors. It's not necessarily bad code, but it's is not ideal.

A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature.

From Joel on Software The Duct Tape Programmer.

Not ideal code can be dealt with if it's dealt with. Code that hasn't been dealt with will pile up and in turn make additional changes harder, if not impossible. It can get to the point where the application is so inter-dependently taped together that additions can only be done by the most careful programmers at an exorbitant time cost. While shipping is a feature, so it maintainability.

share|improve this answer
1  
The only thing I would change is the word "you" in your main point. I'd argue that for every member on your team there is a multiplicative factor of things that could go wrong, and for every outside dependency, there is some exponential factor of things that could go wrong. Or vice versa. ;) –  Wonko the Sane Oct 19 '10 at 15:41
2  
@ysolik: See the rewording. It might not be your fault that the planning or estimation was FUBAR'ed. –  Josh K Oct 19 '10 at 15:43
2  
@ysolik: You write less then ideal code to meet a deadline and pray you will get a chance to fix it later. With proper planning this never happens. –  Josh K Oct 19 '10 at 16:28
2  
Never say never... :) –  Wonko the Sane Oct 19 '10 at 19:52
3  
@Wonko: Correct, with proper planning this rarely happens. –  Josh K Oct 19 '10 at 20:02
show 6 more comments

I'm a big fan of software craftsmanship - writing clean code as best I can, etc, but at times I've had to rush during moments where time is short and a deadline is approaching. I really try not do this as best I can, but sometimes you can't get away from it.

Some people will say "Well that's life, you gotta ship" but I really disagree with this attitude.

When writing hurried code, you may end up getting the software out of the door on time, but what happens when, during the next few days, you end up getting support calls relating to bugs in the software (these bugs living in the same piece of code you rushed to get finished). Or you get an angry client calling you asking why their reporting module is no longer working, even though you promised it would be fine on the day of release?

It's all very well saying "You gotta ship", but there is a difference between looking efficient and looking like a sloppy worker.

Cheers. Jas.

share|improve this answer
add comment

Yes. But it always comes back to haunt me later.

share|improve this answer
add comment

When I am under a stress situation, my code is meant to get the work done. Thats it. I do not concentrate on efficiency and other issues, which is bad, in my opnion.

I will work on it though.

share|improve this answer
    
Make it work, Make it right, Make it fast :) c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast –  Juha Untinen Sep 4 '13 at 8:25
add comment

I don't believe I personally write significantly worse code, but I do deliver a worse product.

When faced with an arbitrary and impossible deadline, we skimp on the development process. We do more superficial code reviews (or skip them altogether). We test less, bypass detailed unit testing for spot-check type integration tests, then try to count the integration test as a formal qualification. We tend to overlook anomalies during testing if they are not directly tied to pass-fail criteria. We skip documentation updates, don't double check release notes, forget to scrub the list of deliverables for files that are no longer needed.

The source code you write during a crunch may be of high quality, but it will almost certainly be shipped as part of a shoddy product.

share|improve this answer
add comment

Depends.

Is the pressure because there is no way everything can get done and because major new features are being added hours before release?

Bad code coming up!

But if it is because the schedule is simply really really tight but the overall plan is solid and I just have to work much harder than usual and keep continually focused while tweaking a few features hear and there... Then I produce much better code than if the schedule allows tons of time. Even if it means I don't get all the unit tests written but cover the major parts of the code.

share|improve this answer
    
Oooh -- good comment, except that very last sentence scares me a bit. –  Wonko the Sane Oct 19 '10 at 16:20
    
Well. That doesn't mean they will never get written. It is scary but I think that helps me stay focused. And there are unit test, just not 100% coverage. More like 66%. –  ElGringoGrande Oct 19 '10 at 17:46
    
The only problem is that the 34% that is not covered is the new code that you put in in a hurry, and not the already established code that isn't as likely to (all) break with your changes. Not to say that we haven't all done it, just that its a scary proposition. –  Wonko the Sane Oct 19 '10 at 19:53
add comment

I know someone who never writes bad code under pressure. He also has some magic beans you might be interested in.

Everybody writes bad code sometimes and looming deadlines are the usual reason, the trick is to avoid getting into that situation in the first place (and that isn't easy either).

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.