I had a friend in college who programmed something that worked the first time, that was pretty amazing. But as for me, I just fire up the debugger as soon as I finally get whatever I'm working on to compile - saves me time (kidding of course, I sometimes hold out a little bit of hope or use a lot of premeditated debug strings).

What's the best way to approach the Dijkstrain ideal for our programs?


Is this just some sort of pie-in-the-sky old fools quest for greatness applicable only to finite tasks that no one should hope for in our professional lives because programming is just too complex?

  • 2
    <?php echo 'hello world'; ?> – Craige Jan 6 '11 at 15:24
  • 4
    Is there anything you can add to this question to make it less of a "yes/no" one? I just tried to write an answer that went beyond a simple "yes" and I feel like I ended up with mostly pointless filler. – Adam Lear Jan 6 '11 at 15:28
  • @anna any better? – Peter Turner Jan 6 '11 at 15:34

11 Answers 11


Make small components with their own standalone test harnesses that demonstrate that each piece works. Getting a program to work the first time is just a question of throwing together components (I mean "pieces," I'm not talking about some particular component technology) that already work.

| improve this answer | |
  • Wow, I don't even know why I asked this question. I always forget about testing - probably because I've never done it... – Peter Turner Jan 6 '11 at 16:29
  • 1
    I hope you are kidding. – Pemdas Jan 6 '11 at 16:38
  • 3
    @Peter Turner, you do it all the time, but you do it late. This makes it harder. Programming is more about testing than writing code, in a sense. It's just a question of when and how you test. – Dan Rosenstark Jan 6 '11 at 16:39
  • Note that testing will only show you if the underlying code works, if there is a flaw in the overall architecture of the application you might not catch it until much father down the road. – rjzii Jan 7 '11 at 23:29

"I just fire up the debugger as soon as I finally get whatever I'm working on to compile - saves me time." This scares me in so many ways.

Yes, I have frequently with small modules. Complete features or subsystem are really hard to get right the first time.

"Is this just some sort of pie-in-the-sky old fools quest for greatness applicable only to finite tasks that no one should hope for in our professional lives because programming is just too complex"

Actually, I think this should ALWAYS be your primary goal when writing software. Too many programmers abuse the fact that is rather easy to just change a piece of code and recompile. This method should NOT be your primary way solving software problems. Everyone makes mistake, but if you are going back into a module more than say 3 time to fix something then you either have a design flaw or you have no idea what the code your writing is supposed to do.

There is some leeway if your learning a new technology.

| improve this answer | |
  • 2
    Get the small pieces right, then build from there. – Alex Feinman Jan 6 '11 at 15:28
  • @Alex That is not bad methodology, but integration bugs are difficult to predict sometimes. – Pemdas Jan 6 '11 at 15:31
  • 1
    I disagree, in contrast the desire to write the "perfect" code from the start or "avoiding all errors" is usually a major contributor to programmer inproductivity and case of misplaced programmer "pride". Get something working quickly and rapidly iterate is almost always faster for non-trivial pieces of code. – Homde Jan 6 '11 at 15:54
  • 1
    I differentiate between "perfect" code and code that works. It is faster to write code that work than to write code that has a bunch of error's and requires time to locate and fix them. – Pemdas Jan 6 '11 at 16:03
  • We can agree on that, however which is faster: writing something, avoiding trivial errors, and then running it to ensure that it works. Or writing something and then meticulously go through it manually to see if it works before then also have to run it and check that it works. – Homde Jan 6 '11 at 16:15

Yes, there have been numerous university assignments and app features at work that just worked the first time I tried. It doesn't happen every time, but it does happen.

There's not much to it. It just came down to having a good handle on what I was doing and not rushing the implementation. Being very familiar with other parts of the program also helped since I wasn't as susceptible to being tripped up by assumptions about someone else's code.

| improve this answer | |

Of course I have, the very first one!

10 print "mattias"
20 goto 10

But in all seriousness, why would you want to do? Programming is an incremential process, doing it in one stroke is like eating a melon in one gulp.

| improve this answer | |
  • I'd imagine if you were one of those dudes who likes to write their programs down in a notebook then you might be apt to hope it works the first time. – Peter Turner Jan 6 '11 at 15:27
  • 1
    writing code on paper is like dancing about architecture :) – Homde Jan 6 '11 at 15:32

