This interviewee would only answer the interview questions if I hired him

Over the past 4 days, I dedicated most of my time on resume screening and interviews. It is a boring job but you get some fun out of it sometimes.

So, here's some fun I collected this morning. An interviewee who thought I would hire him straight without asking any questions related to the job.

2011/9/29 Z* H* <*@yahoo.com>
>
> Hi,
> 
> I will be able to answer all your questions in the first day working at your 
> company. 
> 
> Thanks
> ________________________________
> 
> From: Yuen-Chi Lian <*@onapp.com>
> To: Z* H* <*@yahoo.com>
> Sent: Thursday, 29 September 2011, 7:43
> Subject: Re: Application for QA Engineer from H*, Z*
>
> Hello Z*,
> 
> I would like you to answer the following questions before we proceed.
> 
>  1. What does software quality mean to you?
>  2. How... *?
>  3. Do you think... *?
>  4. How... *?
> 
> Regards,
> Yuen-Chi Lian | www.onapp.com
> 
> 2011/9/29 Z* H* 
>
> Good morning,
> 
> Yes, I am aware of it and willing to work hard, whatever it takes. 
> Thanks
> ________________________________
> 
> From: Yuen-Chi Lian <*@onapp.com>
> To: Z* H* <*@yahoo.com>
> Sent: Wednesday, 28 September 2011, 17:08
> Subject: Re: Application for QA Engineer from H*, Z*
>
> Hello Z*,
>
> Just want to be sure, are you aware that this is not a manufacturing QA job 
> but an IT QA job?
>
> Regards,
> Yuen-Chi Lian | www.onapp.com

And here's my response

Date: Thu, 29 Sep 2011 08:33:09 +0800
Subject: Re: Application for QA Engineer from H*, Z*
From: Yuen-Chi Lian <*@onapp.com>
To: Z* H* <*@yahoo.com>
Cc: Malaysia Careers <career-my@onapp.com>

That's very interesting.

But, Z*,

Our team actually built the core logic of the Iron Man's latest armor "Bleeding 
Edge", appointed by Stark Industries after going through their professional 
selection of industrial partners.

We're very serious about QA, as the product is used (and will only be used) in 
critical missions that define the future of the mankind. I urge you to answer these 
questions and hope you understand why and how so serious they are.

Regards,
Yuen-Chi Lian | www.onapp.com

He hasn't yet gotten back to me 'til now. If you have someone better than this guy who is looking for a QA job, or to be a Sysadmin/Java/PHP/Python engineer, let me know at career-my@onapp.com.

Measuring Your Engineers

To say that I am managing an Agile team is not entirely accurate, we are just trying to be agile. Anyway, skipping the story, the team's velocity increased more than 800% for the last 2 iterations, mainly due to management pressure. Put aside other reasons such as requirement gathering, design, headcount, etc.

1. Engineers are most probably working within their comfort zone.

For the past 3 months, I had passed/failed/extended the probation period of the engineers. During the session, they discussed with us their strength, weaknesses and areas for improvement.

2. Most engineers highlighted that they're lacking some knowledge to perform better.

So, last weekend, after having a discussion with the management, I was given a task - create KPIs to give engineers a direction as well as to provide management a way to measure their performance. So there are two things - KPIs and Performance Review. The first thing that got into my mind was - how did my ex-company do it?

In the support team that I worked in, we used a ladder-based system where there were 4 skill levels defined with skills to achieve. We would also set KPIs such as "resolving 30 support cases with customer satisfaction above 75%" or "to be SCJP certified". The progress, results and data would be presented to the management during our performance review. Trust me, people seldom stepped out the room wyith a happy face because the management loved to tell you where you did not do good enough.

I was thinking of the ladder since then.

I then looked into some blogs and Stack Overflow questions, such as this (Joel), this, this (Steve Yegge), this and this, which in general send the same message:

3. Management focuses too much on measuring the performance than improving the products and getting things done.

Something quite similar to this will be - timesheet and the reason I abolished it because it is irrelevant with the team velocity and business values. What does it mean then, shall we not measure the engineers at all? Your HR is certainly expecting some kind of metrics for her as a parameter to make salary adjustment.

What shall we look into then? Let's start from things that we shall never use to measure an engineer:

• SLOC - Source Lines of Code, the dumbest ever metric. Good programmers write lesser lines.
  
• Number of bug fixes - No way! The engineers would have figured out how to compromise this by writing more buggy code. I strongly against this just like how I disagree with giving points to bug fixes.
• Hours logged - Timesheet is a waste of time.

I had like a 10-minute talk with the engineers yesterday to find out how they want to be evaluated and paid. I think this is important instead of me making decision and guesses based on how other software houses do it. It turned out that they want to be reviewed by the peers, by stories delivered, by code quality, and by having salary within different range they expect to be put an expectation on the skill set they possess.

So here is my summary, the performance metrics will be generally based on the expectations, the results, and the feedbacks:

• The rating from their team members.
• The rating from their direct supervisor, basically this person also knows the agility, code quality, velocity, etc. of this person.
  
• The total stories delivered.
• The skill set, which KPIs can be related with this, not entirely though.

Are KPIs necessary? KPIs shall not be mandated, they have to be discussed and proposed by the individuals, based on their comfort level and see how far we want to go above it. If a KPI is not going to help an engineer to produce quality code and better product, drop it. Also, if one doesn't want to play this KPI game as he really has a clear idea about every thing he is doing, don't force him to change the way he handles and manages his job and directions.

The last reminder is that, we shall not expect to have a perfect and fair formula that objectively measure and rate an engineer. Whether someone will be promoted or given a good salary shall be based on human judgments, as we are dealing with humans and humans make important decisions like you always do.

Working on Branches and the Stable Trunk

I used to work on the trunk because for all the projects I worked on, it's either I was the sole developer or the team ensured that everyone code check-in has passed the local tests. Otherwise, we created (we still) branches for bug fixes, large code for new features, etc.

About 2 months ago, I had a short git session with Kamal and he shared with me the idea of story/branch. And as my team started to grow with more dev guys, I feel the need of encouraging more branching and now this has become a rule. For a project with automated tests defined with CI set up, a stable trunk is guaranteed and this practice can fit very well into it.

We don't use git but Subversion because that's how we started and we are still comfortable with it now (most of the time).

If you have a working copy on trunk, here're some simple steps to switch to a branch (svn switch won't work):

svn cp https://repo/trunk https://repo/branches/module-version-storyname
cd /path/to/trunk/working/copy
svn diff > /tmp/diff
svn co  https://repo/branches/module-version-storyname
cd module-version-storyname
patch -p0 < /tmp/diff

RE: Rethinking Software Development

My colleague David wrote a thoughtful blog about maximizing quality by increasing software development time, do take a look at it here.

Test-Driven development (TDD) and continuous integration (CI) are not new terms but they could be in Malaysia (generalizing based on the number of software engineers that I have met), or people (managers and developers) could just think they are something impractical in terms of meeting the project's deadline and such.

They should find out about the "Broken Iron Triangle" too.

- yc