How to handle Deadlines

Deadlines in the programming world are tricky. They are a necessary evil unfortunately, so one needs to learn how to deal with them.

 

I think it's important to deliver in time and make your deadlines, but I also think it's near impossible(!). The biggest problem is that estimates are so unreliable. The only way to get a perfectly reliable estimate on how long a bit of programming is going to take is to go and physically write the code - only then will you comprehend all the "devil in the details". But then the "estimate" is no longer an estimate (it's like saying Africa is a 1:1 scale map of Africa).

 

Another problem is that requirements are often misunderstood and change frequently. So even if you did estimate 100% accurately, you probably estimated the wrong thing. Crap.

 

To cope with deadlines,  you have four options:

1. More accurate estimates means you're more likely to take on just enough work and not too much. You'll never get to the 100% accuracy mark, but doing more in-depth planning and design does help get you closer to it.
2. Sacrifice code quality - i.e. no unit testing, copy-paste code etc. This may help in the short-term but will probably come back to bite you (especially when requirements change and you have to change your code). So I never recommend this option.
3. Work more hours - either cut down on distractions and interruptions so you can work more hours during the normal working day (this is good), or work overtime after-hours (this is bad).
4. Cut features - release something, even if it doesn't have all the features required initially.

 

Personally I try to cut features. Where possible I try to be more productive during the day, but there's only so much you can do. I try to never work overtime. And I try to never sacrifice quality.

Posted via email from The Coder's Perspective