A lesson learned from the development of Premake 4.1: keep your active projects specific. I mean really specific.
I started development by creating a new project, naming it Premake 4.1, and dropping in a bunch of actions from my backlog. Technically this is a valid approach; the only definition of a project I've ever encountered in this context is "any result that requires more than one action." Now older and a little wiser I realize how incredibly vague that is. Consider: Program TV remote vs. Achieve world peace. Both technically valid projects. One doable, the other not so much (which one is an exercise left to the reader).
My project started out with a reasonable list of actions, but inevitably new ideas came up, features and refactorings, bugs that needed fixing. Because my project was vague enough to encompass all of this new work it soon did, growing larger and less focused, and I started to feel like I was losing ground. Rather than stepping back and fixing it as I should, I tried crunching harder which just made the problem worse. Ack!
Looking back at this trainwreck learning experience, I've come up with some rules to help keep my projects manageable going forward:
- Projects should be a dozen actions or less, a number I pulled out of thin air based on past experience. If it requires more than a dozen steps it is probably larger than I can get my head around in one go, and likely contains hidden work. Better to split it up.
- If I have to think about whether an action belongs in the project or not, one of them is too vague. Either the action needs to be more specific (or become its own project) or the project needs a tighter focus.
- Project names should always start with a verb. What is it I'm trying to achieve with the completion of this project? That doesn't prevent Do stuff projects but it at least makes me think about it for a second.
- When in doubt, split it up.
There are probably more rules, I can't remember. I reserve the right to edit this post later.
I've been doing this for about three weeks now and while I thought it would help my planning a little, the gain in clarity has been quite remarkable.
- I'm more agile. Smaller projects take less time to complete, so I complete more of them. Each time I finish a project I have a chance to change direction, to course correct.
- I'm more focused. Smaller projects make it easier to decide what to include and, just as important, what to leave out. No more feature creep. And because I can get the project done quickly, there's no need to bounce back and forth between projects. Just finish it!
- I'm more motivated. A smaller project requires less distance from start to finish. I can see the light at the end of tunnel right from the get go, and I've got a good sense of how much effort it will take to finish. No more death marches, and frequent positive feedback as projects—not just actions—get checked off.
- I'm more thorough. Because the end is in sight, I feel less pressure to rush, and I'm more inclined to do things properly. And because extraneous tasks are no longer allowed in the project, there are no distractions to keep me from writing documentation and similar unglamorous work.
- I'm getting more done with noticeably less effort. And isn't that what it's all about?
The downside of all this project splitting is that I now have a lot more projects to manage, so I've started aggressively pushing stuff off to my Someday list. If it overlaps with something already on my active list (like two Premake enhancements, for instance) move it to Someday. If I know I won't get to it for a couple of days, move to Someday. If there is any doubt about whether it is important, or if I'll get to it, or if I care about it, move it to Someday. I had to come up with some tricks to keep my Someday list manageable—perhaps in another article.
Okay, I think that's it. Lesson learned.
