Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

May 12th, 2009 at 11:10 pm

Forget about Hope Driven Development (HDD), the cancer of software development.

with 17 comments

Would you go to war without a helmet? Would you drive without the seat belt? Then why do you develop software as if it shit doesn’t happen?

Meet Martin (an average developer) and John (a great developer) Martin is reviewing John’s code:

-Hey John, why do you validate the value of this parameter in your method?
-Well Martin, this is a public method and I’m making sure that its value it’s either “A” or “B” some other value will be invalid.
-I know John, but my class is the only one calling the method and I know I’m only passing “A” or “B”.
-Martin, have you ever heard about HDD?

What’s HDD?

SeatBelt_sign

The previous conversation is a fictitious one, but I’m sure you have been in a similar situation. HDD is the approach to software development where decisions and code are made based on assumptions and guessing

HDD does not only apply when coding, it applies to all the stages of software development, I remember been in a design meeting for a new interface to an external system, the documentation we had was minimal, so we didn’t really know what we were supposed to develop, what did we do? We just guessed what the implementation should be, so when we had to integrate with their system…. CRASH!!! Total disaster, we had to rewrite lots of code.

Everyone realizes HDD is bad, but we all still keep doing it, the only explanation I have for this is that Software Developers are extremely optimistic, is like when we have to give an estimate, 90% of the times our first estimation is: “It shouldn’t take more than one day or a few hours”, which is the same sentence you are going to repeat for the next week.

Most of the bugs I’ve seen During all the years I’ve been developing software were caused because HDD.  I’ve come up with a list of symptoms to detect when HDD is being used and a list of tips to prevent it.

Symptoms that you are using HDD

  • You use words like: “should”, “I think so”…
  • You don’t have unit tests.
  • You are more concerned about performance than your code quality. That’s one of the common traps,  it’s usual to find developers arguing that they don’t want to add an additional validation, or some logic for error handling because that will cause bad performance, that’s wrong, what we should do is first make the best code as possible and then optimize it for performance, 9 out of 10 times the performance is not affected.
  • You don’t have frequent demos/reviews with your product owner/team.

Tips to prevent HDD

  • Every time you hear “should” or “think so” translate it to “I don’t have a clue”.
  • If it doesn’t have unit tests, is not done.
  • Communicate, communicate and communicate.

What do you think?

So what would you do if you were John in the fictitious conversation above, what will you say after all:

a) HDD is just stupid, remove the validation, that’s unnecessary.
b) I see! We have to prevent HDD, let’s keep the validation.
c) Huh?

Please let me know what you think in your comments, I’m looking forward for your opinions.

Easy AdSense by Unreal

Related posts:

  1. Forget about requirements, Software Development is all about inputs, outputs and actions.
  2. The average Software Developer versus the good Software Developer.
  3. Software development and religious wars.
  4. What is good software development?
  5. 5 Tips for creating good code every day; or how to become a good software developer

17 Responses to 'Forget about Hope Driven Development (HDD), the cancer of software development.'

Subscribe to comments with RSS or TrackBack to 'Forget about Hope Driven Development (HDD), the cancer of software development.'.

  1. [...] Read more: Forget about Hope Driven Development (HDD), the cancer of software … [...]

  2. I totally agree with the first point on preventing HDD. Every time you hear “should” or “think so” translate it to “I don’t have a clue”. It happens frequently with people who try to impress their boss or client. In the long run ironically they end up doing the opposite.

    Web Development

    13 May 09 at 1:33 pm

  3. Tottaly lame, our company just got in big performance issue because System Architects didn’t get that performance matters, so beautiful code have to be removed.

    andrey

    13 May 09 at 4:57 pm

  4. I agree with your points. Mostly, we the developers tend to forget about validating the input parameters, hoping that they won’t go wrong. it’s fine in an Ideal world, but the real world is not ideal. So, as you said, HDD shouldn’t be the way.

    veerasundark

    13 May 09 at 5:05 pm

  5. Hi andrey, don´t get me wrong, I´m not saying that performance doesn´t matter, of course it does, but I believe its secondary to having good quality code, ANYWAY you have to always have performance tests sooner better than later, my guess is that in your scenario the problem was that you didn´t test the performance properly and/or in time.

    Alberto G

    13 May 09 at 5:30 pm

  6. [...] Forget about Hope Driven Development (HDD), the cancer of software development. Would you go to war without a helmet? Would you drive without the seat belt? Then why do you develop software as if it [...] [...]

  7. The cure for HDD? TDD.

    Matt Hinze

    14 May 09 at 2:53 am

  8. [...] Forget about Hope Driven Development (HDD), the cancer of software development Making Good Software (tags: programming) TagsCategoriasmiudezas Uncategorized   [...]

  9. [...] checked if the implementation is correct with the customer, that’s a typical behavior from Hope Driven Development and that’s [...]

  10. Nice little piece about one aspect of good programming. The topic is important, and although the few typos irritated my editor’s eye, defensive programming needs to get talked about.
    I’ve actually made a profession out of preaching good quality habits to programmers and one of the issues is checking incoming variables. In code reviews – or what I call ticking the code – I apply a rule called CHECK-IN, which asks the checker to tick any variable that is just used without any kind of sanity check. We don’t always need a sanity check, we can’t always perform a sanity check, but we should at the least know when we expose our code to such dangers.
    For more information, check http://www.tick-the-code.com

    Miska

    15 May 09 at 1:06 pm

  11. Validating input isn’t going to cause performance problems. Horribly written code will.

    tim

    15 May 09 at 7:50 pm

  12. I just realized that HDD is also a lot of what goes on in the fields of international devt, not just software…hmmm

    Mary Ellen

    9 Jul 09 at 11:26 am

  13. Ha! You are not enlightened!
    Keep the faith and you will eventually see the light of PDD: Prayer Driven Development:

    http://blog.jonasbandi.net/2007/10/introducing-add.html

    ;-)

    Jonas

    18 Sep 09 at 2:14 am

  14. See, the problem here is that validating bad parameters turns the code into a mess. It’s an awful lot harder to read a method that contains validation for each parameter…

    But I agree it’s necessary. That’s why I would go for TDD (for documenting your assumptions) or DbC (That would be my first choice, definitely).

    Rodrigo Gama

    18 Sep 09 at 6:02 am

  15. I think for internal parameters the validation issues may be substituted by unit testing. You can check that the parameters passed to your constructors are valid, but this is going to clash with simple unit testing, where you are forced to initialize collaborators you do not use.

    Giorgio Sironi

    30 Jan 10 at 5:08 am

  16. [...] recently read an article by Alberto Gutierrez where he’s talking about a thing he calls ‘Hope Driven Development’ or HDD. And I [...]

Leave a Reply