Avoid asking hypothetical questions in interviews

I have taken part in many interviews as interviewer and interviewee. I have seen many interviewers ( including me ) ask many  hypothetical questions especially for management positions. 

Hypothetical question example :

When one of your team member does not show up on time for work, how will you handle the situation ? 

The interviewee usually comes with a textbook answer. Something like , 

I will talk to him/her about him/her not showing up on time. 

This is a very good answer. But this answer does not mean that the interviewee has any experience handling these kinds of situations. It just means that the interviewee had read some books about management. So instead of asking hypothetical questions, we should be asking "behavior description questions" . 

For example instead of asking 

"When one of your team member does not show up on time, how will you handle the situation?" , 

we should be asking 

"Tell me about a time when one of your team member was not showing up on time, how did you handle that situation?" .

This way of questions will help interviewee to explain how they worked in their past instead of coming up with some hypothetical answer.

Letter to managers

Dear Manager:

Before you judge who I am and what I need to change. Give me an opportunity and see how I do.

Thanks,

Subordinate

Do we need a Tech Lead role ?

I have been thinking about whether we need a tech lead role for sometime. But now, I have come to a conclusion that tech lead role is unnecessary. Let me list my reasons, why I feel that way.

1. Instead of a tech lead , we need a person to act as tech facilitator. This role should be rotated among the team members in weekly basis or biweekly basis. The main responsibility for Tech facilitator will be to resolve some technical conflicts within team by facilitating a discussion where advantages and disadvantages of all approaches are discussed and decision is made.
2. I strongly believe the person with a strong technical expertise will be recognized by the team itself. We do not need to appoint a tech lead. Team members will go to a person who they trust as expertise in that technology. So there is no need for a technical lead role.

So instead of we pushing a person as a Tech lead to a team, I think we should let the team organize itself.

Waterfall is perfect (with some assumptions)

I took "Software development life cycle" course in my school long time ago. It was an interesting course as it was the only course that explained software development process from one level up compare to other programming courses. As a part of the course, I learnt about Waterfall process and different phases in waterfall process. At that time, I felt that Waterfall process is so simple and perfect. 

1. We gather ALL requirements
2. We design the ENTIRE system to attributes and behaviors level in classes
3. We code those designs
4. Test the system
5. Ship or release it.

I felt waterfall is the way to go. It is amazing yet simple. It has less steps than making chicken soup.  Waterfall process can never fail, but there is a catch. Waterfall process has many assumptions and some of them are,

• Requirements never change
• Design is perfect
• Coders can easily implement those designs
• Defect fix will not have much impact in the design as it is perfect.

These assumptions can never be true. In waterfall process, we never consider these assumptions can be wrong. We do not consider them as risks. I think this is the biggest flaw in waterfall process.

Now lets look at some assumptions made for agile process.

• Requirements will change
• Design will evolve and change as we gather more knowledge

As you can see assumptions made in Waterfall process and Agile is totally different. It is these assumptions that make such a difference between agile and waterfall. It is not the phases. In both agile and waterfall we will have requirement , design , coding and testing phase. 

In agile because of its assumptions, these phases are done quite differently from waterfall process. 

Requirement Analysis:

In agile we embrace change and expect requirements to change unlike Waterfall process. So expecting change in requirements, we do not do too much analysis. We do analysis only when it is needed. The advantage is as you wait till the last moment, you can use new knowledge that you have gathered about the system. 

Design and Coding:

In agile, design and coding phase happens in quick sessions that it looks like a single phase. As developers expect the requirements and designs to change they make sure they have good test coverage as a safety net. As they have good test coverage, they are not afraid to change their design or code. They do not spend too much time designing for future (which will be different anyway). They get things done with the information they have at that time.

Testing:

Defects found at this stage would not have much impact in the system as all other phases are expecting things to change. So there is no surprise. 

Workflow:

As analysis is done only when needed, there is less features for developers to design and code. As  only few features are implemented, there is less features for testers to test. So all these phases are done in a very fast rate. Mostly within a week or two. They keep doing them again and again till the customer is satisfied.

As you can see, some simple assumptions can change the whole software development process. So more than anything else, your assumptions will determine whether you project will be waterfally or agilely.

Please teach me rspec

I was first introduced to BDD like 4 years back by Dave Astel's article. I really liked the idea. It totally made sense to me. I was like damn this is the way we have to think for designing objects. That time I was working in a java project. Igor and I were like okay lets do BDD and started naming our Junit test methods like testDogShouldBarkWhenThrownStoneAt . When jBehave released I wanted to use it, but I never got a chance.

When I started working on yewoh, I was so excited that now I can chose whatever framework I want. Being a BDD addict, I obviously chose rspec. It is a great framework for doing BDD.It gives you nice syntax to express behaviors in "when" and "should" format .It felt very natural for me to write verifications for verifying my object behavior instead of tests.

Now after using rspec for sometime, I have some questions about rspec.

• What is the best way to organize specs? In rails project, specs are arranged in folders like models, controllers etc. I do not have a problem arranging the spec files, but I am not sure how to organize specs itself. Does anyone has some good practices that worked for them?

• Sometimes my objects have behaviors like "Player When power is on It should start playing When play button is pressed " . In this behavior I have two When conditions. How do you express this behavior in rspec ? Should I have it like

describe Player, "When play button is pressed"
    it "should start playing if power is on"
      ....
   end
end

using a if condition. Or should I have something like this

 describe Player, "When power is on and play button is pressed"
   it "should start playing"
     ...
   end
end

• In unit test, usually we write tests to make sure our method do not blow up when we pass nil for example. I feel it is a good test to have. How do we writes spec for this kind of situations?  

Rspec documentation has good explanations and examples for rspec syntax. But I am looking for best practices for using rspec.

