16 Jan

Marines vs. Boy Scouts

What I’m talking about here are two styles of development.  And this isn’t an “us vs. them”, this is a “me, myself, I and all of yall”.  We all use both of these patterns in developing code, and will even switch patterns in the same product from feature to feature.  Anyway, here are your definitions:

Boy Scout:  “Leave thing better than you found them”

Marine: “Get in, get out, leave no trace behind.”

Sounds simple right?  So where does this apply?  Starting with the Marine.  I more frequently use this when dealing with someone else’s code, or something I just need to hack out real quick.  Often you don’t plan on maintaining the code, probably won’t own it, or you are just following the given pattern that is already established in the code – no matter how bad it is.  Typically you are just trying to get in and out without your name being attached.  You will also hear the adage “if it ain’t broke don’t fix it” commonly among staunch practitioners.  You can maintain code like this for a while, but if used too often it will come back to haunt you.  Each feature becomes harder to add, unexpected behaviors crop up, and performance problems creep in.

Now the Boy Scout.  You are adding a feature and find a mess.  The code is working, but is very unmaintainable.  Instead of just adding your feature, you tear the code apart and refactor the daylights out of the code.  Once complete and all is in order, then you add your feature.  It took you three times longer than expected to get the feature added, but you might be saving time in the future, assuming you will need to work with the code again.  Unfortunately, it is also very possible to get over your head in a hurry.  It would be great to have some unit tests to fall back on in this situation … but I haven’t seen that yet.  A good thing to do before you start a boy scout trip is to warn people where you are going, how long you’ll be there, and when to send for help.


Now, lets not get too far ahead of ourselves here, there is absolutely a time and place for each approach.  It should also not be too hard to understand which is correct – but I’ll give some guidance anyway.  Here are some points.

  1. If the code in question will be rarely used by one guy in the basement and doesn’t own a gun, marine mission till the cows come home.
  2. If the code is non-critical, proof of concept, spike, or the like and can get everything done in less than 4 hours, marine mission.
  3. If you are a consultant brought in to add one feature and supplement a team with a strange style but is currently working for them, marine mission.  Otherwise you will be “that guy”, meaning the one that didn’t fit in.  Sometime it pays to just go with the flow.
  4. If the code is critical path, a essential web page seen by every customer you have: Boy Scout, and continue to Boy Scout.
  5. If the code is already a buggy mess, the customers hate you, your product, and your car – role up your sleeves and get to work.

End result, either approach can get you in trouble when used inappropriately.  You need sound judgment to figure this out.  But then again, if software development was easy everyone would do it.

4 thoughts on “Marines vs. Boy Scouts

  1. I hadn’t heard of the “marine” style before — I like that term.

    I have heard of “Boy Scout” before, but I generally apply it with the idea of “leave things *a little* better than you found them.”  So, I think there is a third option that lies between exacerbating the mess and “tear the code apart and refactor the daylights out of the code.”  

    So, I agree with the idea that one should exercise caution before embarking on a serious refactoring of a mess, but I don’t think that you have to be a “marine” while you’re doing it.

  2. Same here, I like the ‘Marine’ vs ‘Boy Scout’ analogy, though it seems US Marines never just leave once they have established a base abroad. Special Ops would be closer.
    I do not quite agree with your ‘Boy Scout’ behavior as well. Going in and tearing apart the code to refactor it. The Boy Scout Rule is indeed leave it “a little” better than you found it. Each time the code is visited, you improve it a little. Cleaning up as you go. 
    I think you are on to something as there are different ‘strategies and tactics’ one must be able to employ. I believe sometimes we also act like a member of a bomb squad, very cautiously going in, trying to find that one line of code that once in a while sets off the whole system to go Bang!

  3. Love the analogy! I agree both approaches can be good or bad, depending on circumstances.

  4. +1 for the analogy! I guess the boy scout term is quite known among developers, but the marine was new to me. 

Comments are closed.