How do you get through the inevitable motivational "slump" near the end of projects?

Question

When working on a project, after the interesting parts are coded, my motivation is severely diminished. What do you do to get over this problem?

Answer 1

Repeat to myself: My code doesn't exist until it is checked in.

Or if you're not using version control, 'until it is published' or 'until it is launched.'

You could also use fear and say that if YOU don't finish and launch it, someone else will.

Answer 2

Use test-driven development. A failing test is always a strong motivation.

Answer 3

Usually I try to tell myself that getting things to work in the real world is just as interesting, because there is where your code will get credits or will be improved by discovered bugs and feature requests.

Answer 4

Let some testers loose on it. Nothing is more motivating than seeing people use your interesting bits and finding obvious improvements.

Answer 5

Don't leave all the "boring" bits to the end - make sure that each component works, with regression tests and documentation, as early as possible in the project.

That said, the last few weeks are still going to involve chasing down the really elusive bugs, dealing with last-second requirements changes, finalising the documentation, and generally getting the damn thing out of the door. My approach is just to suck it up: put your head down and know that the sooner it's done, the sooner you can start on all the lower-priority, more interesting things that have been queued behind the current release.

You can't completely avoid last-minute requirements/docs changes other than by arranging for your customers to all be on holiday just before release. Or get yourself in a dominating position like Apple and Google, so that customers have no prior knowledge of releases.

You "should" chase elusive bugs (by which I mean the ones so hard to reproduce that you don't have a consistent test case) early, because you cannot estimate how long they will take to fix. But in practice some proportion of them will become less elusive as the project goes on, or turn out to be side-effects of another known issue, so you save time on average by giving them a limited chance to do so. The downside of this is that towards the end there will be a few left. If there are more than about two, though, you've done it wrong.

Taking a short "break" after a major deadline to do whatever you find most fun is a good way to avoid burn-out in the long run. Even if you end up throwing most of it away because you skipped some difficult planning, you'll have made yourself more productive.

Answer 6

I agree it is tough. The only thing that keeps me going is to keep in mind the feeling I would have after seeing it complete / shipped / in the hands of customers.

Answer 7

Don't do all the interesting parts first.

I motivate myself to do the boring code by always leaving a decent bit until last and being strict about completing the boring section first.

Answer 8

"if YOU don't finish and launch it, someone else will."

Told myself that one before. Sometimes however its good to take a break for a couple hours then come back to it. Then you are not as burned out on it as you were.

Answer 9

My motivation is just to Get It Done. Like onebyone said, you just have to hunker down and do it. It's all a matter of priorities. The quicker the priorities are out of the way, the sooner you can get back to the interesting stuff.

Answer 10

I try to push the concept of bug days / evenings. Set a target of bugs/issues to address and when you hit that number everyone gets to go out for (paid for!) pizza/beers. Keeps the morale of the team up and acts as a focus in an otherwise boring period.

Also you can add into this concept prizes/cudos for the best piece of refactoring or performance improvement etc

Answer 11

1. Try to see if you can take a very short break for a day or two and come back more refreshed.
2. Don't leave boring bits to the end
3. Test it yourself
4. Ensure that your diet/exercise/sleep/etc level don't get lower
5. Tell the others that you are feeling a bit down, can you swap areas of work for a day?

Answer 12

In general, when you've done 90% of the work, it's almost ended, you just have to do the last 90% :-)

Always think about that, and you'll see that's a long way until it's working.

Answer 13

I'm happy doing the creative fun bits of programming.

But after that I think about making the user happy.