Fair wage project for facilities staff @ ThoughtWorks Bangalore

It all started with a blog by Nag (http://www.facebook.com/note.php?note_id=188825934476259). While this started an internal debate about what really can be done there wasn't any disagreement with the content. In discussion people unanimously felt the level of service provided by facility staff was impeccable. Some of us (Nag, Rohit, Sadique, Suresh, Pradipta and me) decided to take this forward as a "fair wage project". The goal was to create a system by which facility folks can earn a fair wage while working at ThoughtWorks premises. As it turned out it wasn't very difficult and in march we got the first release out :-) (money in hands of people). A short account of what we really did:

First of all, we figured out how much was the gap in salary compared to what we considered fair and how many facilities people we had. The total amount turned out to be around 66,000 for 24 people. There was slight issue regarding inclusion of people who work in security. Since, some of them seemed to earn more than the amount we arrived at. We decided to provide a minor increment though it meant that everyone's salary became almost same. I am unsure about how to weave in the skill factor in this issue.

In order to raise the amount we just asked for people in ThoughtWorks India (not just Bangalore) to pledge 500 or 1000 per month for six months. We used email primarily and staff meeting to request for contributions. In some sense we got an overwhelming response. Naturally majority contribution was from Bangalore office but there were also TW Bangalore alumni and few people from other offices in India pitching in. We reached 66,000 with in few weeks. Given our size of around 350 in Bangalore and 600 all over India, I think it was quite an achievement by ThoughtWorkers.

The most complicated question was about how to make this money available. There were some opinions around this.
Providing additional cash, may be perceived (by receiver) as gift and not well earned, notwithstanding our belief of contrary.
When we asked the facility people about their preferred mode. They felt that additional money would get spent and they would rather save for specific and emergency requirements.
Some people who volunteered to pay were of opinion to provide it in some form of insurance or in fixed term saving account.
After some debate we decided to create a separate account for them in post office. Post office, because it is a non-intimidating for people who aren't familiar with financial know-how and paper work. Currently TW keeps the passbook for this account, they would have ability to withdraw money provided they have a genuine reason. Genuine reason is anything but daily expense or wasteful in nature. (Instinctively I don't like this paternalism but neither did I have any experience as to whether such control is good or bad, hence I am undecided about it.)

In the month of march 24 facilities people received payment. For some people there is a small issue as they do not have residence proof which we are sorting out.

a proud ThoughtWorker

