Great Developers Are Not Afraid to Experiment

As a moderator on the JavaRanch, I often come across people asking “What would happen if I executed the following code”. Many times the author of such posts can answer the question by copying and pasting his/her code into a Java main() method and running it. Some might chalk these posts up to being lazy, but, clearly, taking the time to write a post on a message board – often signing up as a member for the first time – takes some amount of effort as well. With that, I’m going to be go with the assumption developers avoid experimenting with code because they are scared or unsure of their own knowledge. Besides which, if it is a matter of laziness, there’s not much advice I can give except to say “Don’t be lazy”.

Experiment

Why is experimenting with code can be scary

In my experience as a teacher, development lead, and moderator I often come across developers who are unsure of their own knowledge. Often times they don’t fully understand what it is the code is doing and are afraid to experiment for fear it will either demonstrate their own personal weakness or harm the existing code. To them, I believe that experimenting is most crucial, if only because some of the doubts and questions that linger in their head can often be answered in an surprisingly short amount of time. If you are staring at a piece of code, puzzled by what you do not understand, take my advice: Step back and play 20 questions, ask yourself “What are questions I have about this code that can be answered with a simple yes/no?” then set up test code to answer each question. Once you have your answer, your doubt about the application should vanish, replaced by first-hand knowledge of what is going on. Keep in mind that sometimes these experiments lead to even more questions, but that’s good; it’s part of the learning process. In those cases, perform even more experiments on the code.

What is an experiment?

What constitutes an experiment? Oftentimes, it involves just writing a short line or two of code, then writing a logging statement, or, more commonly, if you don’t have a logger, a System.out.println() statement that displays the value of some variable or object. For example, if you don’t know why a method is behaving a certain way, add a dozen output statements throughout the code so you can follow two things: 1) the path the code is taking and 2) the value of the data throughout the code. Many times, you may be staring at a section of code, wondering why it’s not working, only to find out that section of code is never reached at run-time. Experimenting can be about changing values and recording the inputs, but sometimes its just about outputting where/what you think a process is doing.

Some people will recommend a debugger for experimentation but I’m not one of them. Aside from often being unwieldy and confusing to use, especially for beginners, sometimes running code through a debugger can affect what it outputs. For example, in a server environment, remote debuggers can be especially difficult to use. Services may have transaction timeouts of 30 seconds, and pausing the code in the debugger can cause an exception to be thrown before the method is complete. If you like using debuggers, more power to you, but as someone who has used both output statements via logging tools and debuggers, I greatly prefer the logging tools. Primarily, this is because the output statements give you more of a trial and error structure to work with: either a test succeeded, or it failed, and the output is all there in front of you.

Stand-alone Safe Experiments

The easiest and safest experiments are those you create that are completely separate from any other code. In terms of Java and Eclipse, this is akin to creating a new Workspace and a new Java Project to run the test code in. Every developer should have a temporary, throw-away workspace like this to perform low-level Java tests with. Simply create a file which in some way asks the question you want answered, and execute the program to evaluate the results.

Safe Experiments within Existing Code

Let’s say the code is highly framework dependent, such as often is the cases with J2EE and database-driven applications. For example, creating a temporary workspace to house your test case may be too cumbersome to implement. In such a case, you can run the experiment inside your existing code provided you are careful and follow some general guidelines:

  • If you are working with code that is backed by a repository, such as Subversion, CVS, ClearCase, etc, make sure your experimentation code does not get checked in or you may end up with applications such as this, this, or even the impossible (the last one). The DailyWTF has literally thousands of such cases. It is perfectly fine to experiment, just be careful to cleanup when you are done!
  • If you are working with code that is *not* backed by a repository, then install a developer repository! I cannot tell you enough the power and value of using a coding repository for all development work. In lieu of that, though, you should just make a copy of the project and/or workspace and experiment with the copy, keeping the original intact.
  • If you are working with code that connects to a database, make sure it’s not one other developers use. Making changes to a shared database as part of a test could affect other developers, so, if possible, you should have your own local copy of the database. This does not mean you should have a production database, but merely a copy of a QA or Development database

Final Thoughts
In my experience, one of the things that separates a great developer from the rest of the pack is that the great developer fully understands the code they are writing. When a bug appears (even great developers can cause bugs), this person often has a good idea where to look for the problem right away, and save valuable support time. Ultimately, if you ever find yourself mystified by your own code base, run some experiments and learn why things work the way they work. You’ll be a better developer for it!

7 thoughts on “Great Developers Are Not Afraid to Experiment

  1. That was always strange to me that people are not lazy to wait whole for the answer on forum but lazy to open ide and type a few lines.

  2. The people I find afraid to experiment, even in order to debug code, are the people that don’t know what they are doing, or even what they are looking for. These are the same people that are afraid to log in to the production database lest they mess something up, because, they don’t know what they are doing or the consequences of their actions.

    I would be the same way if I were tinkering with my car engine (I’m no mechanic). I might go on a website and ask what happens if I tighten the widget valve because I don’t know whether that might permanently break something because I have no clue as to the consequences of that action.

    Ditto with hooking up VCRs/DVRs and TVs, as the technologist in the family, you probably get asked questions all the time about hooking this cable to that socket and if that will work. People think that trying it will be the end of the world if they ‘cross the streams’ or something. Again, it’s all down to understanding the consequences and knowing the results you are looking for.

  3. Hi Andy,

    I agree with you, although logging into a production database can be extremely risky even if you know what you are doing! The sad part is, as developers, they should know what they are doing or have some idea of what they are looking for. As I mentioned in the post, these are the people for which experimenting is most crucial. They need to start broadening their understanding somewhere, in order to be more productive members of the team. From time to time, I’m sure everyone’s worked with the developer who doesn’t understand anything and who no one turns to for resolving mission critical problems. In fact, in my experience they usually get promoted so as they can do less harm to the code šŸ˜‰

    -Scott

  4. I often mess with people’s heads when they ask me “What would happen if I …” by responding, “That would be bad.”

    Of course, then I proceed to say, “Cool! Let’s try it out.”

    I’m a fun person to work with.

  5. You should checkout the scrapbook in Eclipse.
    Great for experimenting with short fragments of Code.

  6. That was always strange to me that people are not lazy to wait whole for the answer on forum but lazy to open ide and type a few lines.

Leave a Reply

Your email address will not be published. Required fields are marked *