Hope Driven Development - Are you doing it?

HDD (and it don’t mean Hard Disk Drive ☺) is intuitively a bad approach on Software Development. If someone tells you that many times is doing Hope Driven Development, only by name you might say “Oh that’s a bad thing. Stop it now!”

But everyone is doing it… Not always, not even most of the times, but sometimes it happens. Why is that?

First of all let me give you my definition of HDD and please do comment on that.

Hope Driven Development is an approach to Software Development that encourages the developer to write code, hoping that this code will run always as expected and ensuing that belief by praying. HDD also encourages the developer to overlook the fact that this code might not work as expected and points out that it might work. Last but not least, when someone is doing HDD it’s possible (yet, less likely) to believe that when the time comes and everything goes wrong a magic unicorn will come and save the day.

Now that we have a definition (or at least we think we have) we must figure a way to tell when we are doing HDD.

  1. So by definition, when we use phrases like: “should/might work”, “even if it breaks no big deal” (deep down we know it will but hoping that this day will never come), “it got to work” etc then we probably doing HDD. And I ‘m not talking about the entire process of Development. I ‘m taking about that tiny piece of code that we are referring to.
  2. When we don’t have unit tests (or we have an empty project that we call “Tests”).
  3. When we are worrying about performance too much. ex: I expect a Person argument in this function and I shouldn’t validate it cause I already validating it three calls behind. So I believe and hope that I will always get my argument validated.
  4. You are writing “spaghetti” code and no-one else in the team wants to hear about that code (hoping they will never have to find out)
  5. You are writing “spaghetti” code and you your self want to forget that you wrote that piece of code (hoping that you will never have to change it again)There is also a possibility when you write spaghetti code and you love it plus the team want to know more about how this could be more complex. In that case you are not doing HDD. You are just weird Smile with tongue out

How can you change your HDD approach to a project?

STOP doing the above Smile

This post is more of a note to myself because there are times that the pressure is huge and wrong seems right…

Comment and share if you feel the need to…


  • Nikolaos Georgiou on said


Nikolaos Georgiou

    "or we have an empty project that we call “Tests”"
    $1you too huh? :-)
    $1Nice post! I'd like to emphasize on #3. If you're writing a method, validate its arguments and throw an exception fast. Otherwise you'll end up with some Object Reference Not Found somewhere deep down trying to understand where it came from, instead of a frindly Argument Null Exception "missing person argument" that is much more helpful.



    This "should" or "might" work mentality usually comes as a result of research activities/spikes that are intended to produce throw-away code but somehow becomes production code.
    $1The lines and verbiage just get blurred over time.
    $1Good post!



    I do not think that the "should/might work" is such a bad thing.
    $1This is something I hope to do every day! If I stop doing that it means my projects are boring and I'm repeating myself. I want to explore the unknown! Off-course we run a prototype before creating a complete technical design based on the should or might but that's an other story.
    $1That's my 2 cents.

Add a Comment (gravatar-enabled)