Program Your Way Out

''There are things you don't program your way out of. Operating systems, distributed deadlock, mutual exclusion, distributed failure recovery, type correctness, ... . For these problems, you need to sit down and think, prove, imagine, use math, etc. There are problems where you NeedToHaveCertainty you are right before you start typing... also, there are more problems you can program your way out of. --AlistairCockburn

See, for example, ExtremeProgrammingChallengeFourteen.''

Yes, there may be things you don't program your way out of. And yes yes yes, there are more problems you can program your way out of.

There are almost no programming problems you can't learn about, very quickly, by programming. So many times I've designed, drawn pictures, pushed ideas around in my head, on the whiteboard, with pals. And so many times when it came time to code it up, the code didn't want to be quite the way the dreaming had gone.

Oh, it was close, and the dreaming had value - it pointed the way. But the code has its own story about how objects want to relate, and the code must be heard.

Sometimes you just can't get a clue what to do without your dreams, and, so, you must dream. But more times than not you can sit down with Ray and say "I'm worried about X", and ten minutes later sit down with the code and see where X will go if and when you really need it. Then you can stub it and move on.

And moving on is where the real benefit lies, for customer and developer. Customer loves it when stuff gets done. And developer learns real stuff fastest by doing real stuff. --RonJeffries

Could it be that there is some amount of personality-type variation going on here? For me, the highly-interactive style of programming/debugging just doesn't work as well. I do it in my head, on a walk, on paper, on the whiteboard, with pals... and when I'm done and I grok the design, then I go to a keyboard, and spew out the code pretty much directly in the form it will stay in. By contrast, when I sit down early and just start coding, I botch it much more often. (In the first case I may make minor typos, typically caught by the compiler; in the latter I may make design mistakes).

Similarly, for me, with debugging. While I appreciate a post-mortem stack trace etc., when I'm looking to track down aberrant behavior I'm much more successful observing the behavior/logs(UseTracing), reading the code, and reasoning it out (DebuggingAndTheScientificMethod) than stepping through a debugger, using breakpoints, and the like.

In both of these I've done it both ways, and in both I'd say I'm pretty much as fast and effective as anyone I know of. I'm not advocating that others work this way; I'm not in that business. I think some others have indicated that they do (WilliamGrosso recently) and I offer this as data point. --JimPerry

Don't know how personality type affects this, and I'd like to. I come from the drawing and grokking school myself. I forced myself to do it XP style because my mission was to know and teach XP, not my own theories. I learned, after 30+ years of being really good at this stuff, that the XP way worked better for me. Weird and wonderful. I still miss the diagrams, though. I just go faster and do better by keeping things more concrete. --RonJeffries

Well, I can't say I'm much into drawing, beyond the simplest spatial markers. But I do find the code comes out the way the "dreaming" goes, so that's OK: it's not that I like doing it one way over another, just what works for me. I find there are lots of software problems that I learn about much more quickly and thoroughly through other means than programming. The sort Alistair mentioned, for instance. (Of course one can program separate simulations or visualizations, which is just one way of "sitting down and thinking", so I don't think that's what was meant by "program your way out"). --JimPerry

It may be tool-dependant. I found debuggers unusable for many years. The early ones couldn't cope with the size of a whole program full of debug info, so you had to selectively enable debug info for the parts you were interested in and recompile and relink. Even without that problem, single-stepping through reams of code to get the point which went wrong seemed to waste masses of time. I'd spend an afternoon and not feel I'd got anywhere. I did eventually find a tool I could get on with (Microsoft VC++ as it happens), and I do use a debugger when I return to that environment. But I'm still happy to drop it in favour of UseTracing if it's not available, and I rarely use fancy features like editing variables or conditional breaks. I try, but it takes so long to learn them and I forget it all the next week.

I think the type systems of Java and C++ can really get in the way when you are MakingItUpAsYouGoAlong?. You start writing a new routine, you immediately have to ask yourself, "What type should this argument be?" It might be an existing class or a new one. You might want the subclass or a superclass might do. The language invites you to think ahead so that you can make a decision. "Doctor, it hurts when I do this." -- DaveHarris

With an existing program, there are two kinds of ProgramYourWayOut, a good one and a bad one.

If your program works, is well-factored, and has lots of tests, you can ProgramYourWayOut of almost anything, quickly. You can usually start from a stable point (because it works now), change the system locally (because it's well-factored), and know you're done (because you have the tests). Since you're in there for a reason, and since the program doesn't satisfy in some way, you need to think what to do. Not for days or weeks, one would hope. But do think as you go along, otherwise your head will shrink.

I sometimes call the bad one DebuggingTheProgramIntoExistence?. This is the situation of a program with "just one more bug". Often, in the problems Alistair mentions at the top of the page, it's one bug, moving around from place to place. I've seen a month go into chasing that last bug in a relatively small program. The only approach I know to this one is to rip out the offending code and start over, preferably with a new person, certainly with a new approach. One is tempted, with Alistair, to recommend a little more thinking and a little less coding.