Selling unit testing to managers/executives

A few years ago, I had to defend to an executive the extra cost of implementing unit tests in a project compared to the return it would give. This was during an architecture board meeting and he pretty much caught me off guard, so I had to come up with something really quickly.

Luckily I remembered an article I read a long time ago that compared Japanese and English players in the automotive industry. Overall during the sixties and seventies (maybe even eighties), Japanese built cars were of a higher quality than the cars built in the Western world. The amount of 'broken' cars produced by American or European were incredibly high compared to what Japan produced. Those cars could not be sold as is and had to be taken apart and repaired while they haven't even left the factory, which was very expensive!

To explain unit testing to the executive, I told him the above story. Then I elaborated on the way Toyota solves this by implementing something similar to 'unit tests' to test the quality of the most recent addition in the intermediate product (i.e. unfinished car). They prefer to stop the process and rather get the quality right the first time than to take apart the car at the end of the line for reparation, which is obviously very costly. This saved Toyota a lot of money and made them much more productive at the same time.

By comparing this to a more easy to understand case and showing the financial benefit using unit tests had, the executive was immediately convinced. I didn't even have to give figures, because it made so much sense. He didn't know that Toyota did this and was even surprised to hear it.

I never found back the article, but I did find a book on the Toyota way (http://www.amazon.co.uk/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/) which elaborates more on the case above and also elaborates on how Toyota works in general, which is also a very interesting read. They might have to re-read it themselves considering the recent events/recalls ;-).

Principle 5 is the one I am referring to and here is a summary of that principle:

Principle 5. Build a culture of stopping to fix problems, to get quality right the first time.

• Quality for the customer drives your value proposition.
• Use all the modern quality assurance methods available.
• Build into your equipment the capability of detecting problems and stopping itself. Develop a visual system to alert team or project leaders that a machine or process needs assistance. Jidoka (machines with human intelligence) is the foundation for “building in” quality.
• Build into your organization support systems to quickly solve problems and put in place countermeasures.
• Build into your culture the philosophy of stopping or slowing down to get quality right the first time to enhance productivity in the long run.

You might argue that Toyota was rather doing integration tests instead of unit tests, but for an executive this is pretty much the same. Hope this helps whenever you have to defend unit testing in your company!

Separating the sheep from the goats during an interview (part 1 - Learnability)

I previously talked about the perfect CV and how an applicant can survive an interview. Although both posts are more oriented towards candidates, they are also useful for employers. When you receive a CV that is written as it should be and when a candidate can act normal without suffering too much from stress, you are already halfway in evaluating the candidate. In this post, I want to go deeper in what -in my opinion-  a company should look for in an ideal employee and how to test this during a one hour interview.

How can you actually evaluate a candidate in one hour?

During the interview, I always let the candidate elaborate on his latest job/function and only explain the content of the job at the end of the interview if he is actually a worthy candidate. Most of the times I already interrupt him during the first few minutes to steer the candidate towards the things I want to know that are important for the job and to look for the 3 major qualities I look for in the ideal candidate.

1. Learnability

2. Responsibility

3. Social

In this post I will elaborate on the first quality: learnability. In next posts, I'll go deeper into the other two qualities.

Learnability

Learnability is all about being smart and the willingness to learn. Being smart is not enough by itself. I rather check the learnability as a whole of the candidates. They should be smart to be able to actually understand things AND should also be willing to learn.

How do you test smartness? I always have a question in my sleeve that can easily be answered at first sight, but which will be used as a trigger for a lot of follow up questions. If they know the answers, good for them, they'll get the next question that builds upon the first question and the answer they gave. So far, we probably are testing their encyclopedic knowledge, things they know already anyway.

It really gets interesting when they do not know the answer immediately. This is where you go beyond encyclopedic knowledge and can see if they really understand what they are talking about. Just give them the answer yourself, explain it in detail and look if they can follow. You may explicitly ask them if they understood the answer. Then you can hit them with another question that builds upon your own answer. Look at their reaction. Have they really understood everything you said? Do they ask questions themselves to follow your reasoning? Can they reason with you? Can they actually answer the new question or do they blank out? Even if they can not answer again, do the same again, give the answer yourself, explain it in detail and hit them with the next question. See how far you can go. If you can see that they stick with you until the end and they don't get frustrated or completely blank out, you got a smart person in front of you.

Don't try to be too smart with your questions though, you could end up like Google expecting an answer which is in fact wrong on a question they ask during interviews:

http://www.thebigquestions.com/2010/12/21/are-you-smarter-than-google/

http://www.thebigquestions.com/2010/12/22/a-big-answer-2/

Just choose something quirky or not so obvious you encountered in your own experience.

Being smart does not mean they are actually willing to learn new things though. To test their willingness, I ask what they do at home to stay up to date, are they reading articles, blogs, sites, books, etc... in their free time? Even if they only do this during their daytime job, reading a blog or article does not take a lot of time and keeps them sufficiently informed of what is happening in their domain of expertise. If they do stay up to date, I always ask them to tell me something about the things they've read and what they like or don't like about it. What are the evolutions? What do they think what the future brings?

Learnability might be a knife that cuts on both sides. If you have a lot of people with high learnability, they might never get things done, because they are always looking for the next best thing and never finish their actual work. You might not always need people who want to learn all the time. Sometimes it is sufficient that they are smart enough to understand the task at hand and make sure there is a smooth continuation of existing tasks. More on this when I talk about responsibility.

I generally reserve 20-30 minutes for this part during a one hour interview, because I think this is really important.

In a next post I'll go deeper into responsibility. If you think you're learnability is high, you are already one step closer to working for us.

A foundation for writing guidelines

I've been several times in a situation where I had to write guidelines for one of our clients . Guidelines, instructions, procedures, protocols, ... some seem more strict than others, but they all suffer from the same problem: how to clearly indicate the do's and don'ts.

A few years ago, I got inspired by what is known as an RFC (Request for Comments) in the internet world. Very roughly speaking, RFCs describes how machines must communicate over the internet. One RFC in particular (RFC 2119), written by Scott Bradner from Harvard University, describes some key words to signify the requirements in a (RFC) document.

Although the RFC clearly states that "they must not be used to impose a particular method they must not be used to try to impose a particular method on implementors where the method is not required for interoperability" (roughly speaking for the internet again), I found them very useful for guidelines in general.

The key words are as follow (excerpt from the originial document):

1. MUST - This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
   
   
2. MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
   
   
3. SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
   
   
4. SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behaviour is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behaviour described with this label.
   
   
5. MAY - This word, or the adjective "OPTIONAL", mean that an item is truly optional.  

Let's look at a simple example of how these key words can be used in practice. Although I don't have grass in my own garden, I found a simple article on "How to mow grass like a pro" with some straight forward instructions on - you guessed it - how to mow a grass like a pro to make it truly look slick. Here is the adapted version that uses the key words to emphasize certain points on what to do and what not to do:

1. The lawn MUST NOT be wet before mowing grass. Being wet only causes grass to clod up and create mounds of grass through out your lawn. When cutting grass when dry; the clippings spread out evenly, and fall into the lawn and disappears. Of course this depends on how high the grass is before cutting. If grass is exceptionally high, you SHOULD bag the grass and dispose of it.
   
   
2. You MUST NOT cut grass too short. Mowing grass too short allows you to possibly scalp the ground and leave dead spots. As a safe measure, you SHOULD cut grass at about 2 1/2 to 3 inches to be safe. Some even prefer 3 1/2 inches. Depending on how level the ground is; if there are unlevel mounds and drainage trenches, you SHOULD consider cutting as high as possible to avoid scalping.
   
4. You SHOULD mow grass before weed eating or trimming. 
5. This will enable you to make sure you will not have to go over the lawn twice. By weed eating after you mow; those corner spots will stick out like a sore thumb, and you will be able to do a more professional job and not miss anything.
6. 
   
7. A choice of weed killer can be a number of brands. When you choose a weed killer, you MUST be sure you mix it properly. You MUST read the instructions on the label for mixing it correctly. You MUST NOT spray if the wind is 10 mph or above. You MUST NOT spray around young shrubs and flowers, large trees will handle these weed killers, but take precautions anyway.
8. 
   
9. You SHOULD spray around your home and barns or storage sheds. You SHOULD spray about 3 inches wide. This will look neat and will not leave a wide dead space that is ugly. You SHOULD NOT spray weed killer in drainage areas on your property, this will only cause erosion eventually. You MAY spray ditches but be advised to only spay the very bottom, you MUST NOT spray the sides.
10. 
    
11. You MUST use an edger for your side walks and walk ways. You MUST NOT spray these areas or even weed eat them. This will only cause the edge of the grass to get wider, and will not look professional. Edging these areas will have a neat straight look
12. 
    

This looks like overkill, but by using the key words, you make sure that no misinterpretation is possible. Although using the key words does not prevent you of adding arguments or elaborate some parts in the document to clarify things. The key words are there to make sure the requirements are well understood.

All guidelines I write now are superseded by a chapter (eg. "Keywords to indicate requirement levels") describing the above key words. Throughout the whole document, I apply the key words consistently to emphasize requirements in the document. The key words are also in uppercase to even emphasize them more.

It is now much easier to write more to the point and stricter guidelines, without sounding arrogant. By describing the rationale behind the key words in a introductory chapter, they are perceived as a formal part of the document and not as me pointing with a finger.