Quotes 2011

Some quotes that I came across this year. They motivate me and I try to learn from them:

1. Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot it becomes the teapot. Now, water can flow or it can crash. Be water my friend. Bruce Lee.

2. What is your dream? And knowing this, what have you done to work towards realizing it today? -- Les Brown

3. Habitability is the characteristic of source code that enables programmers, coders, bug-fixers and people coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently. [...]Habitability makes a place liveable, like home. And this is what we want in software – that developers feel at home, can place their hands on any item without having to think deeply about where it is. -- Richard P Gabriel, Patterns of Software.

4. Never interrupt your enemy when he is making mistakes. -- Napoleon Bonaparte.

5. I hear and I forget. I see and I remember. I do and I understand. -- Confucious.

6. “In the beginner’s mind there are many possibilities, in the expert’s there are few.” – Suzuki Roshi
7. "Thought is useful when it motivates action and a hindrance when it substitutes for action."Bill Raeder
8. Success is not achieved by doing the largest project, but by doing the project that provides the most value for the customer, leaving time for software developers to work with other customers with real needs. This strategy is strongly supported by Scrum

Qualified Professional Scrum Master -I

I have since long used Scrum in various forms but never got “certified”. Then I came across http://www.scrum.org/onlinescrumcertification/ and reading through this and its reviews I was really tempted to see how much knowledge I had. I attempted the free Assessment and got only 74% marks (qualifying marks were 85%). Now I knew that I may be distorting Scrum unknowingly and I went through the Scrum Guide seriously and was enlightened in many ways. Took the test almost 10 days later and passed with 91% marks.

So, I am a Professional Scrum Master -I that is good to hear, but in addition I came to know what mistakes I was making in implementing it in our team and coincidentally we are starting a new Sprint on 10Jan2011 and I would ensure that those mistakes are not repeated.

Inducting Interns

We decided to offer three candidates internship. They are all MCA final year students who have 6 months of industrial exposure as part of their curriculum.

I made a decision to ask the current engineering team to select the three individuals from a pool of 13 in a single day. We had an aptitiude test, a simple Java test including a small program writing and a general question paper to judge the clarity of the individual regarding training followed by an interview taken by the three engineering staff.I also sat down with the engineering team to come with a probable plan of study and project that should help them cover the curriculum needs and also know how software development happens in our company.

The three interns joined us on 03Jan2011. If end of 6 months we have any open vacancies should we provide these three individuals a first shot at it? I am not sure, but I think it is better to evaluate a person in 6 months than in 60 minutes. Let us see how it goes. The only thing that I plan to gurantee is that they would have good exposure to working in teams than their colleagues.

Engineer supposed to join does not turn up without information

Last month, after around 4 weeks of interviewing we zeroed down on an engineer and gave him an offer letter. He came and accepted it and also accepted the terms and conditons which included a 12 month compulsory stay with the organization. He talked, discussed, shared email ids. He responded with all needed documents to HR but during the 30 days between the offer letter and joining date kept us in the dark as to his intentions.

A day prior to his joining all email-Ids, domain login, machine was setup and this fellow did not turn up. Today after 10 weeks we still do not have engineer on board. This is hugely disappointing. I wish he had been professional enough to have informed us and so that we could have searched for a new candidate.

I have no ideas, how to avoid such situations and I do not want to lift the 12 month compulsory stay terms & conditions as I believe that we as an organization invest enough in an individual that he should commit to this minimal time frame. We do not hide any details as to what we do, what platforms we work on, type of work etc.

My thoughts are weening towards hiring Interns --- at least they assure me of 6 months availability and then give offers to the top ones at the end. By that time the intern has seen the working of the organization and can take a quick decision to join or not. Given the resources that I see during the interviews, I think this is also a good way to give back to the society at large – an engineer who is ready for the Industry. I will blog about the experience later ...

Continuous Learning, and Quicker Delivery

I consider that there is a strong relation between “Continous Learning” and “Quicker Delivery”.

Most of the time projects / products or a company's /team's usage of technologies is a set of few items. With the areas of work defined it should be every team member's endeavour to master these areas so that when new tasks come up the team member's have broad knowledge if not in depth knowledge of how they are to be accomplished.

