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?
closed as off topic by yannis Aug 28 '12 at 0:56
Questions on Software Engineering Stack Exchange are expected to relate to software engineering 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.
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.
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.
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.
Yes. But it always comes back to haunt me later.
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.
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.
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.
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).