The deadline problem is, unless a project has a hard limit (like a fixed budget or a client milestone) or a willingness to halt work, it’s pointless to even call it a deadline. And a due date is more a wish than a prediction, given my track record, so I’m not even going there.
Right now THE OCTOBER GAME is running without a deadline or a due date. It’s kind of a problem.
At the end of October I had a choice:
- Cancel the project and admit failure
- Set a new deadline, after which the project halts
- Work on the project until it’s done
Ha ha! Just kidding. There was no choice at all. Even by December I couldn’t stand the idea of not finishing the game. I might have said to myself “any app project is a valuable experience”, or “this is an opportunity to learn something new, yadda, yadda…” Those are what you call rationalizations. I want the game. It tasks me. It tasks me and I shall have it.
A month into Spring I’d changed the way I work. By limiting my hours and resting more I achieved a steadier pace. As I added features to THE OCTOBER GAME, a few of the classes seemed to grow bigger than the others. They became harder to work with and debug. I needed to write better, not just more code.
Analyzing my developer notebook, my plan file and my daily log entries, I found two main kinds of bug: race conditions and incorrect game states. I’ll write more about those later. Essentially I had to stop all forward progress and rework the core game entities. I won’t say I didn’t have fun but it cost two more months and brought me into the start of Summer. That’s when I learned to plan better and keep an eye on the big picture.
To be continued.