A request for simple example programs

I got a worried call from support this morning. In essence a customer had provided his entire application solution as an example program to reproduce a bug and they wanted a nice way (British, with a cup of tea and a ginger biscuit?) to turn his offer down and ask him to please isolate the issue in a small project.

I'm sure I'm preaching to the choir here, but it seems to me that part of the job of a programmer is to debug. We never write perfect code every time (if you do, I'll gladly fly out and pair with you to see how you do it). We always make mistakes, and I'd vouch that part of the fun of programming is seeing a bug and isolating it and slapping one's forehead in a duh! moment and then fixing it.  I'll admit my particular programming blindspot is conditionals with multiple boolean expressions (one reason I like Refactor! Pro's ability to break conditionals apart and merge them back together: I can "see" that a simple boolean expression is correct).

Also programming these days is very different from when I were a lad (cue stories about shoeboxes in the middle of the road, travel to/from school being uphill both ways in the snow, etc). No matter what programs we write we are relying on external code, be it the operating system, database engines, run-time libraries, controls, frameworks, etc and in general a lot of effort has gone into that external code to test it and make sure it works in as many ways as the designers could foresee.

In the vast majority of cases where there is a bug in our controls, we find that it can be reproduced in a small project. Ach, put it more generally: in the vast majority of cases where there's a bug in some external code, you'll find it can be reproduced in a small project. But in some majority of cases where you see a bug, you'll find it in your own code as you build that small project.

With a small example project, it is much easier for us to verify that the code that calls ours is valid, that the way our controls are being used is as recommended, and so we can concentrate our resources on the problem area. It takes us less time to read and understand the code that isn't ours, to see that the bug isn't in that. Sometimes the bug may be from using the control in a way we hadn't foreseen and we can then more easily suggest a workaround, investigate a design/implementation change, or just reinforce in the documentation to do things the recommended way.

By providing us with a large project, it's virtually impossible for us to isolate the problem in our code. Well, not impossible per se, but more long-winded and resource-intensive. Given the choice between finding a bug in a small example versus a complete project in development, which would you rather investigate first? Uh huh, me too: the small one. There's more chance of a quick positive hit, of sending the customer away with the warm fuzzies, of getting that feeling of satisfaction of successfully completing a debugging session. Heck, given the choice between 10 small examples that repro different bugs and a large project that shows one, I'd rather debug the 10 small examples, bam, bam, bam.

The other problem with a large project is that the probability of the bug being in our code reduces dramatically. In effect, we then become the debuggers of your large project and in doing so we naturally don't have as much time or resources for other customers.

So, please don't get offended if, having received a large project, we ask for a small project that reproduces the problem. With a small program, we'll be able to confirm the bug faster, queue it up for fixing faster, get the workaround or the fix to you (and everyone else) faster. Everyone wins. With a large one, it clogs up the system. Help us help you get perfect code.

Free DevExpress Products - Get Your Copy Today