Programmers are a multi-faceted beast. We write instructions for the dumbest person to follow, but that's only the tip of the iceberg. We listen to users (a group who never knows what they want), we placate managers (a group who wants everything right now), and a host of other skills. But, most of all, we solve problems. brian_d_foy has posted a great discussion of how to solve problems, as have other monks. Here's mine, using as an example how I found and fixed a bug last night.

The problem: I am using DBIx::MyServer to simulate a MySQL database for a project at work. We need to be able to connect to it from Perl, Java, and C++. Perl and C++ were having no problems. Java, through JDBC, was just giving us fits. It didn't seem to be using the right protocol, which made no sense.

  1. If something doesn't make sense, you're not seeing something.

    I know next to nothing about Java or JDBC, but as the author of our MySQL emulator, I'm the one who has to solve it. I grab a copy of the Java code from SVN and try to run it. Of course, I immediately run into problems because the classpath is completely wrong.

  2. Replicate the bug in your environment.

    A few go-rounds with the Java developer and he finally gives me a line to run on my Mac. Yep, I see the problem.

  3. Find and ask an expert.

    This is where OSS really shines - I can go email the author of the module. He replies pretty quickly. Unfortunately, the reply is "I never tried JDBC. But, if you get me a minimal testcase, I'll take a look."

  4. Build a minimal testcase.

    Ah-ha! The next step is to build a minimal testcase. There are several reasons CPAN authors ask for them. The first is that it gives them the ability to replicate the problem. The second is (as we're about to see) the process of generating the minimal testcase can solve the problem.

    I start building the minimal testcase. The first thing was to remove all of our proprietary code. So, I created a Java class that creates a connection and reports success or failure, then exits. I also created a Perl script that creates a minimal DBIx::MyServer server (taken almost verbatim from the distro). It works.

  5. Start adding things to the minimal testcase until things break.

    Normally, people talk about removing stuff from the broken code till it starts workings. But, in this case, I had a working testcase, so I needed to add stuff till it breaks. I replaced the stock DBI call with the call to my emulator and it quickly broke.

  6. Verify what breaks.

    I took about 20 minutes to verify that the addition of that one line was what actually caused the breakage. Most people are so quick to say "Oh, I saw it once - that must be the problem!" and I'm just as bad as anyone. That time taken to truly verify the breaking piece was critical because it gave me another lead.

  7. Start drilling down to find the breaking bit.

    After some faffing about, I learned more about how MySQL negotiates a connection that I ever wanted to know. Namely that there's two protocols that are completely and utterly incompatible. The initial problem, if you recall, was that JDBC was using the older protocol even though DBIx::MyServer was requesting the newer one. JDBC, it turned out, apparently didn't care about what flags the server would set in its handshake. Instead, it preferred to rely on an arbitrary text string that my emulator wasn't setting properly. A quick hard-code and we're good.

  8. Assume that professionals know what they're doing, but don't count it as gospel.

    My JDBC connector came from MySQL itself. I'm sure they had a good reason for doing what they did, but it was certainly annoying. :-)

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

In reply to Solving problems and fixing bugs by dragonchild

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.