It will be great if you all share your experience with rspec.

Do we need Iteration Planning meeting?

Iteration Planning Meeting (IPM) is becoming a controversial topic. In one side , some people feel IPM is a must. In other side, some people feel IPM is not needed. I have friends and people whom I appreciate in both sides. According to me, I feel IPM is needed (not a must) but in a different form.

These are the activities that usually happens during a typical IPM.

• Showcasing (Demo to customers)
• Retrospect
• Story presentation
• Story tasking and estimating
• Planning
• A little celebration for finishing an iteration.

In those activities I have mentioned above, I am not convinced that some activities should be part of IPM. Let me explain one by one.

Retrospect:

Retrospect is where we collect knowledge to eliminate waste. We can retrospect what things worked and what did not work. The problem I have is why cannot retrospect be an ongoing activity instead of just happening during IPM ? We can have a board where everyone in the team can add things whenever they want that they like or do not like. The board will be always up to day. In daily standups everyone can discuss on issues that are very critical.

Story presentation:

Story presentation is where a analyst will present what a story is all about. Developers can ask questions to understand about what is expected out of that story. This is a very useful activity, but again why it has to happen during IPM. Story presentation should be postponed till some developer is ready to work on it. That way we can use new knowledge that we acquired in the past few days working with other stories.

Story tasking and estimating:

Please look at my other blog, where I have discussed the importance of tasking. Again like 'story presentation' this activity should be done at last possible moment (ie.., when developers are starting to work on that card) instead of being done during IPM.

Planning:

Planning is something that we can never avoid. Planning has to happen. But we should understand that planning is not a commitment. We should be willing to change our plans as we gather new knowledge. Planning for short term should be more towards what is next three stories (keep this number as low as possible) that I wanted my team to work on. Things change so fast and we gather so much more knowledge in a short time. So planning should be a continuous activity rather than being done only during IPM.

Now our new form of IPM will have only these activities,

• Showcasing (Demo to customers)
• A little celebration for finishing an iteration.

Ideal situation:

In a ideal situation, customers will be always sitting in your team room. Whenever we have a story done, we can deploy to a demo machine (which is very close to production system ) and demo it to the customer. In this scenario, celebration is the only activity we will doing during IPM.

Reality:

In reality, not all customers will be sitting in team room. So we need a scheduled time to demo the stories you have done to get feedback from them. So we will need IPM , but in new form.

Hope and Change

Enterprises are comfortable to use Java or C# as there are corporate backings for these languages. But for ruby there are no corporations backing it up. In this case, I was not sure how successfully Ruby will become in enterprises. I do not think a big health care system will be implemented using Ruby in near future. I really wanted to see Ruby become more mainstream, so we can build applications that have more impact on people's life rather than just social network site. That is why I wrote my previous blog "Who is responsible for Ruby?" to get an idea of what others think.

After talking to some of my friends and thinking over this weekend, I feel Ruby will soon become mainstream. Enterprises will start using ruby. But I think this change will not come in a traditional way. This change won't happen because some big corporation started backing up ruby. I think this change will happen because of Ruby community. Eventually enterprises have to start using ruby because of its wonderful developer community otherwise they will be left out.

To sum it up,

"Ruby is a grassroots movement to change Enterprises"

Who is responsible for Ruby?

In Qcon London 2008 conference , I attended a panel discussion for what type of projects should we use rails. As one of the audience mentioned during the discussion, that all the panel members were pro-ruby :) It is not a big deal, but I just thought it was funny. I have lot of respect for all those panel members. 

The discussion for some reason was totally off topic. Probably the discussion about what types of project can be implemented using rails happened like 5% of time. Most of the discussion was about why nobody from ruby community was worried about ruby running so slow in Windows. Someone from audience mentioned if Ruby community wants ruby to become mainstream and accepted as a language by all enterprises, it should run faster in Windows. Panel members said that they do not really care that much about ruby getting accepted in Enterprises. They told that they are doing it because Ruby as a language makes easy for them to solve the problems.

I totally accept that. If I find a language that is helping me to solve a problem more eloquently, than I will use that language. I do not care whether that language will be accepted by all big enterprises or not. If there is someone smart in those enterprises, than s/he will decide what language is good for solving their particular problem.

But one question enterprises will be asking, "who is responsible for RUBY ?" so that they can blame them when something goes wrong.

5 Reasons why I hate Basecamp

I have been using Basecamp for my project management for sometime now. I have to say I hate it. I really like what 37signals guys do, but I was disappointed with Basecamp.

Without any further ado, let me list 5 reasons why I hate Basecamp

1. Navigation

I get lost so easily in Basecamp. There are no breadcrumbs in any pages. For example, I have a page for our iteration planning where we list all the stories that go into that iteration. These stories are listed as links to other writeboards in the project. When I click on any of these links to view a story there is no easy, intuitive way to navigate back to the iteration planning page. When I click on browser back button, it just refreshes the current page. The page has a link to "Go Back". When I click on that click instead of taking me to the iteration planning page, it takes me back to list of writebroads. I am not sure if this is some configuration problem from our side. But again I don't think this should be a configuration.

2. Loading Writeboards is very slow

3. Search is useless

Search does not search writeboards.

4. Wiki support is aweful

Compare to Confluence or other wiki tools that I have used, Basecamp support for wiki text is inferior. Even Wikipedia has better support.

5. Does not handle big projects well

Organizing things in Basecamp is a pain. I have no way to tag or search writeboards.

Einstein had a famous quote - "Make everything as simple as possible, but not simpler" . I think they missed the second part of that sentence.

Ruby is more object oriented than Java!

This simple example proves that Ruby is more object oriented than java.

To find absolute of a number,

in Java we need to use a separate class - Math.abs(-24)

but,

in Ruby abs functionality is built in the number - -24.abs