My peeve against majority of software professionals is that they do not spend this time learning and end of the appraisal we find that we can still not do tasks faster or with higher quality leading to frustration of the “Product Owner” who expects improvements for the yearly financial raise provided. This also leads to individuals who have “gained experience in number of years”, but not in type and complexity of tasks performed.

One of the reasons provided by the individuals is that they do not get any time. Unfortunately, even on teams that I have restricted to 45hrs a week work these reasons are spoken of. I feel it is a necessity of all software professionals to continously learn so that they do not forget the “art of learning” and in the process become obsolete in the times to come.

Should Developers Buffer Estimates?

We use a typical Agile methodology during software development. During Iteration Planning engineers want to buffer/pad their estimates. Their logic is that something may come up! This leads to:

• Obviously, bloated estimates.
• Bloated estimates even on predictable tasks.
• No visibility to what type of issues we tend to miss out while estimating (as everything is lost in the buffers)
• Work expands to fill the time we have.
• Reduction/Destruction of trust with the Product Owner.

My questions against this is How do you know that the buffer you are keeping is adequate for “something may come up? How can you estimate an unknown? My recommendation is to base the estimates on the current knoweldge of tasks and its delivery with Quality. For other things that crop up we manage as and when we see the unknown.

If an unknown does crop up the “rule of the book” is that the Product Owner should be considerate enough to drop the low priority user stories. But the reality is that many of the Product Owners do not agree. The role of the Scrum Master at this time is to convince the PO or move the equivalent tasks to the next Iteration. This does not come easy to non-Agile PO practitioners but is the only way to prevent drop in Quality of tasks or slippage of schedules.

One way to make this scope adjustment easy was used in one of my previous organizations by marking the features as “Must Have”, “Should Have”, “Nice to Have”. My issue with this is that this again leads to “Work expands to Fill In the Time”. The devlopment team ends up consuming most of the time in “Must Haves” and scope adjustment needs to be done there.

The retrospectives at the end of Iteration are the right time to relook closely at those tasks where we did a bad estimate / found unknowns to find what type of issues/work we tend to overlook. This is the learning which if taken forward helps the team to do better estimates as well as points to development/learning areas for a team.

In a nutshell bufferring brings opaqueness to the development process and needs to be avoided.

As a side note one of my engineers came up with – buffering is also done because it is driven by the year end Appraisal process which may have heavy weightage for “Timeliness of tasks”. The fix for that lies both with the engineer and his manager. The manager and engineer should collaborate to see where the estimation errors come from and thus over a one year appraisal cycle we should see statistical averaging helping in some tasks finished ahead of schedule and a few late but overall project timelines being met.

How a new joiner can get to speed quickly...

As per my experience there is a big chasm between the academics and the Software Development industry in India. I have my theory for why it exists (a topic for a seperate blog).

But, I do wish that the new engineers that are recruited (some of them months in advance from campuses) spend some time getting ready for the industry before arriving on their new jobs. I have seen many engineers who may have scored high in aptitude tests etc. arrive on their jobs with no effort put in to get ready for the work. Many of them have the attitude “employers should provide training”. This may be fine with those who join the big companies like Infosys, TCS, Wipro who can pamper them for some months before assigning tasks but for the majority of smaller sized companies in India it is discouraging to see this attitude.

Following is my wish-list from a new joiner:

• Should have basic knowledge of the languages that the organisation works with (this must have been told during the interview or asked/researched by the person).


• Should know and used at least one Version Control System.


• Should have a “team mentality” instead of being an individual player.


• Should know when “he is stuck” or “when he needs help”.


• Should interact and communicate with peers and superiors (also helps out in 4).


• Should use the platforms provided in the organisations (meetings, information sharing sessions etc.) to expand his skills.


• Be passionate about any task assigned. Yes, you would some day architect a huge application, but you will have to prove your worth in smaller tasks first.


• Be open to challenging (though with facts & figures) ideas, processes followed.

Unfortunately I find many a times these skills lacking even in experienced candidates. If these points are conciously taken care the person would quickly feel at home in his new assignment and start liking the work and being effective quickly.