I do not think that right now is one of those times. I think right now is primarily procrastination. So, I invite you to come along with me, and see where my brain ends up taking us. I have a feeling we'll both be surprised; I can't promise any satisfaction or enjoyment, though. There might be mutant space potatoes with ray guns.
Anyone who has ever worked on a software project, even a tiny one, knows about the Death March phase. It's that ugly, dreary chunk of time, usually at the end of the project. It's when everyone is sick and tired of the project, would rather do something else - anything else - and just wants to ship the damn thing and move on. Tempers are short, hours are long, and even the most rabid coffee connoisseurs quit whining about the burnt Folger's in the office coffee pot and drink it just because it has traces of caffiene in it. The Death March is the "make it or break it" period for a project; either you pull through and put out a win, or you sort of phase out and dribble out something that vaguely resembles that product you were dreaming about so eagerly not too long ago. In the worst case, the project may just get canned entirely.
Death Marches occur, in various degrees, in all projects in the software realm. I think they also occur fairly often in other realms, too, but I don't know much about those realms, so I can't say for sure. (This is not to imply that I know anything about the software realm, mind you - I'm just better at pretending to know things about the software realm.) That nifty little applet you're writing for Grandma is going to hit a Death March. Massive corporate systems have Death Marches. Games have Death Marches; in fact, games usually have some of the most publicized and well-documented Death Marches out there.
The reasons for Death Marches are diverse. People much smarter than me have spent much more time than I have thinking about and writing about those reasons. (I've only spent a couple of minutes thinking about it.) My theory is that the biggest cause is feature lock: eventually, you reach a point where you have to stop creating new stuff, envisioning new possibilities, and just finish the thing that you're already committed to. I can't pretend to really know why, but that transition point seems to mark a decided drop-off in enthusiasm and drive. Good project leadership is prepared for this and knows how to handle it. Bad project leadership is likely to just let the whole thing fall into the crapper and drown. (Pleasant metaphor, isn't it?)
Anyways, I'm not really smart enough (or edumacated enough in things like psychology and management) to know how to cure the Death March phenomenon. Hell, I don't think it can be "cured" at all in the sense of just making it go away; I think Death Marches arise from very real shifts in the emphasis of projects over time. I do know that good leadership makes all the difference in whether or not people actually die during Death Marches. (While I have not, in fact, seen anyone really die under bad leadership in a Death March, I know of many cases where people wished they were dead.)
What I'm interested in at the moment isn't so much the Death March phenomenon. I'm not involved in any Death March projects at the moment, so I don't have any fresh thoughts on the whole situation. I also have a bad tendency to totally forget things when I quit dealing with them actively, so I have no particularly pertinent recollections from past Death Marches to share.
The thing that's been brewing in my mind, making my brain itch so to speak, isn't Death Marches - it's a similar phenomenon, but much less documented, at the other end of the time scale. Death Marches begin when it's time to just buckle down and get the stupid thing done. But something else happens, something similar and yet more subtle, and much more insidious, at the beginning of a project. That Thing is what, I think, has been sparking a lot of my own procrastination lately.
I have no good name for it, so I'll make one up (you may wish to avert your eyes): Pre-Vision Boredom. During the most passionate, invigorated, and adrenaline-charged segments of game development, there's something that really keeps the team going; that thing is responsible for getting everyone to work early, keeping them there late, and keeping them raving about it in thoroughly excited tones. That thing is what makes it so awesome to be working on the project. That thing is why we love our jobs (even if the job isn't game development, but some other thing).
That thing is Vision.
Vision is the core of motivation. Communicating vision is the core of leadership. Project leadership is all about rallying the team behind a vision, getting everyone excited about being a part of something. Vision is the ultimate fuel for our deep human need to be a part of something larger than ourselves. Vision is triumphantly getting some chunky images on the screen, and knowing that when the game is all done, it's gonna be so freakin' cool. Vision is looking up the long, hard road of development towards the finished product, and being so caught up in the joy of that product that we stop seeing the road itself, and just walk.
Death Marches occur when vision starts to fade. The feature list is shrinking, and most of the cool stuff is done. The bug list is starting to grow - probably very rapidly, as alpha testing and usability testing starts in full force. Suddenly, the finished product isn't so easy to see anymore. The road starts to fill our sight, and without good leadership to keep the vision alive, the team is liable to stare so hard at the road that they fall face-first into it and crash.
This much is pretty well known. I'm sure some very eloquent and insightful people have said it better, in many places that are not my journal. But I think they've missed an equally dangerous, but much less visible, problem with vision.
The problem is what the team does before they catch the vision. At the beginning of a project, especially an expansion or sequel type project, this is a very real issue. It's something I personally have been hit hard with, especially without the infectuous physical presence of enthusiastic coworkers. Vision is so much easier to convey in person; it just seems to lose something when all you've got to refer to is the project Wiki and some IM conference logs.
One of the best bits of advice I've ever heard for self-motivation is to just start - don't worry about getting it done, just get started. Once you start, catching sight of the finished product - the vision - is that much easier. Once you've got the vision, wanting to finish isn't a problem anymore. But if you just can't see that vision, you may never really truly get started, and that's where problems arise.
I've almost caught it. There's some possibilities for this next project at Egosoft - largely of a technical nature - which are really exciting me. When I get into the code, and start doing real refactoring and documentation, real work, I can start to see the edges of the vision coming into focus. There's just so much potential, so much opportunity - but not quite yet enough to hit that critical mass and propel things forward into solid, dedicated work. There is potential for much good, yes, but there is also potential for a lot of failure.
Grabbing on to the Vision is everything. I think it is largely the responsibility of leadership to maintain, keep, and spread Vision. However, it is important to remember that everyone has to have a slice of the Vision to work optimally - and the best way to sell someone on a Vision is to let them play a part in it personally. Egosoft is absolutely exceptional for letting individuals play a part in the Vision, but we still seem to lack a little something in the realm of developing a coherent and compelling Vision up front.
I think that, for any team, the sooner Vision is ready for everyone to start being a part of, the better things are liable to go. Losing the Vision at the moment of truth is a danger, but it can be just as deadly to neglect the Vision when the first critical (and irreversible) decisions of the project are being made.
