Programming collaboratively in geographically distributed team

Versión 1.0

January 13th, 2010

beWeeVee's Scenarios

Programming collaboratively in

geographically distributed teams

Sebastian Fernandez Quezada

CEO

[email protected]

beWeeVee’s Scenarios | Programming collaboratively in geographically distributed team 2

Header Information

USER TECHNICAL BUYER ECONOMIC BUYER

Developer

Architect

IT Department

Offshore Manager

Director

CIO

A day in life (before)

Scene or situation: Focus on the moment of frustration. What is going on? What is the user

about to attempt?

Borys is the lead programmer of a mid-size offshore Development Company based on

Poland. He is currently working on the corporative payroll system of its main client who is

based on the United Kingdom. He spends one week a month at the client company at

London working along the client in planning new features and requirements. That week is

always very intense as the face to face communication makes it a very productive time.

Borys is a very skilled developer, he got the lead programmer job after his superior was

required by the client for another mission critical system just a couple of month ago. Before

that he was the developer of the Transacting engine, the one that execute online

transactions on behalf of the entire organization.

In one of those trips an urgent change request was added to the backlog by Ian from the

business analysis team. That left them 4 days to do the necessary changes in the

transacting engine, and the rest of the application.

Irena was a very clever developer at the Warsaw team, leaving her in charge of the 120K

lines of the Transacting engine code, had been a no brainer decision. However, she was

quite new to the job of extending it.

Desired Outcome: What is the user trying to accomplish? Why is it important?

The change request was in fact caused by a new requirement issued by the England Central

Bank, and it must be in effect by Monday morning, when the company would start the

payroll processes to all their providers and workers. If they didn’t comply most transactions

would be rejected by the source and requiring the company to handle each one individually


by a manual workflow; with the volume of transactions scheduled to occur that was

definitely an impossible task.

Attempted approach: Without the new product, how does the user go about the task?

Borys meet with Ian and Irena for 2 hours to understand the scope of the critical request.

Irena was at the phone from Poland, and she was able to understand the main problem.

After that Borys meet with her by phone to speak about the extensions that had to be

performed on the rules engine to handle the requirement of the Central Bank. Borys knew

that the rules engine was capable of doing it with some extensions that would require slight

architectural changes in the adapters and rules logic. Being the most knowledgeable person

on the transacting engine (it was his baby after all), he explain in detail Irena the solution. It

wouldn’t take him more that 1 day to solve the problem, which would leave the certification

team Friday to perform all the required tests to put it in production on Saturday.

He continued with his planned work while Irena was busy working along the plan they laid

out. At the end of the day they spoke again, she was a little behind, and had to take a

couple of decisions that Borys wasn’t confident about. He had his time booked until after

dinner, so he wouldn’t be of much use that day. She continues working around the clock

until 1AM.

The next day, they had the daily meeting Irena needed lots of help with the rules engine,

but no one was as skilled at it as him. They phone called each other every 2 hours to assess

the status. Lots of emails with questions went back and forth, Borys was worried. At the end

of the day he had to take the airplane to come back to Poland, and they were already

delayed.

He went to the office on Saturday and started to review the code, he found very important

mistaken assumptions; it wasn’t Irena's fault, which was the first time she extended the

rules engine. That part of the system had been in place without modifications for almost 6

months. He had a hard time remembering all the nitty gritty details on why he did some

things also. They pair programmed and redid the entire feature and finished by 2AM. On

Sunday the Certification team had to come to the office, they weren’t very thrilled at it.

Deployments where done on weekends so the production team had rotating personnel that

worked on weekends so they didn’t mind.

Errors where found and corrected by Borys and Irena, working around the clock they

decided that if there was a bug they wouldn’t correct it; there was no more time, they had

to put the changes in production right now. The production team finished by 5AM London

Time and was ready to roll by 7AM. Most transactions were executed with some exceptions


that were performed by hand. The mission has been accomplished. Remaining defects

where squashed during the week for the next weekend deployment.

Interfering factors: What goes wrong? How and why does it go wrong?

Irena was a very clever developer but her knowledge of the inner working of the rules

engine was not as detailed at needed, even if Borys was pretty detailed in the

documentation. Borys wasn’t able to see what Irena was doing because IT rules at the client

company didn’t allow him to use screen sharing software (banking network restrictions are

a norm almost everywhere) so his communication bandwidth was limited and wasn’t able to

track her steps to guide her. The end result was to restart the entire work Irena has been

