Remember the last time your boss roamed into your office/cubicle and asked you to add this one tiny feature to your project in a week? You were tempted to say it is not possible to do it in the time frame, but then you took into account that it looks and sounds as a small feature and it will probably take you only half the time to do it anyway. Also, it is difficult to say “No” to your boss, right? So you said: “Sure boss, I can handle it.”

In the end, what could possibly go wrong?

You see, what you forgot is that even though the feature is tiny, this is not some hobbyist program. It is an enterprise solution and it has to be done professionally, meaning it has to have great UX and consequently UI, it has to follow application conventions and it has to work even in most obscure situations. Also, your boss never told you half of what he expects and he forgot to tell you he intends to show off this feature to board of directors on Friday, so you have to have it ready by Thursday. This will turn your next week into a living nightmare, consisting of developing, building and making complete arse of yourself, because you didn’t get “the specs” correctly. Sure, you should have written specs, but let’s be honest, you agreed to the timeline that makes writing specs impossible to do. I guess you could go to your boss a day later (after you slept it off) and tell him that the feature is a no go, however, you have a problem there. Your boss considers the feature to be tiny. Hell, he even convinced you, the expert, that it is a tiny feature. You agreed with him, so the feature is tiny. No matter what you say or do, you won’t be able to convince him that his feature is in fact a monstrous three week feature that needs planning, specs, Q&A testing and a release on it’s own.

So, to get yourself out of this mess, you need to start thinking strategically and fast. Meet crunch-time development. Crunch-time development may sound like waterfall development, but it is not. CTD plans for everything. It is just that it may not follow all company conventions, as it has to be done in record time. To do CTD well, prepare for 2 days of planning, at least half a day of serious testing and debugging and some serious overtime. The remainder of time you must spend coding. Based on my experience, I can only advise you not to code tired as that will only make your code more error prone. Hence, I advise you that during CTD, you go to sleep early and get to work well rested. Also, if you have Q&A department, explain the situation and ask them for help. A bribe or reward afterwards (I am talking coffee, chocolates, whiskey) should be given and is silently expected.

Planning stage consists of specifying the hell out of the feature. You don’t have time for full blown specs, so do some hand-sketching and explain things on sketches themselves. At all times, nag your boss for more details and show him sketches and improve on them. If your boss is unwilling to participate, then try to convince him that in his best interest to get involved or he might end up with feature he didn’t order.

Back to your “tiny feature”. In case you missed it, you have exactly 4 days to complete it. So, counting down 2 days of preparation and half a day for testing and debugging, you are left with 1.5 days of extreme coding. You can prolong that by doing overtime, but do not over do it, as that will leave marks on your mental and physical health. Not to mention your code.