Programming in a crunch

Question

Ideally you want a schedule that's accommodating and flexible but when it comes to paying the bills and working in a business, that's rarely a luxury programmers have.

I have been fortunate to have the grace of Steve McConnell and Frederick Brooks to tell me what to do if I want to screw up my project and I take their work seriously.

And yet there are still times when your back is against the wall and you need to speed up the work. What are some "tweaks" to your process you've used to speed up delivery without sacrificing quality? Is this even possible?

I consider learning good practices to be of higher value than learning the actual code so no "be a better coder" answers. That's a given.

Answer 1

jpgs are faster than html pages

Answer 2

Usually, cutting features and work items is the best way to meet a tight deadline.

You can try to rush coding, but you'll almost always pay for it later - You'll spend much more time debugging and stabilizing the rushed code than you saved in the first place.

Answer 3

Actually, I think a lot of programmers and organizations have a lot of low-hanging fruit. Make sure you are using your time productively, know how to trade-off speed for quality appropriately, don't "gold plate" things beyond what your customer is asking for, etc.

Profile your organization's processes. What is the bottleneck slowing you down? Context-switching (i.e., multitasking) is often a real productivity-killer.

I suppose the problem with this is that when your back is up against the wall, organizational improvements like these seem like luxuries unto themselves, even though they are the things that could really help you speed up your work.

Answer 4

Without sacrificing quality, your best options are pretty much the same best options that you have when it's not crunch time: Eliminate unnecessary distractions, focus on the most important work first, obtain better hardware, and offload any work that you can reasonably offload.

Answer 5

Arrange my tasks in some sort of list of small independent tasks (or, tasks where the dependencies are already taken care of in the order). Then, just sit down and clear one task off my plate after another. Anything where I have to coordinate with someone else, ask a question, etc. is punted forward; I just sit and code with no distractions, until I get to a place where I need some sort of outside interaction. Then I deal with all of my coordination with other people, re-planning, and so on in one batch, and go heads down into straight coding again.

Also, prioritize and cut everything that's optional. If you get the required stuff done in time, then go back to the optional stuff, but do what is absolutely required first. This may be relaxed slightly if there are tasks that are easier to do when you're in the right context, but on the whole, try to keep the optional parts to a minimum.

Oh, and don't make these judgement calls while you're coding. When you're coding, just take one task off your list, do it, and move on to the next. As I said, batch up all of the non-coding work into chunks so it doesn't slow your coding down.

Anyhow, that's what I do when I'm up against a wall. Not sure how well it works for anyone else.

Answer 6

The biggest help (for me) is forcing myself to complete each single task before moving on to another one. If I need to get some bugs out of libfoo, or even write libfoo to go on to the next step, I force myself to stay on that task, then the next one, then the next one.

Most of the time that I find myself in a crunch, its because I was too much of a grasshopper, jumping around from thing to thing.

This morning I sat down and forced myself to write a bunch of unit tests, rather than working any more on the library being tested. It sucked, but now they're done, and I can really sail through finishing my library.

Answer 7

I'd suggest learning GTD or something like it before you get in the crunch, using to avoid a crunch if at all possible and then, if you must, get through the crunch by just doing it. Get in the zone and persevere.