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 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?

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.
- First care about your code quality, then improve the performance.
- 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.
Related posts:
- Forget about requirements, Software Development is all about inputs, outputs and actions.
- The average Software Developer versus the good Software Developer.
- Software development and religious wars.
- What is good software development?
- 5 Tips for creating good code every day; or how to become a good software developer
![[Google]]( http://www.makinggoodsoftware.com/wp-content/plugins/easy-adsenser/google-light.gif)
[...] Read more: Forget about Hope Driven Development (HDD), the cancer of software … [...]
Forget about Hope Driven Development (HDD), the cancer of software … « News : India-Developers.com
13 May 09 at 4:37 am
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
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
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
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
[...] 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 [...] [...]
Top Posts « WordPress.com
14 May 09 at 1:00 am
The cure for HDD? TDD.
Matt Hinze
14 May 09 at 2:53 am
[...] Forget about Hope Driven Development (HDD), the cancer of software development Making Good Software (tags: programming) TagsCategoriasmiudezas Uncategorized [...]
links for 2009-05-14 « pabloidz
14 May 09 at 12:02 pm
[...] checked if the implementation is correct with the customer, that’s a typical behavior from Hope Driven Development and that’s [...]
5 Tips for creating good code every day, how to become a good software developer « Making Good Software
15 May 09 at 10:37 am
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
Validating input isn’t going to cause performance problems. Horribly written code will.
tim
15 May 09 at 7:50 pm
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
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
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
[...] http://www.makinggoodsoftware.com/2009/05/12/hdd/ [...]
FizzBuzz » Cleaning out the Bookmarks #5 – Hope Driven Development
25 Oct 09 at 9:37 am
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
[...] recently read an article by Alberto Gutierrez where he’s talking about a thing he calls ‘Hope Driven Development’ or HDD. And I [...]
Let Fortune Cookies Develop for you
1 Feb 10 at 2:59 am