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?
Asked
Active
Viewed 2,768 times
13
-
Let me challenge you in one big way: some of the biggest, best innovations I've come up with have been the product of an immediate, pressing need. Sometimes the heat of battle brings a razor-sharp focus that days and days of pontification and craftsmanship do not inspire. – user1172763 Oct 15 '19 at 13:43
8 Answers
32
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.
Wonko the Sane
- 3,172
- 1
- 24
- 24
16
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.
Josh K
- 23,019
- 10
- 65
- 100
-
1The 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
-
Agreed. However, when you are just a developer, you may not have a say in the planning phase and find yourself in this situation not because or your own mistakes. – ysolik 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
-
@Josh: I figured that was what you meant, but wanted to make sure it was clear to everybody. – Wonko the Sane Oct 19 '10 at 15:47
-
@Josh: So, do you write bad code in the end in order to meet the deadline? – ysolik Oct 19 '10 at 15:53
-
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
-
3
-
I believe this is the Joel On Software post you had in mind: http://www.joelonsoftware.com/items/2009/09/23.html "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. A really important feature. Your product must have it." – Tim Goodman Oct 19 '10 at 21:20
-
@Tim: Yep! I'll add the link. I remember the "endlessly polishing" bit. – Josh K Oct 20 '10 at 01:56
7
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.
Jason Evans
- 845
- 6
- 13
2
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.
ivorykoder
- 321
- 1
- 3
- 8
-
Make it work, Make it right, Make it fast :) http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast – Juha Untinen Sep 04 '13 at 08:25
1
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.
AShelly
- 5,793
- 31
- 51
0
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.
ElGringoGrande
- 2,913
- 22
- 20
-
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
0
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).
FinnNk
- 5,799
- 3
- 28
- 32