Programming by guessing/hoping

Question

The Visual Studio IDE gives the developer almost instant feedback as to whether or not a block of code is correct or a program runs correctly. This usually leads to programming by guessing... The programmer thinks to themselves, "Maybe the intellisense will tell me it's right if I do it like this..." or "Maybe if I change this constant to that or change this loop and click play it'll work..."

I usually fall into this mode when I'm tired or have my mind on other issues (i.e. just don't care ATM). It's sometimes hard to break out of this "mode of operation" because you want to get something done but at the same time you aren't thinking about what you're doing. It's a viscous cycle.

What are some causes of this type of programming and how do you recognize (i.e. catch yourself) when you've fallen into this trap and correct it? Or perhaps a better question, how do you prevent it?

(I'm referring more to writing new code or getting a block of code to work than debugging existing code, although it could apply to debugging existing code too.)

Think instant gratification.

Answer 1

The first rule of debugging is to thoroughly understand the bug before trying to fix it. In other words, don't even think about how to fix it until you totally understand exactly what is hapenning to cause it. The debugger is your friend there... just step through and you'll see what's going on. If you follow this rule, you won't get into the "hacking" mode that you describe, because you won't be trying to fix the bug yet.

By following this advice, you will be much more likely to really fix the bug, plus it may suggest that there are other places in the code with a similar bug that you could now fix. Plus it will be a general learning experience. It's a very valuable way to work.

Answer 2

As you surmise, it can be a product of being tired. Or lazy. Or ignorant. It's not much different than driving a car while sleepy in many respects.

It's very dangerous because the tired/lazy/ignorant programmer here cannot tell the difference between a successful, correct program and one that happens to have produced successful or correct result once.

The best advice is to stop when you're realizing you're in this situation. Get sleep, Eat. Enlist the help of a coworker.

Or if it's from ignorance, then read up on whatever you're working on for better ideas and practices.

Answer 3

There is also significant academic research on these problems.

For example, a recent study by Latoza demonstrated that users debugging other people's code tend to second-guess the intentions of the original author's intentions and build a personal mental model of how the system may work, against which they make changes. A significant issue here is the lack of understanding but also of the ripple effects of changes.

My own study revealed that developers tend to optimistically guess things about the services the code they are examining/writing invokes, rather than explore their documentation or source code. Unfortunately, guesses don't always work; I had some proposed tool for dealing with that.

Finally, Ko came up with a framework for debugging called WhyLine, that lets you ask why something happened by focusing on that manifestation (e.g., why did this line appear in blue). Unfortunately, his tool is relatively limited to UI toolkits right now.

Answer 4

Pair programming. Explain the code and the bug to someone else.

Answer 5

You need to think more about the design and what you plan on doing and how to do it before you start banging on the keys. Draw some whiteboard diagrams or think about the problem a little bit before writing code.

Answer 6

I had a boss that did this. Most of his software did not end well. You need to know why something works. Not just if it works.

Answer 7

The reasons I have so far

• Tiredness
• Laziness
• Ignorance
• Lack of understanding (problem domain knowledge)
• In a rush/hurry
• Optimism

Answer 8

If you use TDD you won't fall into this trap because you'll need to think about what you want the code to do and write a test to check before you write the code. Thinking about the problem enough to know how to test it is usually sufficient to give you at least an outline (if not the actual code) of how to implement it. The most important thing, though, is that it makes you think first. You have to think about what it is you want to do, what could go wrong (and how you would test for it), and when do you know when you've done enough.

Answer 9

I see this sort of behavior very often, and it used to bother me. Then I realized that it's just one way of learning how to program. Whether it's good or bad depends on who is doing it and in what environment (educational vs. professional).

Relying on Intellisense to tell you if you got the syntax right is no worse than letting the compiler tell you (in fact, it's exactly the same thing). I've instructed hundreds of students to not be afraid of that "bad" beeping sound the IDE (BlueJ, at my former school) makes when they compile code that has a mistake in it. That's the fastest way to teach them debugging skills, by teaching them that mistakes are common.

In a professional environment, however, this sort of thing still bothers me. A developer should know how to use his tools, but he should also know the syntax of his language. The compiler shouldn't be telling you if your program is correct or not, tests should.

Answer 10

Um, how about Optimism? I think that is the true reason 50%+ of programmers do it, it's not because all programmers are Lazy bums...

Answer 11

As for avoiding this burned out zombie-coder state, I believe my answer to this question fits.

The questions are somewhat different, but they converge when you get past the symptom of feeling out of focus and take a look at root causes.

Answer 12

Sounds like the phenomenon of "programming by coincidence", to me. The Pragmatic Programmer, an excellent book, recommends against this practice and offers some useful insight into how to recognise and avoid it.

Answer 13

What causes "programming by guessing"? Temptation. Human nature.

How to avoid? Planning, and working with somebody else.

See Read Before Running.