Software Programming Under Pressure
We’ ve all been there, and most of us (whether we like to admit it or not) will say that we code
just fine under pressure when people are breathing down your
neck to get to that next new release. One of the fundamental things good programmers learn is how to code well in a tight situation, or code without making too
many mistakes and avoid piling up duct tape fix after duct tape fix. In these situations we tend to quickly add in our stuff without thinking too much about
it - try to resist this temptation of just shoving it in there, because the quicker you ship it, the quicker the testers will want to rubber duck it.
Your hurridness can cause issues such as instability, strange errors, inefficient coding practices, band-aid fixes, and all sorts of other horrors. It’s not necessarily
bad code, but it’s is optimal. Personally I am a fan of well crafted software, but if you rush it you know in a couple of days you’ll get that call about some bug. I think
it all boils down to writing worse code, and also delivering a worse overall product. When faced with an arbitrary and impossible deadline, we skimp on the development process,
we do superficial code reviews, or blindly skip them all together. We test less (…if at all), bypass detailed unit testing for spot / manual check type tests, then try to count
that as a formal qualification. I’d rather fight the case where its better to loose a couple days by slipping the schedule than lose time making all the corrections after release.
That’ll lead up to at least a week’s worth of bugs…
From experience I’ve observed that missing deadlines is usually a result of poor planning and estimation, and it’s somewhat rampant in some industries. Acknowledge that the
deadline will be missed, solve the issue and identify the errors with the right people. Non optimal code can become our technical debt. 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.