Where is code created?

1 Aug

Are you surprised by this question? You are thinking the answer is so obvious, isn’t it? Of course, the code is created in the computer!

Just think about it. Is the code really created in the computer? In my humble opinion, No. The code is created in the head of the developer. “What happens (while creating code) in the mind is some discovery or decision. What we do at the keyboard is turning that discovery or decision into useful form”. (credit: Paul Oldfield)

Profound, isn’t it? I cannot think of any argument against this fact.

If we accept this as a fact, several questions come to my mind:

  • Given that people are the most important ‘resource’ for software creation, why are people treated like nonliving ‘things’?
  • For something which people primarily create in their heads, why is intrinsic motivation not given the importance it deserves, and why is it (wrongly) believed that incentivizing with monetary rewards is the best way to motivate people?
  • Why are we obsessed with applying manufacturing relevant productivity measures to people? E.g. Typing code for at least 6 hours a day.
  • Why is effort spent towards communication and collaboration between team members seen as nonproductive/waste, when in effect this will actually lead to better product/solution?
  • If we take into account the collective experience of the team and the fact that all human beings are capable of thinking, why are Managers more powerful than the teams?

Answers please, anyone?

I am extremely saddened by the colossal waste and non-utilization of human brain’s potential, in the IT industry. Hope to see a revolution happening for changing this. As of now, moving to the Agile mindset is my only hope.


Distributed Development Challenges – Part 2

29 Oct

In my previous post, we examined five challenges in Distributed Development.   Let us look at five more challenges in this post.

1.     Lack of Cultural Sensitivity

Distributed Development often involves teams spread across nations and continents. As we all know, cultures vary widely across the globe and ignorance of culture can lead to even an innocuous gesture, or lack of it, ill feelings among people.


An example will illustrate the point. People in countries like USA and UK are very conscious about maintaining a certain physical distance between people. Violation of this distance makes them distinctly uncomfortable. An apology/’excuse me’ is always given and expected for any accidental touch, regardless of who caused it, and not doing so is considered rude. On the other hand, in countries like Brazil, China and India, people, especially of the same gender, are simply indifferent to the distance maintained between them, as well as to accidental touches, thereby not offering any reaction when it happens. I have come across multiple instances of misunderstandings between people, due to lack of appreciation and understanding of cultural differences like these.


2.     Lack of ‘Big Picture’ View

This challenge typically occurs when the Product Owner and Business Analyst are in a remote location. While they may conduct a ‘big bang’ session to provide the big picture view, their conversations around the big picture may get ignored, and the most of the team members might just get to see limited pieces of the puzzle. The problem aggravates when a team might be doing the work as directed by the team at a remote location.

3.     Lack of Visibility

Working from a remote location, it is quite difficult to get good visibility of work happening in other locations, as radiation of information across locations is a huge challenge. This can lead to ‘multiple sources of truth’, which can result in a lot of misunderstandings and unpleasant surprises.

4.     Lack of Collective Code Ownership

Collective code ownership means no single member of the team owns a piece of code – rather the entire team does. This means the code is up for refactoring to all team members.  Implementing this in a distributed environment poses 2 major challenges First, .unless appropriate tools and Version Control System is used, maintaining collective code ownership can be challenge across locations. Second, lack of trust between team members can lead to a highly negative consequence, viz. no code ownership by anyone in the team.

5.     Risk of unpleasant surprises when ‘Everything Comes Together’

When multiple locations are producing work which needs to come together at some point, there is a huge risk of things falling apart, unless Continuous Integration is practiced rigorously. Inconsistencies between locations in types of tools used, an unsuitable Version Control system and lack of common quality standards can become major impediments towards achieving integration which is surprise free.


Reading all the above, it might appear that Distributed Development is doomed for failure. However, many organizations have worked towards implementing measures which significantly help in overcoming these challenges, if not fully eliminate them. I am going to share these best practices in my subsequent posts.









Distributed Development Challenges – Part 1

13 Oct

By definition, Distributed Development is difficult due to the ‘tyranny of distance’. In fact, in the early days of Agile adoption, some purists believed that Agility and Distributed Development could not co-exist, going by the principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Distributed Development is a reality today. In most cases it is a necessity due to some very convincing reasons. Despite all the technology advancements related to communication and collaboration of virtual teams, distributed development still has challenges as people are ‘not in the same room’. Let us examine five of these challenges in this post.

1. Barriers to Communication and Collaboration
Distance between teams not just inhibits face-to-face communication, but poses some additional challenges as well. If teams are working in vastly different time zones, e.g. San Francisco (US West Coast) and Pune (India), the challenge is about overlapping working hours. Either or both sides would have to start work early or end work late, and this can lead to another problem, i.e. resentment.

Another situation can be where both teams are different parts of the world, and their primary language is not the same. E.g. A team in China, whose mother language is Mandarin, while the other is in Brazil, whose mother language is Portuguese. These teams would have to use a language common to both, say English. Given that it is not the primary language of both teams, the ability to communicate clearly and crisply, and keeping an accent as neutral as possible can become quite challenging.

2. Requirements Misunderstanding
In a Distributed Development environment, it is possible that the Product Owner and sometimes even the Business Analyst are located ‘onshore’ while the rest of the team is located ‘offshore’. This can naturally lead to higher documentation for communication requirements, and clarifications over phone. This poses a huge risk of requirements being misunderstood, especially if there is no common primary language.

3. Low Morale
This is typically seen at offshore when onshore has a superiority complex. When onshore team members carry the belief that the work done by offshore team is relatively of low value as compared to their work, they seldom appreciate the team across the shore. This can lead to a feeling of being taken for granted and result in low morale.

4. Lack of Trust
Developing trust between team members is a ‘chicken and egg’ problem. When people are separated by distance, there needs to be more trust between them to work collaboratively. And trust cannot be built between people unless people connect in person and spend meaningful time together. Absence of trust leads to ‘throw over the wall’ mindset and finger pointing when things slip or fail. In this situation, there is a very high risk of negative feedback being given or taken in the wrong spirit.

5. Lack of Co-ordination
This is an important challenge when teams are distributed and have high level of dependencies between them. Imagine a day when a team in Pune(India) leaves behind a broken Build as the other team in the San Fransisco starts the workday. This will result in loss of productivity for the team in San Francicso. There would be very reason to believe that leaving for the day with a broken build was an inadvertent slip up by the India team, it could easily result in US team feeling resentment, thereby leading to other problems like increasing the trust deficit.

Agile Is Not Fragile

10 Jun

Agile Is Not Fragile

Stand Up Meeting Anti Patterns

21 Oct

Stand Up Meeting Anti Patterns

Comparing Business Analysis with Software Process Consulting

17 Sep

Presentation which I delivered at the BA Conference hosted by ThoughtWorks, Pune on Sep. 15, 2012.




Distributed Development Best Practices

12 Sep

Deck which I used for my talk on Distributed Development Best Practices at Agile Brazil 2012 at Sao Paulo, on Sep 7, 2012.Distributed Development Best Practices