You Can’t Rush Code

Effective time management means knowing when not to be a perfectionist. For example, it’s better to do something hurriedly when other people’s tasks are dependent upon it, and when a first (or second) draft would suffice. Revisions could be done afterwards as necessary. However it has been my experience that it’s never OK to code hurriedly. The subsequent time and effort wasted on the inevitable bug fixes is just not worth it. It may be just a few lines but there are a lot of hidden costs: time taken to context switch, build locally, unit test, rebuild, promote (worse still if you need to merge), and to ensure build does not break on the continuous integration server.

Ideally one should sleep on code involving algorithms and business logic: after a long and intense coding session, leave it overnight and review it with fresh eyes the next morning. Peer review would be even better. If you ever find that you’re rushing, don’t. Inform your project manager or tech lead that you need more time. If there’s no leeway, you have to manage people’s expectations accordingly by warning them of the scenarios that your code doesn’t handle well. Alternatively, you could just focus on the happy path (which is almost always the simplest to code) and leave edge cases for the next iteration, making this clear to others.

My university lecturer once boasted that his code doesn’t have bugs, period. At first I thought it was because he was smarter than the rest of us. Now I know why – he’s in an academic environment where time, relative to a commercial environment, is in infinite supply. In the real world, it’s always a trade-off between scope (features), time frame, and bugs.

26 December 2008 | Software engineering | Comments

One Response to “You Can’t Rush Code”

  1. 1 Ady 26 December 2008 @ 6:23 pm

    Yes try to put the lecturer in our shoes I bet he/she will not be able to do it and even commit suicide on the first day.

    “Those who can not do, teach”.

    I’m just being mean today.