Google+ Followers

Monday, December 13, 2010

It is not about how quick, but about how far!

It's quite common to some business/manager people come to us and say:
I'm trying to find ways to increase our production capacity... I would like to go faster. How quick can we  go? (...)

The point is: Software development is not about how quick, but about how far.
We always should think about how long our current solution will survive.

Saturday, November 27, 2010

The question is: Why not to automate?

Lately I have been in some meetings to discuss if we should automate the tests scenarios or not.
After some discuss with my colleagues we came up with this pattern:
When reviewing a story instead of asking if we should automated the tests for the story ask: Why not to automate the tests scenarios for this story?
If we don't have a really good reason to not automate, let's automate.
If the reason is related to the size of the test scenarios, the difficult to write all the scenarios or quantity of scenarios then we should break/rewrite the story.
If there's any technical reason, apply the 5 whys analysis to find the root cause, that in most of the cases will be a technical debt.
What will left will be just real manual test, like visual validation.

Friday, November 26, 2010

How to avoid losing a unused terminal command line

This morning I got a great tip...
I typed a command in my terminal but I wanted to run another command before executing the line that I just typed without loosing the information in the current line.
For instance:
I typed in my terminal the command:
git commit -am "Unit test for scenarios A, B and C"
But I was not sure if I was committing just the scenarios A, B and C that I have changed, I would like to run a git diff before committing but also without losing my committing message...
Then my friend Duck told me to put a # in the begging of the line and... voilà!
# git commit -am "Unit test for scenarios A, B and C"
It transform the line in a comment, so that I could hit enter without executing the commit and that line went to my history so that I could recovery it.
Thanks Duck.

Wednesday, November 17, 2010

Influencing people - How to get involved

Some weeks ago I gave a talk in the office about How to influence people.
My experience in this topic comes mostly from three books: How to win friends and Influence people by Dale Carnegie, The 7 habits of highly effective people by Stephen R. Covey and the Holy Bible by God.
If you already read the Dale Carnegie's book, you will see that the topics for the deck came from there, but while talking I was browsing the three book ideas on this subject.
Here is the deck:

Influencing people
I'll not describe the deck here as each slide deserves a whole blog post. Some day I'll write more about it.

Tuesday, June 29, 2010

Remote Pairing

Remote Pairing

In the last few weeks I had an effective remote pairing experience. I'm locate in Brazil and my pair is located in USA.
That experience gave me some thoughts about remote pairing that I would like to share here.


To share the screen, we used VNC (TightVNC to be more specific). It works well and you can config the compression and color resolution, what helps with slow connections.
To voice chatting we have used Skype, with a two-ear head-set. In my opinion the two-ear is very important, because it helps you to don't be disturbed by any noise from your local office.
Normally I use a two monitors set-up with a virtual-box filling one of the monitors, that helps to you not open your personal e-mail in a shared screen.

The pairs were in different timezones. Brazil is 4 hours ahead of USA ET. For this reason we did not pair for the entire work-day. And it was a good thing, as both sides had time to do other work which is not related to the story at hand.
Also we used the Pomodoro Technique that was good to things like going to bathroom, smoking, drink water, cellphones, etc...


TDD. Use the ping-pong technique.
Turn on the video on Skype (Gtalk, Msn, whatever...) and raise your hand when you gonna start/stop driving.

Thursday, April 8, 2010

Pairing techniques

This week my colleague Guilherme Motta and I did a presentation about Pair Programming, that were really fun, we learned a lot. During our research I noticed that there are few posts, wikis or sites about Pairing Practices, so I'm sharing with you some practices that we found.

Ping Pong

In this technique the first programmer writes a minimal failing unit test, the second programmer modifies the code to pass the unit test(s) than the second programmer writes a new minimal failing unit test and gave the keyboard back to first programmer, and so on. This loop continues as long as any programmer is able to write failing unit tests. The technique can result in the driver role switching as often as a few minutes or less.
Pros: CV taught me this one and was really fun, because you don't have to discuss a lot, although you keep conflicting the programmer's ideas.  
Cons: I don't know.

Chess Clock

Using a chess clock the pair define a time interval to each one be the driver, when the clock rings the pair switch theirs positions.
Pros: Ensure that each programmer get the keyboard.
Cons: It can be inconvenient to pass the keyboard in the middle of a method or idea.

10-second rule

The navigator should wait 10 seconds before pointing out a typo. Generally that’s long enough for the driver to correct a typo that’s already noticed. Excessive interruptions are distracting.
Pros: No one get nervous.
Cons: It sucks if you are the navigator.

Think Out Loud

The driver “thinks out loud” as he/she’s coding. This helps keep the navigator in the loop, and communicates the intent better. It’s certainly not a technique that most people practice without suggestion, however.
Pros: Pair is about conflicting ideas and talk is a good way to say what you are think about.
Cons: You may strain your vocal cords.

Sharing the ppt...