Posts Tagged ‘programming’

Trio programming revisited

May 1, 2012 4 comments

Last month I was at the airport browsing random things on my phone and I ran into this text by Jon Evans.
It made me think of how people always try to come up with the perfect set of practices for software development, but there’s always someone reminding them that common sense still prevails over every possible process or practice. But it also reminded me of some thoughts I had many years ago about pair programming, or, actually, trio programming.

I’ve seen many terms for the situation where 3 people are coding together: triple-programming, trio-programming, trairing, etc, choose at will.
The problem I see with these terms is that usually they are used to describe 3 people working on a single feature, and that’s not very effective in my opinion – except on some rare occasions with extremely complex/important features or problems (common sense still prevails).

Going back in time a little, when I was in college I had to work with a group of 3 other guys to write a web application, it was our finals for one of the courses we were taking, and it was a big deal because we had never written something like that with all the integrated bits and layers and shenanigans. One of the guys bailed for some reason I can’t recall – no hard feelings, he had his legitimate reasons – so it fell to the other 2 and I to do the work.
All the 3 of us were raised in Brazil, and as I usually say, every Brazilian is born agile, because we always seem to “do everything at the latest responsible moment”. As expected, 2 days before the deadline to hand in the application we had barely started coding, so we had an overnight development session where we wrote most of the application together.

It worked like this: we were 3 guys, we had 2 machines. There was always one pair and one solo dev, but the pair would rotate constantly. I was pairing with João now, and César was going solo, until he stumbled on an issue/doubt/important-decision-making-point, where he would call for help and either João or I would join him. If João joined him, now I was the one going solo, until one of them joined me again. We had 2 well defined streams of work, but neither of them had a clear driver, because all 3 of us had a medium-to-high level general understanding of what was going on with both.

The most interesting thing is that this process had not been defined previously, in fact we only realized that it had happened once we finished, it was all very natural and organic, and worked very well. We didn’t have any tool to remind us of rotating, in fact, we barely noticed we were rotating. We were just 3 guys working together on a project, all of us helping one another.

Back to the present, whenever I think about that experience, I recall how well it worked, and how interesting it would be to try that again.
I guess I am just trying to put into words a very non-organized way of work, but I think it’s possible.
And here’s why:

A typical pairing session for me usually has 3 clear different actions: the talk, the decision making, the typing. For the typing bits, given both people in the pair are proficient with the technology in hand, usually there’s not much the navigator has to add. Most of the comments around typing are going to be things along the lines of “you forgot a semicolon” or “there’s a typo there”, which are usually things the driver had already noticed and was on his way to fixing, or that he would catch quickly enough anyway. The greatest value of pairing is on the other 2 actions.

(Now, there can be typing involved in the talk and in the decision making, typically when one of the developers in the pair go like “here, what if we did something kinda like this?” and starts to type code away, usually not really code that is going to be used in the final version of the solution but just a means of expressing his/her ideas. So when I say that “typing” is one of the 3 actions in pairing, it does not include these moments where we write code to discuss our solution.)

That’s why I think triple-pairing in 2 work streams works so well: there’s always a pair talking and making decisions, while the typing can be done solo. Hell, if the typing is so important to you, and, let’s say, you don’t want to have to wait for the tests to run to catch a typo, I could even argue that there’s some just-in-time code-reviews happening there as well: whenever the pair enters in typing mode, one of the guys in the pair goes back to the solo guy to check on how he’s doing and can offer advice on the typing bits.

So how can this practice be formalized? Should we try to assign 2 stories to 3 people?
Well, maybe, why not? I still want to try this out and see what happens. If anyone out there has had experiences in these lines, please share!

But I think that there’s more to that than simply having 3 developers for 2 streams. The project I am currently working on has a small team of 5 developers. Which means there’s always one person soloing, but this person is more often than not doing QA work. Anyway, here are 2 situations that I think fit this idea even though they don’t fall into the 3 for 2 category:

– I worked in a story while another dev worked on some other bits of work. We were sitting side by side just as if we were pairing, but our pairing screens were not connected to the same machine. We both knew what each other was doing, and we both talked about both problems constantly and even took each other’s keyboard for a few seconds to type something – but we had clearly one person working on each stream of work;

