There's more. As I work through a project and it takes shape, I see possibilities. Case in point: I was working on a tool to monitor 5 simultanious video installations. The tool had to be completly modular and run unattended. Much of the work came with developing the syntax of the config file. Once that was done, I saw how I could use my existing logic and syntax to do siultaneous testing of other features. Implementing this slows down development.

As the project approaches completion, there's cleanup and endgame tasks to do: write documentation, standardize and format logging and debug messages, et cetera.

Finally, there's the time-compression phenomenon. Managers never feel useful unless they've recently given an order. As the project moves on more time has passed since the original order. The manager, unable to see work being done on a long-term project, begins to feel lonely and insecure, and must issue a new order to feel important. The developer is then given a new task to do "in their spare time" or "just real quick". This slows down development of the original project. To combat this phenonenon, I recommend breaking random things around the office. It'll give your manager something to do so they'll feel special and leave you alone to do your job.