Guess-driven development

A few days ago, I received a link to a blog post called some lesser-known truths about programming. Among other things, it states:

Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.

Patrick, my business partner, jokingly calls this Guess-Driven Development and I now take the liberty to publish the term in writing. I will admit that I have fallen for this type of development quite a few times. But now I have started to wonder: Where is the fine line between guessing and exploring?

When faced with a strange bug or error in some system, we are taught to use e.g. a debugger and over time, we hopefully become more adept at solving bugs. But sometimes (many times) I have solved a problem by almost randomly trying out different solutions. So is this guessing or exploring? I don’t have the answer.

Maybe I should have listened more carefully in Software Engineering class?

4 comments

  1. Hey David,

    Something that I have learned in my time as a developer is to hack less and think more. Making random code changes definitely falls under the category of ‘hacking’. Yes, exploration is an important part of what we do – but it’s guided, scientific (if I may be so bold to use the term) exploration – not random hacking. Cheers,

    Kevin

    1. Hey Kevin,
      Of course I agree with you that we should “hack less and think more”. I think it is actually a problem that many developers do not think hard enough about a problem before implementing a solution for it.
      You’re right on.
      David

    2. From my experience – I do not agree about hack less (guess less). I myself used to try to make sense of things. But I got a problem with unknown technology – https://smartclient.com/ . Really hard to find information. And there is one good dev in my team, and managers said him to help me, by pair programming. He also did not know this technology. But I looked how is he solving it – just by trying randomly. Of course it is not complete random, but there is some logic where things might work if you do x. Like if you call some function which you do not know what it does but from the name it looks it might do. And he finds solutions that way quickly. Really sometimes it happens that trying thing which makes little sense works. Or you expect it should not work but it works. It might be working because of some other thing stopping working which you assumed it works. Yes exactly you might have asumptions about somehing working correctly, but since that something does not work correctly, it affect some other place where are you having a problem.
      Do not know if it is hard to understand what I mean, I do not have exact examples.

  2. Like for example with smartclient. Need to change color. He would probably check the list of function on the object which change color and try “guess” by its name which one it should be. I am used to google search “change button color in smartclient” for example. And since it is hard to get good results from google (I really remember having trouble changing stupid color of a button in this technology :D that I told to client lets postpone it and do not waste time on this, as it is not such important thing, realeased without changed color and changed it maybe after a month when the technology was more familiar).

    I also remember at 2015 had another team lead, and he solved some problem probably by guessing thing, also can’t remember what it was. But I remember clearly another colleague asking- how did you do that or smth like that. He says – experience. So probably from the experience you might even have guesses more correct even if you do not know exact thing – because you have seen soemthing similar maybe.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.