The Sandbox

One mistake that I see time and time again, even from experienced developers, is trying to model new ideas, new techniques, and/or new designs directly into a working codebase.

In my own experience, I’ve come to find this to be a bad approach.  In particular:

  1. I have to work around existing errors, bugs, and other conditions in the code.  When this happens, it becomes difficult to figure out what I’m doing wrong.  Is it the new code?  Did I introduce a new bug?
  2. I have to worry about breaking existing code.  Sure, I can make a branch to work in, but sometimes it’s not worth the effort to test some simple design ideas.  You never want to test out new concepts in working code without trying it in another environment first.
  3. It makes it hard for others to review the code.  Without checking it in and without creating a branch, it’s hard to share the code with your coworkers for review or for testing.  It’s too much to ask a coworker to download a branch to review a bit of code.  Also, if you’re working in the branch, you may end up checking in broken code if you need someone to help you fix a bug.

In our environment, we have a repository specifically for what I call “sandbox” code.  Basically, it consists of small standalone models of the more complex designs in the main code base.  I use the sandbox to test design ideas in a simplified environment with less noise and interference.  In addition, if I need to have a coworker review the design, I can check it into the sandbox and not worry about breaking the main trunk or integration branch.  In general, it’s just easier to work with; you’re not sifting through a huge project to find code, the projects load fast and compile fast, and it’s easy to test and run multiple dev-test cycles.

It’s true, sometimes, to properly model a scenario, I may have to build out a lot of the code, but I think it’s ultimately worth it to have a simplified environment to test and build in over time.  It makes it easier to think about the concept and design assumptions as well as to think about architecture…there’s just less moving pieces to think about in such a scenario.

Next time you get stuck looking at a complex piece of code or refactoring or designing around a tricky scenario, try simplifying pulling out the code into a sandbox project and model.  It’ll help give a new perspective on the problem and let you think about it in much simpler terms.

You may also like...

1 Response

  1. August 13, 2010

    […] empiricist."  I'm in Brooks' camp; I'd definitely consider myself an empiricist.  It's evident in my sandbox directory where hundreds of little experiments live that I use to rapidly iterate an idea (and isolate the […]