The Boy scout Rule (or Ignorance vs. Apathy)

Scrum or no Scrum, the quality of your product depends of your developers.

There is an old joke about a poll taken once in the US, 

One of the questions was - which is worst, Ignorance or Apathy?

And the most popular answer was - I don't know and I don't care.

 

 

So which is worst?

I'd argue for the second.

In fact, I'd go as far as saying that ignorance is sometimes a blessing... 

(Well, not exactly, but the more someone thinks of himself as a professional, the less likely he (*) is to be one.) 

- I had a member in my team introduce himself last week, and what he said struck me.
     he said "I don't think I am a good developer".

- How likely do you think he is to learn new stuff from his peers?
     without the fear of appearing unprofessional, it is sky-high!

On the other hand, let's look at Apathy.
Imagine you have a big pile of tangled code, and the team members, when they have to touch it, do the minimum necessary to fix it...

- meaning 

• Understand the problem, set up the system and try to reproduce it (three hours).
• Find the relevant part of the code (two hours).
• Perform a surgical cut and paste (**) operation (3 minutes), copying a piece of code that includes:
• a try-catch-finally block
• a check for null condition
• a strange number representing the system state, something like
                       if (item.getState()==15) ...
• a logger code like
                       this.logger.debug(
                   "myMethod (15) param1="
                   + param1);    
• Change the copied code, setting the state in it to 16, change the log - setting the state to 16 and the method name to myOtherMethod (2 minute).
• Test the fix. (20 minutes).
• change and fix again (wash and rinse) until it works (say twice more = 1 hour).
• Perhaps deploy the fix on the pre-production system for the QA to test it, and than on the production (two hours), and perhaps some more wash-and rinsing.

The whole process took about half a day if we are lucky (up to two bug a day, not bad!).

BUT, there are a few questions that really bother me:

1. What are the chances the bug was not fixed properly? (say the log still points to the old method...) 
2. What are the chances this code didn't say its last words? (meaning there are other bugs lurking to pop up)
3. What are the chances the same developer will be assigned to the next bug?
4. If he does:
1. What are the chances he will bitch (***) about the fact it is always him stuck with this lousy code?
2. How much faster will he fix the code next time?
5. If he doesn't, and a new developer will handle the bug:
1. What are the chances he will hate the old developer?
2. How much faster will he fix the code next time?

I'd say the answers are:

1. 15%
2. 80%
3. 80% (since now he is considered the "expert")
4. 100% , and a 50% improvement on the actual cut and paste operation, bringing the whole fix to a 20% improvement.
5. 110%, and he will show a 5% decrease in fix time, since the code is 5% more complicated.

And this is where the Apathy factor comes to play!

The developer handling the bug looked at the code as it was covered by an SEP field (as the good book says) 

What if the developer actually took responsibility of the code?

• Try to understand the whole functionality.
• Clean the clutter (is 30% of the code just error handling and logs?, is there an enum saying 15 means "Pending-state", and 16 means "Eruption-state"?, is the logging necessary? is the function/ class too big to swallow at one chunk and can be divided?, perhaps even some code can be reused?)
• And than test, change, fix, etc...

I'd argue the results would be:

• The code touching phase took about 20 times longer (2 hours instead of 5 minutes) and the whole cycle 2 to 3 times longer.
• The developer merited a feeling of satisfaction at the end of the day. (mood increase - 50%)
• Perhaps even a few more bugs were fixed at the process, hence - chances of another bug are lower.  (50%)
• Next time
• The old developer would not bitch that much (50%)
• The new developer would not bitch that much as well. (30%)
• The new developer may be even encouraged to fix some more things, and show them to the old one.
• If you do the math, the process starts paying for itself in 2-3 months, resulting in:
• Fewer bugs.
• Faster response time to new bugs.
• Happier developers.
• A better team-spirit.

And this is the golden Uncle-Bob's boy-scout rule, get it to your team, and you are on your way out of the mess:

Always leave the campground cleaner than you found it

Notes: 

(*) I know I refer to all developers in this post as a "he", there are two reasons 

      - They are a 'he' 93.6% of the time (****) 

      - The 6.4% remaining develop-hers are more likely to follow the boy(eh-voila! why not girl?!)-scout rule.

(**) There are some software dictatorships where the punishment for someone caught cut-n-pasting is a decapitation of the paste finger (see the term 'Yubitzume') , I think it is plainly cruel (and hurts the piano playing capabilities), a simple keyboard hack connecting two live electricity wires to the ctrl and 'v' keys, giving a shock when the circuit is closed seems good enough.

(***) Developer's Bitching is scientifically quantified by WTF/H units (though European and US units differ due to the average working-hours/day and the lunch-break duration).

(****) All measurements mentioned in this post are based on years of experience, as gathered throughout the globe in the past 179 year. personal measurements may vary.

Till nextime! 

The Scrum'em Bear.