doing for 2 days adding to the project wasted effort.

Borys knew very well the inner working of the rules engine (as he has written it) but the last

time that part was modified she wasn’t on the job. Even Borys had trouble remembering

why he did something like performance tweak here and there. Those detailed inner working

reasons are not typically documented because they are not worth the effort (except in cases

like this one).

The certification team at London was not very happy to have to work on Saturday night and

Sunday when they were told that they would have the build by Friday. And the production

team had to work around the clock to have the system productively by 7AM without the

entire certification process done; at the time they were already complaining that if

something bad happened it wasn’t their fault.

The system worked but they were lucky, as the certification process couldn’t be performed

in it’s entirely; so they risked a lot to go into production.

Economic Consequences: So what? What is the impact of the user failing to accomplish the

task productively?

Failing to have the requirement changes by Monday would have been a huge problem for

the client company and for Borys boss too. Having to resort to the manual workflow would

have delayed the payments to providers for 2 to 4 days, delaying also the delivery of

important goods. Borys boss would have trouble billing the extra hours worked by Borys

and Irena, as the client wouldn’t be too thrilled of the inconvenient.


A day in life (after)

New approach: With the new product how does the end user go about the task?

Borys and Irena would have the meeting with Ian. Irena and Borys would fire up Visual

Studio, and try to connect through the Windows Peer-Networking stack (a peer-to-peer

technology that can pass firewalls that enable IPv6 edge traversal). Sadly the IT department

does not allow IPv6 traffic, so Irena shared the solution through beWeeVee for Visual Studio

Saas Viewer, a Silverlight application that is able to give basic access to the solution on the

other end.

Borys and Irena discussed the detailed implementation right into the code, putting

comments and discussing key details of the inner working on the rules engine. At the end

of the 2 hours conference call they had already laid out a solution straight in the code. That

was possible because they would simultaneously write code while they discussed the

changes needed. Borys helped Irena also to write the tests that would define the interface

and behavior of the rules engine changes.

Irena worked on her side, and once in a while Borys connected to the Saas Viewer to see a

fast playback of the changes that Irena is working on; in the event he discover something

that he was not confident it can work, he annotate the information in Irena's code and sent

her an small review project tweet for her to notice that he was around.

Irena finishes by 4AM and by Friday morning, the build was sent to the certification that

took the entire day and Saturday morning. By Saturday midday the build was ready to be put

in production.

Enabling factors: What is it about the new approach that allows the user to get unstuck and

be productive?

The live collaboration straight into the code that beWeeVee added to Visual Studio allowed

Borys and Irena a very efficient communication and collaborative workflow. The use of the

beWeeVee for Visual Studio SaaS Viewer gave Borys the ability to access Irena's solution

code in a split second from a web source, even if the typical workflow was disrupted for

security reasons inside the bank.

Furthermore, the ability to replay all changes that Irena made to the code was an invaluable

aid to let Borys understand in a quick glance the state of advance. Even more, being able to


review some rule engine key changes months ago using the playback feature aided Borys to

remember key details that were invaluable at the time of communicating the solution to

Irena.

Economic rewards: What are the costs avoided or benefits gained?

One of the biggest benefits of beWeeVee for Visual Studio is that the communication

bandwidth is enhanced by working directly with the subject matter, not in an abstract way.

In that way, the mental model mismatch between Borys and Irena get narrower, diminishing

the rework, accelerating the time it takes to accomplish the task. The solution obtained

diminished the needs of redesign and refactoring after production because the entire team

was more efficient.

Under the same assumptions, an alternative solution to diminish the risk identified after the

first day would have involved Borys to depart Thursday noon to Warsaw to join Irena on

Friday. Even in that case, they couldn't have been able to release the build for certification

on Friday mid-day.

Under a different set of assumptions the IT department would have permitted the use of a

remote desktop solution. That could make a slight difference on the communication (the

first 2 hours information exchange between Borys and Irena), however it wouldn't made

much difference on the efficiency of being able to write code simultaneously and the ability

to use the playback ability. So the efficiency would have been still much lower under those

assumptions. Moreover, as beWeeVee for Visual Studio is embedded in the native

development environment, the development workflow is not altered; something that would

have happened using other alternative software likes Etherpad or beWeeVee Web.

Corvalius | Useful Change

[email protected] | www.corvalius.com

mailto:[email protected]

http://www.corvalius.com/

Technology

Programming collaboratively in geographically distributed team