– 2 pairs working on 2 different stories, but all 4 people involved knew at least some about the 2 stories (they are both stories in the same project after all, so guess what? They are related!). One developer goes to the restroom, his pair has a doubt, one of the developers in the other pair joins them, the refreshed-developer-who’s-just-back-in-the-room hovers a little bit both streams of work and eventually joins one of them. This happened more than once (and not only triggered by restroom visits, otherwise we would be thinking about a general team visit to the nephrologist).

So, here are my conclusions:

– 3 developers for 2 streams of work may be worth trying. I want to try it out again, and will share my experience when I do so. If you have, please share with me.
– When pairing on a story with someone, don’t shut yourselves from the world – I see this happening very often. Go around the team and talk about the problems you’re facing, ask for advice from a third party, go around offering advice. If you’ve done the talk and made a decision with your pair that results in at least a few minutes of pure typing/refactoring/moving stuff around, choose one of you to do the dirty job and get the other to go poke around and check what the others are doing, maybe they could use some talk themselves. Of course, sometimes it may be worth to stay and pair through the typing too, specially if it involves moving a bunch of existing code around or touching the always-present-hairy-parts of the codebase – again, common sense.


Don’t use this in JavaScript

April 28, 2012 8 comments

this JavaScript:

var o = {
    f1: function() {
    f2: function() {

o.f2.prototype.f1 = function() {

var k = {
    f1: function() {

new o.f2();
var x = o.f2;

There. That’s why I never use the this keyword in JavaScript.
And that’s why I think you should stop using it too.
Can you figure out what’s the output of this code?

Read more…

Step-by-step selenium tests with page objects, dsl and fun!

September 29, 2010 15 comments

Note: this is a long post!

Not long ago I wrote about functional tests and the page objects pattern in Aqris’ blog. Back then we at Aqris got all very excited about page objects as they were the solution we were looking for to solve our problems on maintaining our functional test code base, which by that time was based on a set of messy helpers that nobody really understood completely.

Before page objects, whenever a developer in our team had to write a test that had to perform an action no other test already performed, he or she would go through that bunch of helpers trying to figure out which one was the helper that should perform such an action. The result of this approach was that the team couldn’t get to a full agreement on what was each helper’s responsibilities. Everybody agreed that the code was not good, but each person had their point of view on why.

We first learned about the pattern here, when reading about WebDriver (now Selenium 2). Page objects came as the solution to separate the different actions our helpers contained in an extremely simple and even obvious way that nobody in our team had previously thought: simply creating a specialized helper for each page of the application.

It is in fact so simple that I still wonder how come we didn’t think of that before… I think that we were too busy trying to figure out how to deal with the helpers we had, and we were too used to have them that way. I guess that’s because the previous project we had worked on (and the first one we had a strong movement towards automated tests with Selenium) was a web app based on only one single page with lots of GWT-based ajax.

Anyway, excuses aside, we started using page objects and it was great! But then other doubts started to come up: how to deal with parts of a page that are common to many pages – for instance a side navigation bar? How to make our tests more readable? Should our page objects use selenium directly? If yes, how to resolve the selenium dependency? Can the page objects just encapsulate the locators for the html elements instead? Should page objects be responsible for the tests assertions too, depending on xUnit’s API, or should they just provide verification methods that would be used by our tests’ code itself?

I think that these are questions that may or may not have a straight correct answer, but here I will write a bit of what worked well for us or for me later on when dealing with that.
To do that I think we can write a test for an imagined scenario.
Let’s try that!

The problem

Let’s say that we have a test case to test the following hypothetical scenario:

We have a hypothetical book store application.
Every page in the application has a navigation bar on the side.
An user goes to our application home page and, by clicking on a link on the navigation bar, she goes to a page to search for books.
On the search books page she fills in a search form, entering “Tolkien” in the author field and “Rings” in the title field, and submits the form.
She is then redirected to a search result page that contains a list of books along with the same search form already filled in with the same search data she had entered – in this case, “Tolkien” in the author field and “Rings” in the title field.

We want to assure that, given our test data, the search result contains the book ‘The Return Of The King’.
We also want to assure that the search form in the result page still has the data she had previously entered.

The code solution after the jump 🙂

Read more…