Thursday, September 29, 2011

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:



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.

Monday, September 26, 2011

The SCRUM Sales pitches

OK, you guessed it, it was SCRUM.

Anyway, a consultant came and started coaching us.
Now, this was the beginning of the fun part, see, up to now no one ever treated a professional training as a coaching.
I must admit I got hooked quite fast, and if I recall the pitches I liked were:

The short blanket pitch
All our life we try to hold a too-short blanket to cover the triangle of features-time-quality.
Since management is great at demanding features and insists on delivery on time, quality suffers, (which effects the time of delivery finally as well...), so let's try another approach: to keep high quality, and deliver on time, let's loosen up the requirements! (we can't define the full requirements for a two year project anyway...)

The human factor pitch
OK, as difficult as it to admit, we are not robots, and we make mistakes, in estimations, in choices, and marketing makes mistakes in requirements. so let's take in small chunks.

The 'It's a give and take relationship' pitch
- We are responsible to make the estimates of the required development, and no one has the right to tell us we are over-estimating.
- We engage to deliver working software in a month.
- In return - requirements are frozen for a month.

The fun pitch
- Thou shall not stay late due to overload (unless you miss-planned), and thou shall learn your lesson if you do.
- The planning is done with post-its, all the development participates. lots of noise. lots of coffee.
- There is a five minute daily meeting, called a standup, we actually stand (and no coffee allowed), so as not to tempt us to babble in it.
- Every end of month (end of Sprint) besides a demo there are:
  - a retrospective; let's try to see what we learned from the way the sprint ran.
  - a celebration: hey! we spent a good effort (even if we failed miserably), let's have an hour of fun!

Given such strong sales pitches, seeing only benefits, and given the fact we had no say in it, we said yes.

And so the story began...

Till nextime!

The Scrum'em Bear.

Saturday, September 24, 2011

Welcome aboard!

If you read this post thus far, two questions probably came to mind:
1. Who?
2. What?
3. Why (well, it's a third one, but it came anyway...)

I'll try to answer both (or troth) with this post...

Hop right in.

Age of darkness:

- For more years that I can count I’ve been doing different variations of the same role, which is walking the fine line between developing software and managing a team of software developers. 
and for more years than I care to admit the dynamics of work was a bi-polar one, hence -

- periods of nothing clear to do, and a big project being managed somewhere. (dunk, write some sample code that will maybe be useful some day, tetris, minesweep, coffee-breaks)
- periods of panic: either the deadline is too close (have we implemented all that is needed? why doesn't this work?, the ship is 'bout to hit the fan..) or tons of support cases piling up.

At both cases, the feeling was that we are not doing what we should, someone up there must have a clearer idea of how things should run, but we are expected to swing it.

Gantt-charts were a nightmare to use, since dependencies were always moving and reappearing, and ms-project … well.. don’t get me started...



Let there b lite!
And then at one place I worked a decision was made to start developing in another fashion, there were rumours that the development procedures would change, and as someone who hates bureaucracy all I had to say was, oh shift.. another document set to read, more forms to fill, and just more mis-communication between the top floor (BTW - why does management always have the top floor?!) and the people really doing the work.


But you know what? this time the idea was actually a good one! 
the direction was how to increase communication, how to not do redundant work, how to have good close visibility of what is required, and how to (as the good book said on the back) NOT PANIC!

And the name of this new thing was: …
.
.
.
I’ll tell you next time.
(but I can hint is starts with an ‘S’ and end with a 'CRUM')

till nextime

the Scrum.m.bear