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 25 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.

25 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. […] 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 […] […]

  6. The cure for HDD? TDD.

    Matt Hinze

    14 May 09 at 2:53 am

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

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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

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

  15. I would say that if John’s class is the only one calling Martin’s method, that method should be a private member of John’s class.

    Didn’t anyone else notice this?

    Also, if the parameter isn’t A or B, does it throw and exception (so Martin needs try/catch all over the place)? Does it return a default value? Does it return it’s own Out of Band value? Does it simply do exit(666) into the abyss without leaving a stack trace?

    What makes anyone think whatever John does in response to detecting the error won’t cause a worse problem than ignoring it?

    Maybe it is
    #define A TRUE
    #define B FALSE
    void martinsMethod( bool input) {
    if (input != A && input != B ) …

    No, the cancer is all those stupid design mistakes which are never corrected and arbitrary rules that created cluttered, complex code in the first place, but every method does all kinds of fancy checks for the most improbable events.

    E.g. A 7 deep nest of methods will each dutifully check for a NULL pointer and just do nothing with it, so a security program which is validating a password will return OK instead of crashing with a segfault, letting the hacker through. I would rather it crash and halt than try to continue spinning who knows where.

    HDD – Horrid Dogmatic Design – is writing out the design – all the classes – at random before you have any idea what you really need to do – and using Hope that you can turn the monstrosity that you refuse to fix at the higher level into something that works by doing a perfect implementation.

    tz

    27 Apr 10 at 8:30 am

  16. Clarification – if the input can only have two valid values, it should be a bool, isAandNotB, or vice versa, even if John’s class is doing something complex involving private members of his class, but it begs the question as to why there is exactly one different class calling that method. Something is very likely wrong in the design.

    It seems very popular to fragment things into as many objects and classes and methods as possible, but this is bad design, not much different than being paid in KLoCs (thousand lines of code).

    Often, when I hear a story like this (and I’m probably oversensitive), the two classes should be one larger class.

    I’ve seen so much bad, fragmented C++ that suffered from this.

    The designs I have seen that were blocked off into classes without trying to minimize the interfaces, and rules are put in place to “check everything” without a good guide as to what to do or even probability (the CPU is overheating so changes the value in its register).

    If a method can only take two values make it a bool. If three, an enum or an array with 3 members.

    If divide by zero will be a problem, try to mathematically transform it so you don’t need a divide.

    Tell me how many new() methods do the right thing when memory allocation fails. Allocating statically might waste things at times, but the breakage is immediate and constant.

    HDD is having a spare tank of gas, radiator fluid, and spare tire because you built the car to break down, or can’t be sure it won’t.

    It is much harder to design the structure so that it can’t break, isn’t dependent, has no “invalid inputs”, but that will result in high quality code.

    And it may not be harder than peppering exceptions and try/catch blocks through the code. Will you really code unit tests for EVERY exception condition?

    Making it bool gives it two possible inputs and whatever complexity it does internally. Adding the test for validity means you need to test every other possible wrong input (e.g. 257 is treated like 1 instead of being detected), and then also write the code not to just examine the internal state change and outputs, but do whatever handling, typically exception handling, used to detect the error.

    Then, since it is in the definition of that method, the test fixture for the calling class has to be modified to cause the same thing to happen – or not?

    That was the conversation – does Martin’s class handle it when whatever error detection happens – if Martin ever sent a wrong value into John’s method, Martin’s class now needs to deal with the fallout – but how do you test that if Martin’s class always sends in correct data? Occasionally treat valid data as invalid to insure Martin’s upstream handling is OK?

    Then there’s those who call Martin’s methods, if any (hence my merge the classes comment). Every one of them will have to handle whatever Martin does to handle John’s action in the invalid input case.

    So now the code around the interface is 10x larger and more complex, and we really hope the unit tests we are writing will trigger things properly and that we didn’t miss anything or introduce more numerous and subtle bugs with the full and properly implemented validity checks at all levels than were likely to be there originally.

    Or you code some simple, throwaway handling and use the same HHD you originally criticize to avoid validating the entire exception handling chain.

    Try working through the original example and remove HHD completely, not just from the first level.

    And my suggestion – make it a bool so it can’t be invalid by definition. The code still needs to be tested, but the number of cases is now far more limited.

    tz

    27 Apr 10 at 9:24 am

  17. You called HHD a cancer, but is the alternative exception handling metastasis?

    And what if in the exception handler we run out of memory or the error logging connection breaks? Ah we need yet another layer of exception handling to handle the exceptions caused on the original exception handler – disks get full, you know. Or do you just “hope” the error message will be logged properly, or the dialog box will get on the screen. And we need unit tests for all that too…

    This has gotten too long already, as would the code.

    John should trust Martin is good enough, or if he isn’t change the interface so it depends neither on Martin’s ability to send good values, or John’s (and everyone else’s) ability to handle bad ones properly.

    tz

    27 Apr 10 at 9:31 am

  18. I agree that hope driven development is a problem, but your approach isn’t much better and comes across as dangerous and naive.

    Formal planning and requirements are key, but you don’t mention them at all. Not every program needs a complete suite of unit tests, it depends on the scope and lifecycle of the project. Similarly, performance is a requirement, and so should be quantified before any code is written.

    Rick Minerich

    11 May 10 at 7:19 am

  19. @Tz

    You make a good point when it comes to the public bit, if there is no obvious other user of the method it has no business being public (for the time being).
    The method itself can still be valid for other reasons, SRP and encapsulation come to mind.

    If Martin is really sure about his code then he doesn’t need to add a try/catch block to catch anything does he? (don’t use CheckedExceptions if you are working in Java) Remember that he is the source of the exception, not a victim.

    However if he does make a mistake John’s method will make that apparent. This is a basic ‘fail fast’ concept. Without the exception Martin will first have to dig through John’s method to figure out what’s going wrong.

    Also if Martin is unit testing his code he will get these same exceptions as his code calls John’s. In my view this will actually -help- Martin make his code more robust.

    If Martin does call John with bad data I see it as a requirement that Martin handles this. How can John possible know how to resolve the issue, it’s out of it’s context? It’s a precondition thing; “I can’t service you given this”.

    In a public scenario I do unit test for all exceptions on John’s method. I do not unit test private methods, if John’s method would be private I would test Martin’s method only.

    Typically I don’t put pre-condition expections in private methods but I may put in some asserts which the compiler can drop when building a release.

    Constraining the method input supporting on the compilers type checking is also a good solution, be it booleans, enums or whatever. Not always possible though.

    Tungano

    11 May 10 at 7:59 am

  20. […] 也有人說,「希望能促進開發」,若你對於某些事並不確定,或是你發現你自己使用了「應該」這個詞彙,那麼你麻煩就大了。 […]

  21. thanks for article alberto. my choise 2, prevent hdd :)

    ertan

    10 Jul 10 at 5:50 am

  22. When i first started coding in a junior position I was told to follow the JFDI model of development… I felt kinda stupid for not knowing what it meant so asked one of my senior colleagues whose response was…

    Just F**king Do It model!

    Web Developer

    14 Feb 11 at 4:17 am

Leave a Reply