I'm not entirely sold on the fact that the title of this series is completely fitting. At least, it certainly feels a tad bit on the ironic side given the breadth of my experience as an interactive developer. Project Management from the Developers Perspective. This suggests that I have a viewpoint - or at the very least, have a vantage point to “see things”. The reality of my experience has taught me in some of the most brutal ways, that more often than not, I’m too busy assuming the position to actually be able to have one.

Much of my development experience as a Flash Developer can be summed up by an acronym I have recently been introduced to and admittedly cannot stop abusing - BOHICA. Enrich yourself and take a trip to the urban dictionary too look up this term.

Developers - quick! Assume the position and stop struggling - it will invariably hurt less.

Most developers will know exactly what I am referencing. It’s the point in the project where you might be fairly confident that this just may end up being a project that actually isn't completely messed up. Things seem on track, irritations are few and far between and your inbox is no longer under attack by those beloved emails that are marked high importance yet are missing subject lines .You walk in one morning, grab your morning coffee, fire up your computer, twitter something void of context, open Firefox in yet another attempt to finish the internet and then you hear it. Its the beeline sound that only a project manager can make as they take the most direct path towards you, eyes on target, determined and full of purpose - channeling a force beyond recognition and downright scary as hell. The project manager slows to a halt at their destination, stops and waits impatiently for the developer to acknowledge them. Developers avoid the awkwardness of eye contact by staring straight forward at the monster wall of monitors as the verbal capacity switch is internally flipped. Efforts are now focused on appearing to be “in the zone” - a term used solely by anyone other than a developer to describe that state of complete engrossment and utter withdrawal.

It starts with a compliment. It always does. It’s a little known fact that Project Managers moonlight as sandwich artists with a limited menu comprised of a single masterpiece - the compliment sandwich. The meat of the conversation is sandwiched by two completely unrelated compliments that are crafted in a very madlibs-esque fashion. Chances are, they love your hair, or your shirt, or some other random noun, and without fail, think you are the best. Between that, they slip in the news that the deadline has moved up on what was once a promising project. Its potential for creative greatness was crushed the minute they invited the client to walk all over them by approving requests that likely belong in the land of the ridiculous. With that compliment sandwich comes a bad case of personal time ingestion - in one fell swoop a developer's' nights have been raped and their weekends pillaged.

The project process fails for a variety of reasons, often complex and compounded by many unforeseen variables- and most reasonable, flexible members of a team accept this. Its when the process fails, by allowing people to perpetuate bad project process, that isn't as easily digested by those most affected by it.

Bad project process limits the potential of a developer to contribute meaningfully to its success. Bad project process ensures that developers cannot be anything more than an implementation monkey.

Good project process, or at least a functioning one, enables developers to be innovators. Meaningful innovation requires a nurturing environment that fosters it. Meaningful innovation is important, because meaningful innovation is a competitive edge. What better way to set one apart, than by doing something that might not have been done before?

So, how do we avoid the wrath of the infuriated developer? What things can be done in the project process - from a developer’s point of view, that might make the project run just a little bit smoother? As critical and overtly cynical as most developers are, they are not seeking perfection - they are simply seeking progress.

In this series, its my hope to do more than just entertain but also to introspect and evaluate both the successes and failures of current common project processes. By looking at common things as estimating, schedules, taxonomy, and deadlines, I hope to not only point out the issues but offer solutions - from a developers perspective.

Read the rest of this series here.

Read more from Stacey Mulcahy.