(Disclaimer: ThoughtWorks doesn't hire facilities people directly rather we sub-contract it as majority of other business entities in India do. This compensation is available as long as people work at TW Bangalore facilities.)

Why I decided to be a vegan?

I have born and brought up in a family with "liberal" eating preference. We ate all common items other than beef and pork. (I always slightly wondered why no pork, for ours being a Hindu family. But I am/was not curious enough to find out more about this common practice.) Anywhere between 25-50% of meals in the house had meat/fish/egg in it. When I started living by myself I continued this.

During this period I occasionally confronted myself with the question "whether eating animals is unethical" because of the killing involved? I could never come up with affirmative conclusion. My reasoning went like:
Everything we eat has life whether plants or animals.
In nature there are carnivorous and herbivorous animals.
Human beings happen to be carnivorous + herbivorous.
Basically it seemed natural.
Having said that I dreaded going to meat shop and see animals cut before (most of meat shopping in India still happens like this). I believed this to be a response, for some evolutionary reason not evident to me.

But in last four years there were more questions. I would broadly classify them as:
1. Is eating animal healthy?
2. Is non-vegetarianism unsustainable for our planet?
3. Do animals have a life of dignity, before we kill them and eat? Should they deserve one?

I brushed aside the first question as I am quite casual (not careless) about what I eat. Quality of food never gets me worked up. I don't care too much if small insects or hair is found in my food. I would set that small portion of food aside and continue eating. On these occasions most of my friends choose to abandon that meal to my surprise.
Coming on to the second one, based on all scientific evidence I got quite convinced that this was a real issue and if I wasn't doing something then I was part of the problem. I realized my consumption pattern need to be tested/adjusted for sustainability.
But I was most disturbed by the last question. Earlier what I always thought to be an issue of killing animals vs killing plants, was much more than that. A cock/hen stacked in small cage for its entire life, carried on bi-cycle upside down, kept without water in sunlight and finally killed slowly (halaal) is not something I could be convinced as moral thing to do. In all this killing part was least heart-breaking. There is enough evidence of such cruelty on the web like http://www.peta.org/

Being sustainable meant that I should lower my consumption. But being an agent of torture for animals was not something I was happy about. In other words I had to pledge to give up non-vegetarian food. Also, in theory I left myself an option of occasionally having anything non-bred (chicken/fish).

(next: Quitting non-vegetarian turned out to be harder than smoking)

Continuous Integration Patterns: Commit Gate

Context

Only fix to be allowed on a broken/breaking build

Description

Continuous integration, hence code commit, is a team activity. A broken CI build adversely affects the flow of the entire team, hence needs to be fixed at highest priority. A commit made on top of broken build has no chances of fixing it accidentally. It can in fact make it worse. Negligence or lack of knowledge of build status can lead to commits on top of broken build.

Continuous Integration States
Green: Successful and not building
Red: Failed and not building
Yellow: Successful and building
Orange: Failed and building
Pink: Failing (In integration which have multiple jobs running in parallel, if a job fails while others are still running. Might not apply for tools)
Grey: Unknown (for server, network being down)

Of the above states on Green and Yellow are valid states in which a non-fix commit should be allowed. Most modern source control systems provide facility to hook custom code (e.g. http://www.kernel.org/pub/software/scm/git/docs/githooks.html). Pre-commit hook does the following.

1. Checks the continuous integration state to see if it is either Green or Yellow.
2. Checks whether the commit object contains some sort of identification that it is for fixing build. This can be as simple as commit message containing text like "Fixing build".

If both the tests above pass then Pre Commit Hook allows the commit to go through.
There are places to run the Pre Commit Hook.

1. Centralized VCS
2. Commiter's VCS (in case of distributed VCS) or VCS Client (e.g. with SVN). Since this pattern also amounts to policing running it on the commiter's environment might be socially more acceptable.
   

Limitation

If the continuous integration server doesn't respond very quickly to status check then the users commit might get delayed. This might cause annoyance to the commiters.

Continuous Integration Patterns: Verified Commit

Context

Continuous integration build should always pass and development shouldn't stop to perform build.

Description

Every commiter has a private branch to which she commits. The changes from this branch fed to verification build. While the build is in process the commiter can continue to do her work. Successfully verified changes are merged to the main source control. In case of failure the commiter need to provide a fix and the continue the with the same process of verification.

Use of distributed version control system is recommended over centralized ones as they are designed for handling frequent branching and merging of code.

Limitation

Requires additional hardware to perform verification builds.

Not suitable when the build is unstable, as it might lead to a lot of waste.

In large teams it might lead to code conflicts when merging to the main branch.

[Source: https://sites.google.com/site/petmongrels/home/continuous-integration/continuous-integration-patterns/verified-commit]

Continuous Integration Patterns: Staged Team Commit

Context

Unusable continuous integration, too many commiters and higher need for integration within a team.

In large sized projects if the continuous integration is unusable because of unstable nature of CI, it can lead to a lost of waste. This waste can be limited by creating smaller team specific continuous integration flowing into the main integration.

Description

A set of commiters (generally a team) define their own source control (or a branch) off which they work. There is a continuous integration system which facilitates, integration of code within the group and create output which can be used for downstream activities. On a periodic basis the local code is merged with trunk (main branch).

Use of distributed version control system is recommended over centralized ones as they are designed for handling frequent branching and merging of code.

Limitations

Integration of code is limited within the team and across different teams the integration is not continuous. This can lead to all the issues caused by not doing continuous integration like integration hell, bad merge etc.

Increases the testing effort as merge verification is required.

Continuous Integration Patterns: Optimized Parallel Jobs Build

Optimized Parallel Jobs Build

Context

Modular System. High build time. Hardware constraint to use Parallel Jobs Build.

Description

In principle it is same as Parallel Jobs Build but avoids the duplicate work. As a result it needs less resources.
Extracts out common elements of different jobs in Parallel Jobs Build into a setup pipeline with single job. The other parts of the job are run in a downstream pipeline which works of the output of setup pipeline. This applies to applications using compiled programming languages when the tests cannot be run before compilation of code.

Limitations

• The continuous integration build is not the same (a setup where binaries are published and consumed) as local build, hence not verifiable by commiter. This can overcome by designing for this problem.
  
• It creates temporary output which might not be useful for any downstream activities after the build is over but might still occupy the disk space on CI server.
  
• The build time may be higher than Parallel Jobs Build depending on time taken by the continuous integration server to schedule individual jobs and transfer output between different jobs.
  

Silverlight vs plain old web application

In last couple of years the question of Silverlight or plain old web application, DHTML, (HTML/CSS/JavaScript) has come up few times in front of me. During which I have also had opportunity to use Silverlight on a large project. I don't remember where exactly I started in this debate but now I am firmly in DHTML web camp. So here I try to list down why?

As a user:

• You loose URLs and all the power that comes with it (hyperlinks, bookmarks).
• Then there is debate about rich client making users more productive. There is only some merit to it. There is a lot possible in DHTML. One of our teams in ThoughtWorks built a sophisticated call center application and the users were very happy with its usability. They were looking from complete keyboard based usage of system. I know anyone who has used GMail knows this already, but this is sometimes dismissed as "GMail being a functionally simple application".
• Some believe with Silverlight you do not have to worry about browser compatibilities. Again this is not as bad as some might make it sound. With jQuery this problem has been reduced to great extent. Also, Silverlight isn't really supported well on all OS/browser.
• User has to install the Silverlight plugin (may be not a big issue for intranet applications)

From development (and its cost) perspective:

• One of consequences of Silverlight kind of architecture is that you have to add data transfer objects, which you could have lived without otherwise. This cost is not small.
• Silverlight forces you to use asynchronous calls only to your back end services. This makes the implementation harder compared to WinForm or WPF.
• There is no good tool support to analyze memory leaks in Silverlight. In an event based system this is a problem because most typical memory leaks came from observer pattern (event in C#). We had to use WinDebug for it. In short its not easy, we had experts in our team to use this tool.
• Automated testing is hard. We used White and WebAii from Telerik. Any rich client kind of testing means you cannot run tests in background. So everytime you run the test you have to stare at the screen. Using white's custom commands and UI Automation patterns you can theoretically get around it, but I haven't done it myself. We adopted custom commands quite late in our project.
• Automated tests run very slow when compared to Selenium with WebDriver combination. The cost of this cannot be ignored in teams which do continuous integration.
• Silverlight like WPF works on concept of styles. I am not an expert in this, but its hard to find people who know this stuff.
• Most likely you would be using C# in the back end/elsewhere in the project. This means there is some sort of common code. Reusing code between .NET and Silverlight (its a different runtime and has different class library) is tricky at best. You end up wasting a lot of time, sometimes, not realizing what is really going on. We had a lot of "hmmmmmm or !@#%^&%$# moments" on our project.
• You cannot instantiate controls in test context. Best way to test Silverlight controls (we wanted to test data binding) seems to be using SilverUnit. This requires typemock which is not open source. My guess is because typemock manipulates the instructions in dll and makes it possible to instantiate it in test context. Not being able to unit test Silverlight controls is a big disappointment and it shows flawed design. Testability should be inbuilt in any modern software framework.

Arguably having C# code to model user interface has its advantages but they pale in comparison. Overall it is a quite costly proposition and I have been advising people to not go this route.