Will doing a job badly actually save time?

Day 234 / 365

Working in software development, I have always had troubles with deadlines. For those of you not familiar with software development, There are two aspects of code which we deliver. First and foremost is that is the code working as expected. This is what the clients are most worried about. Second is, is the code of good quality? which is something that affects the developer more, and often the clients don’t even care about it.

When you start off you write your code really well. You write verbose variable names, you add good comments and documentation and even unit tests. But as you get closer to the deadline, you have less time left for all this. The clients are on your ass and asking for just code that works fine. You are faced with a choice here. Do you write good quality code, or do you just push in a bad product that just does the job?

More often than not people choose the second option. And the reason given is that it’s to “save time”. But does that really save time in the long run?

What happens generally with these bad jobs is that in the future you need to spend much more time fixing all the mistakes that happened as you didn’t spend much time, in the beginning, to be careful. You tried to save a few days, and end up wasting a few weeks. In the worst-case scenario, you have to scrap the whole thing and start again.

A stitch in time saves nine, we’ve always been taught. The more you delay fixing a trivial issue, whether it is in your work or your personal life, the more terribly it will come back to haunt you.

This post is part of my 365 Day Project for 2019. Read about it here

Yesterday’s blog —Time Tracking