On the individual level, everything can start innocently enough. You think "I could have coded this much better, but there's no time now. I'll fix it after the weekend. Nobody'll notice." Trying to just get away with something opens the door to the Vicious Circle of Busyness. On Monday, something else comes in between and you eventually forget the fix. Your slightly suboptimal code slips into the release and nobody notices. Next time, going over where the fence is at its lowest is even easier. Before long, shortcutting quality becomes a habit. Everything is fine. You have found a nice and cozy way of working. It doesn't exactly make you proud, but at least you're on schedule. Until one day, when a customer notices a problem.

The customer in this fictional example is an internal one. There were several customer projects, all integrating the newest versions in their code bases. For a long time, the customers had been unhappy with the code. It didn't integrate very well, and it was difficult to configure. Until today there hadn't been a real reason to complain about it. Now there was a clear error in the code. The originator would certainly hear about this. An error report ought to make him change his ways. And while we're at it, let's complain about those other things, too.

The first few error reports surprise you and you try your best to respond as quickly as you can. You are working on some other new features at the time and remembering how you implemented the erroneous code takes a little longer than it should have. You don't really have time to completely finish the error handling of the new feature, but it should be fine. These critical errors are more urgent, anyway. If you don't fix them quickly, your boss might notice and then there would be hell to pay.

But the new feature isn't fine. The customers of the code are disappointed with it too, and come up with several error reports on it. You are trapped in the Vicious Circle of Busyness. You can't find your way out because there is always something, a critical error or some new functionality, that you have to work on.

You don't even notice when your working day turns from nice and cozy to chronic stress. Being constantly under pressure starts to affect your ability to code. You have no time to improve your skills, you can't even keep them at their original level. You aren't proud of your coding. You aren't able to apply your skill like you know only you can. Coding isn't fun with everybody demanding something from you. After a few months of feeling meaningless and inadequate, you suffer a nervous breakdown and have to take medical leave. Your colleagues talk about burn-out but never see you again. You quit the whole software business as no fun.

The story is fictional and over the top, but it should highlight the fact that taking shortcuts in quality to save time usually means to shortchange quality for time. You seem to gain some time now, but when the unfinished business comes back to haunt you, the rework required is much more than you saved. Overall it doesn't pay off to try and cheat in quality. Reality will kick back. The problem is that even if you wanted to do it right, there's no time once you get stuck in the Vicious Circle of Busyness. You suddenly have two problems, the suboptimal quality in the old task and no time to properly finish the new task, either.

The Vicious Circle of Busyness is an important concept in Chapter 3. "Root Causes". In this excerpt, we look at it with from an individual point-of-view. There are also teams and whole oraganizations caught up in the circle. The situation isn't as hopeless as it sounds. If you are held hostage by the Vicious Circle of Busyness, i.e. you have been ignoring quality in order to save time, Tick-the-Code can help you.