Sometimes you return to working on a programming project from doing something else only to find that the project has fallen apart! Setbacks are always quite distressing when they happen. The longer you leave a project untouched, the greater your chances of returning to disaster.
Unfortunately, everything tends toward disorder. Rarely does rain work to improve statues, preferring to grind them into sand, instead. So, too, does time ravage your code! Dependencies break, other commits conflict with your own, memory leaks begin to add up. Though inevitable, we can try to mitigate the damage that setbacks can inflict.
Planning for regular maintenance allows you to stay on top of problems instead of letting them build. Projects aren't normally killed by one big problem, but by a thousand small setbacks. I prefer to set a limit on the number of unfinished bug tickets in my projects. Allowing yourself 3-4 unfixed problems enables focus on creating new features, but disallowing any more than that prevents setbacks from turning into a catastrophe.
Your mindset about setbacks is just as important as your process for addressing them. A setback need not lead to frustration; take it as a challenge and enjoy it! I have heard it said that success is the ability to move from setback to setback with no loss of enthusiasm.
If we accept this kind of change as inevitable, then we can see it as just another part of the game of software development. If we accept this upkeep as a reality then we can plan for it and, when it occurs, attack it as if it were a new feature. Try and face your setbacks as enthusiastically as possible. May you overcome all of your setbacks and find software success!
