Roger Almeida's Opinion

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.

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.

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.

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 View more presentations from Roger Eduardo P. de Almeida . I'll not describe the deck here as each slide deserves a whole blog post. Some day I'll write more about it.

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. Tools 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. A...

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 inter...