Look at Test Driven Development TDD. By it's nature of writing a test before code it never works the first time. :-)

TDD is probably the best framework for writing quality reliable code. It has the best test coverage and by it's design reduces the amount of "what if" code. Since you have to write a test before you write code it also IMO reduces the amount of extra features that a programmer things are "cool", since the developer actually has to create a full test scenario around that cool, but unnecessary feature.

| improve this answer | |
  • Wow, I'm amazed, only 1 answer mentioning TDD, I thought we were all doing this by now? – BlackICE Jan 6 '11 at 18:32
  • What if there is a bug in your test? – Pemdas Jan 6 '11 at 22:47

I've frequently written non-trivial programs (~200 LOC or so), ran them, and they worked the first time. As others have mentioned, it helps to write in a modular fashion so you can have confidence that each piece will work as intended.

Writing modular programs requires planning. I spend probably about half of my cognitive effort up front just thinking about the problem. It helps, too, that I've been programming for over 30 years; many common programming techniques have become patterns and I write them without much thought.

I do my best holes-in-one with a language that doesn't stand in my way: Perl. Its flexible syntax lets me get my ideas down quickly without a lot of fuss. Weak, dynamic types mean I don't have to worry about declaring variables before I use them, nor do I have to concern myself about memory leaks and right-sizing data structures. They just work and I can get down to business.

A common pattern is the one the churn through a text file, ignoring comments, trimming blanks, and discarding blank lines. The rest gets put into an array.

while (<>)
    s/#.*$//;          # Trim comments
    s/^\s+|\s+$//g;    # Trim blanks
    next if (/^$/);    # Discard blank lines
    push @lines, $_;
| improve this answer | |

For me it typically happens with single components of fairly simple complexity. I think it is a good exercise to do once in a while as it forces you to fully think through the "flow" of your code rather than the tweak and compile method. It also makes you faster in the long term because you will eventually get better at writing clean code from the outset and thus spend less time fixing things. If you constantly depend on the compiler you will always have the overhead associated with "tweak/compile".

| improve this answer | |

Constant debugging to see if the code you just wrote works correctly tends to waste time in my opinion. It can be necessary occasionally, but if the code isn't simple enough to think through it, I find it more productive to write automated tests. Then, you can just run/modify them as you code and see if your assertions are true.

| improve this answer | |

Take a look at the "Writing Correct Programs" chapter of "Programming Pearls" by Jon Bentley, particularly section 4.2. I personally can't imagine going to this level of rigor on every single thing I write, but I think it's a good example of the type of thinking you need to do to get it right the first time.

| improve this answer | |

When I'm working in Smalltalk I do almost all my development in the debugger.

I write a test that fails, demonstrating the correct behaviour of the yet-to-be-written code, and hit the Go button on the test runner. The test fails. (If it doesn't fail, I first find out why!) I click the test, bringing up the debugger. I step through to wherever the problem is, I type whatever I need to do to make the test pass - define a class, write a method, whatever - and then hit "proceed". Hopefully, the test now passes. If it doesn't I roll back the call stack to find out where I made the mistake, and continue executing the test.

After I'm finished, I'll usually run the entire suite, just to make sure I didn't break anything.

| improve this answer | |

For me, whatever I write just works first time, isn't that what happens to everyone else?

In all seriousness, programming is like typing with your eyes closed, the more you write the more likely you are to make a mistake and the longer it will take to find it. If you take special care, you may be able to write a fair deal, but if you can't be sure it's right then what's the point?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.