Saturday, September 5, 2015

Mob Programming and Trivial problems

Whenever I hear about Mob Programming people always talk about how great it is for the hard problems.

But let’s explore a fictional example of some trivial work because I believe this is where things really start to shine.

At the Institute for Boring  & Monotonous work (IBMw) there was a team of 6 developers that whose large code base had all become destroyed due to a large disk crash. Fortunately, all of the code had been printed out before the destruction, but it had to be re-typed in. The estimated work was going to take the 6 programmers 8 months. It doesn’t get more trivial than this, IBMw was really living up to its name.

Nonetheless, Mob Programming was the new buzzword so this team said, “why not try it out?”. Here’s what happened.

Day 1 (Many eyes):

The team started typing in the pages. They quickly started to arrange focus so that a couple would be manning the physical paper and couple eying the projector to keep everything in tack. They were definitely slower with only one person typing, but they also realized that they weren’t making any typos. This is very important as the code had to be perfect or the whole system wouldn’t fit together again.

At the end of the day they retrospected as it is recommended for mobs. They came up with 2 big findings.
1)   quality is up
2)   some people can’t type
Idea for improvement: “Let’s spend 20 minutes tomorrow working on typing”

Day 2 (Countable Improvements)

The mob downloaded a typing tutor and started the day working on keyboarding. It didn’t make a huge difference, but  it was nice to know the slower members were working on it. Made it easier to be patient with them during the day.

But one part of the day went a bit off, something went wrong with the typing and they had to debug a bit. As they did someone counted the number of words. Paper: 304 Computer:303. Damn. Eventually they found the missing part.

At the daily retrospective, a couple of post-its showed up in the positive side with ‘word count helped debugging’

Day 3 (Checks)

They continued with the typing practice in the morning. A little progress but not much, some members had moved from 15 words a minute to 16.

The word count was really helpful so they started doing that with each part. It usually wasn’t wrong but there was something reassuring in knowing that the computer matched the paper so they kept doing it. It was extra helpful when it didn’t match. However programmers can be extra lazy and  someone complained that it sucked that they had to count the words on the computer as well. Everyone agreed, and then they suggested they write a small programmer to count the words for them. Easy enough; No more manual counting of the words.

The retrospective had a lot of sticky notes with “auto counter” written on them in the what went well section.

Day 4 ( Auto-enhancement)

It was great having the ability to know the word count when they matched up, but still a bit hard figuring out where the missing part was when it didn’t. So they would add improvements to the AutoCounter to allow for easier debugging. It was interesting to note that some of the best ideas came from the most frustrated people. Team members that never would have been able to implement those ideas on their own.

At one point, they just couldn’t get past one section.
“I know something is wrong”
“But the word count is the same, even the character count is the same”
“but look at it, it doesn’t feel the same”
“yes, but, oh the printed font is different. That’s why it feels different”

The retrospective had a bunch of “font caused frustration” in the negative side.

End of Week 1 (double check)

After typing practice the first thing suggested was to change the font to match the paper. This made the day a lot easier. They would hold the paper up and do a quick sight match. Still programmers are nothing it not lazy. The retrospective included “arm tired from holding up paper”

Week 2 (Seeing words)

The second week seem much easier than the 1st. They brought in a second projector to overlay the paper so it was even easier to see the differences, but this also got them thinking why do we need to count the photo? It was too hard to program up something to read the printouts, but it wasn't to hard to detect the words. They could figure out the boxes around words. It wasn't great but it helped.  Now WordCounter could also help a bit with the physical world.

They were still doing typing, but it wasn't helping much the slowest was up to 22 words per minute on Friday from 21 words per minute Thursday.

Oh, someone was sick and out for 2 days, didn’t really matter.

Week 3 (Word counter sees letters and bugs)

The team was able to get the boxes from words to letters. This really improved the speed of the checking and we are almost completely sure there are no bugs going in from typing now. Of course there were some bugs in the original code. We got in one argument over a weird compiler setting that has different effects on how a struct would end up in assembly code. It was rather goofy, but we added setting to Word Counter to notify us if this shows up again.

Typing still isn’t helping much, our slowest is barely making 26 words per minute.

Week 4 (Splitting Word Counter)

The team split up the Word Counter into a separate program that detects the patterns of common bugs. We only have 3 patterns so far but its pretty neat and we are removing some bad code because of it. We were also able to run this over the previous code so fixed some stuff from the first 3 weeks.

