Skip to content

Can we stop the Hydra from eating our project joy?


One of my favorite phases of any project is the beginning.  I love starting things!  The project landscape is like a blank sheet of paper or fresh blanket of snow.   There’s so much excitement, so many things to do, so much new stuff to learn and puzzles to solve and details to figure out.

Then, a few weeks into the project, the inevitable shift happens.  Problems crop up. Deadlines start to slip. Feature creep, bugs, negative feedback from beta testers, unforseen complexities. People just plain lose interest, or get distracted by life, or get interested in the next thing. Inevitably, all of these factors aggregate to form a gigantic Hydra that continuously attacks your project, your morale as a team, your spirits.

Now, instead of innovating and trailblazing, it becomes a full time task just to avoid having your soul consumed by the violent beast. Now the fresh blanket of snow becomes tattered, stained with the blood of you, your team, and the beast.  The once unblemished landscape is littered with the serpetine heads you are able to strike down, which is never all of them, and as it is with Hydras, they just keep growing two for every one you lop off.

So you run around feverishly, wielding the sword and shield of your text editor, design documents, acceptance criteria, project tracker, and whatever other infrastructure you use. Bemoaning the wretched beast that is the [end  user|stakeholder|team member|pm|contractor] from whence your woes originate.

And the deadlines slip. And momentum winnows steadily down. That fervor which propelled you, tires screeching, adrenaline coursing, from the starting line, has all but gone. This COULD have been such a great project. We SHOULD have made history. It SHOULD have been a game changer. Now the excitement is replaced with disdain and resentment. The joy is replaced with frustration and loathing. The Hydra is winning.

How often do we introspect on what we did that caused or exacerbated the problem? Apparently, a fair bit. Google shows 5,570,000 results for the query “why do projects fail.” If there are nearly 6 million resources for figuring out how to prevent a project from failing, then why do we keep repeating the cycle? In our introspection, though, are we considering our own actions and how they impacted the situation?  Did we give in to the desire for the ‘right’ solution over what the context of the project called for at the time?  Did we give in to pressures for the ‘fast/cheap’ solution when we knew it would only cause problems down the road?  Worse, did we choose the quick fix to meet a deadline, only to create more work for a team member in a future iteration?  Have we  failed to build sustainability and accountability into our workflow?

Are we improving our ability to recognize when we are taking an action or making a decision that could negatively impact the workflow, or the team, or the quality of the product?  What can we do to become more aware of how, and when, our choices and actions steal joy from the project? What have you done in the past that has kept that initial fervor burning? How can we, like Heracles, avoid the poisonous breath and cauterize the exponentially multiplicative neck stumps of the ancient beast, vanquishing it for once and for all?

I hope I’m not alone in saying that I am bone tired of watching great projects and great teams with great intentions run out of steam halfway to the finish line. Is there anyone out there who knows how to successfully avoid these archetypal nightmare scenarios? If so will you please share your solutions here?

The Hydra

  1. Great post, I know many in our industry share similar frustrations, as do I.

    I think, however, that part of it is an unavoidable “honeymoon effect.”

    A few initial thoughts…

    Deadlines are toxic when they force you to speed up to the point that your quality is compromised — i.e. cutting off one hydra head sprouts 3 or 4.

    Have a “no broken windows” policy — easier said than done — when you see something broken, fix it, don’t complain about it. And you need to have a project “defender” who buys the team time to do their best.

    I think many projects have constraints that doom them to disappointment. So we’ll never achieve a 99.999% satisfaction level on our work.

    A final thought is that initial versions of our domain models are inevitably going to be wrong, and as soon as enough of that “wrongness” piles up, people start feeling blue about the project. It’s important for everyone to understand when the project begins that some areas will require rethinking and rework, throwing away great well-tested code in the process.

    • seeflanigan permalink

      Couldn’t agree more. In my experience, unrealistic deadlines, or those lacking context (other work tasks, learning curves, etc.) have been the single greatest enemy of quality and work satisfaction. So how do we alleviate that, without doing things like padding estimates that sacrifice honesty and transparency?

      The “no broken windows” policy sounds familiar. The Pragmatic Programmer book maybe? Definitely easier said than done there, especially on small teams. Do you see ‘Project Defender’ as a full time role, or is that a hat worn by a senior dev or a leadership type? Or, by whoever is the most appropriate person at a given time?

      While I concur to a point regarding constraints, I think Neal Ford made a compelling point in his talk Creativity and Constraint (video, someone’s notes) that when we have all the time in the world, our natural tendency is toward getting nothing done. As a terminal procrastinator, that certainly rings true for me. Maybe it’s another one of those critically important but difficult to balance factors?

      In Design Patterns in Ruby Russ Olsen talks about the idea of programming while stupid. It’s a concept that makes sense, but maybe it needn’t have a negative impact? If we are aware of the phenomenon, can we account for it, and factor it into our process of managing expectations?

      You make some excellent points Ryan, very thought provoking. Thanks for getting the conversation started! Perhaps with the right balance of awareness and insight we can all work together to come up with some ways to minimize the barriers to satisfaction. Life’s too short to give up on five nines!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: