David Erik

"This blog has more redesigns than posts" - Any reader

A new perspective on time saving

Saving plenty of time later by spending little time now is something that occurs at at a regular basis. By spending initial time structuring work, many hours will be saved during the now well organized project. Document the code you write and you will save time when you have to understand the same code a few years later. Paint the house thoroughly instead of doing a sloppy work, and you won't have to do it again every year. This concept makes a lot of sense. But it can be interesting to consider the opposite: Saving some time now, at the cost of having to spend plenty of time later.

This is commonly know as the "bad" version of time management. Just take the opposite of the earlier examples and it's obvious why. Skip code documentation and tear your hair out when you have to understand that code later. Don't fix your broken bike and instead walk to school for a month (losing 30 minutes every day) to avoid spending 30 minutes once to correct the problem. The examples are numerous and it's considered bad to choose this path. But this is not always the case. Consider these two scenarios:

The principle is assuming that my time later will be worth at least as much as my time right now. And time value can shift incredibly fast. Let's reuse the coding simile and pretend that a project must be done at a tight deadline. You could complete the project and documentation exactly in time for the deadline. But you skip the documentation part and five hours are yours to spend as you like. A year later when you have to change something in the code, this takes ten hours extra since it's so badly documented. You gained five hours and lost ten. Bad deal. Unless those five hours right before the deadline had more than double the value of these ten hours. Maybe you had the possibility to travel into space, and this was a once-in-a-lifetime offer. Maybe you just had a nice time with your friends. As long as those five hours were more valuable to you than ten arbitrary hours later when nothing would have happened anyway, this is considered a good trade. The example might be a little bit stretched, but the principle stands. Time can have different value at different times. And more time isn't automatically the best outcome.

There is also the possibility that you never have to spend the "punishment" hours that should happen as a consequence of your "lazy" action. If neither you nor anyone else would ever need to change anything in that code, the five hours would be a direct gain. You could bring statistics into this if you enjoy such things: If you know the odds of the punishment happening, you can weigh the gained time verses the potentially lost time and find out what action would result in the most won hours.

I'm not saying that you should be lazy. And no, I'm not saying that you should never document your code. I'm simply stating that time saving is a little more complex than it seems. Effectivity is not laziness.