We also had an idea of how to detect the letters from the printouts, but it didn’t work.
On the failure side, typing is still not really improving. Slowly McTypesABit is only doing 30 words a minutes.

Month 2  (OCR & Linting)

This month we were able to add a lot to the bug finder. Up to 13 patterns. We’ve even shared the program with other teams to help them check their code. We also got a way to do a bit of automated reading of the characters from the printouts. It’s not very good (about 50%) but it gives us a starting point which is nice and we are doing good overall. Might even be a month or two early to finish this project.

On a side note: because of a 2 week vacation we have a new slowest typer! It’s very close though (40 wpm vs 39 wpm)

Month 3 (Done Done?)


The WordReader is still having problems (only 80% accurate) but it’s been helping us move really much faster. With the combination of BugFinder we are going to be done with the rewriting by the end of next month. The teams still has budget though and it looks like both WordReader and BugFinder might be useful outside of just helping us finish our original Task. We are looking into making them more robust…

Wednesday, April 15, 2015

Making Things Smaller

Often, when people talk about minimum viable product or story splitting we hear the question

"but how can I make this smaller?"

I'm going to show a very simple, powerful and yet often overlooked strategy for doing this.

Use smaller numbers

If your scenario has numbers in it make them smaller. You can do this in 2 ways depending on what you are trying to accomplish.

Minimum Viable Product

When you are trying to get to the smallest thing start your numbers near 0 or 1.

Here are some examples:
 "This report should do 5 things" -> "This report should do 1 thing"
 "Get data from 3 sources" -> "Get data from 1 source"
 "The UI changes these 8 things" -> "First we will change this 1 UI feature"
"We check in code every 8 hours" -> "We check in code at least once an hour"

Sometimes people 'hide' the numbers
 "Handle English, Spanish & French" = "Handle 3 languages" -> "Handle 1 Language"

Also, remember that programmers tend to think in terms of only 3 numbers: 0, 1 & many
 "Save directories" -> "Save many directories" -> "Save 1 Directory"

This also creates a very nice step from 1 to many of 1. In programmer that is:

"int postalCode = 90210"  -> "int[] postalCodes = {90210}"


Minimum Viable Change

When coaching you usually want to go the opposite direction so that the change is less noticeable and easier to absorb without conflict.

 "Our sprints are 4 weeks" -> "Our sprints are 3 weeks" -> "Our sprints are 2 weeks" -> "Our sprints our 1 week" ->  "We release weekly" -> "We release daily"

 "Our Build has 9 manual steps" -> "Our build has 8 manual steps"
 
Sometimes this shows up as negative numbers:
"No teams are writing tests" = "8 teams aren't writing tests" -> "7 Teams aren't writing tests" = "1 team started writing tests"


The Point is... if you start making a habit of looking for numbers in your stories and processes you will see them everywhere and then they are easier to reduce.

Monday, January 5, 2015

Women in Tech & Men in Zumba

I have been a long time supporter of women in tech but today I realized how little I truly understand their situation.

Today my girlfriend brought me along to a Zumba Gold class. This is a easier version of zumba and often is frequented by older (60+) women. We were the youngest there by far.


I was the only man.

I'm a good dancer. Proficient in swing, salsa, cumbia & merengue which is basically what Zumba is. Youth is also an advantage in most physical activity. This should be very easy for me. Also, everyone was both very nice, complementary and welcoming. 

I was the only man.

I felt very uncomfortable. I would not have been there if not with my girlfriend and can't imagine going there by myself. I wouldn't say that I enjoyed it. I wouldn't say that it was "my thing". I wish I could have turned invisible many times. But that was not the worst thing.

The worst thing was I had absolutely no idea what to do to make the situation more comfortable. Here I was, with all the self interest in the world to want to make things easier and no idea at all how to do it. 

I did gain some clear insight into what I did NOT want:
  • please, oh god please, do not single me out or call more attention to me
  • I felt very uncomfortable when people would come over to give me compliments
  • I did not enjoy the particularly extra girly dance moves
This makes me question some of the things I would do in regards to women in tech. Such as 
  • Make sure the women are recognized
  • Compliment women when they do good 
  • Anything remotely 'brogrammer' related (the mere thought of this now makes me cringe)

As uncomfortable as it was being the only man in zumba today, it was one day. It's not like it's my career... 

I can only imagine how many girls we lose the first few days of a programming class when they just feel like they don't fit in.