Obviously stating the obvious and restating the evident - Part I

Sailor: Did I ever tell ya that this here jacket represents a symbol of my individuality, and my belief in personal freedom?
Lula: About fifty thousand times

David Lynch’s  Wild At Heart

A manager’s instruction is almost never executed. The obvious things are never obvious.

Jack Welch explains In his autobiography, that it is not enough for a manager to make a decision. It needs to marketed, explained, exemplified, and personally demonstrated repeatedly if there is any chance to make it effective.

This is even truer in high-tech where people are very smart, opinionated and independent. While it is common in Israel, I have seen the same phenomena in Belarus and San Francisco.

Jerusalem Freedom Graffiti

Let’s take a look at some simple, pretty obvious decisions, a manager can make.

Ignore for a second your own sentiment about the wisdom of the actual decision and focus on the implementation conflict.

• Sales meetings are documented in SalesForce.com
• We do code reviews
• Our dialogs will be using capital letters for the buttons
• We use a consistent terminology across our system
• We do unit testing for our code
• Development team leaders review QA test designs
• Critical bugs must be fixed for code freeze date
• Should write all our word documents with the organizational template

Now, assume the manager reads out loud all these statements during the weekly company gathering.

What are the chances that the guidelines will be implemented?

In many cases, if not all of them, the answer is no chance at all.

Let’s walk through a code review implementation process.

Phase 1: Denial

Manager: Did we do a code review on the new “Task Manager”?

Team Lead: No.

Manager: But we decided we do code reviews, just last week.

Team Lead: Oh, I didn’t remember that.

Phase 2: Omission

Manager : Did we do code review on the new “Task Manager” ?

Team Lead: Yes.

Manager: Who did the code review?

Team Lead: I asked Mark to review Jane’s work.

Manager: And how did it go? Did he find any bugs? How much time did it take?

Team Lead: I’m not sure on the exact details, they didn’t complain.

Code Review ?

Phase 3: The Gory Details

Manager: Do you have the details now?

Team Lead: Yes, they went over the code and didn’t find any issues. They thought it was quite pointless.

Manager: How much of the code did they cover?

Team Lead: They just browsed through the module together and it seemed OK.

Manager: I want all new code to be reviewed. I want the reviewer to be a team leader. I want the reviewer name on the commit and I want post mortem analysis of every bug, to see why we didn’t locate it in the code review. No code is to be committed without code reviews.

Phase 4: Threats and Conflict

Manager: How are the code reviews been going for the last week?

Team Lead: We didn’t get to do it this week. We were busy writing the “ControllerFreak ” project. We will complete the reviews next week.

Manager: But I told you not to commit any code without doing a code review. Didn’t I?

Team Lead: You have. But there were a ton of things to do and I used my best judgment as a practiced professional and decided that from the universal optimization perspective it is better that we postpone it to next week. We would have to do a lot of extra branches if we could not commit and that would be really annoying.

Manager (Shouting): Let me make myself clear. I want all new code to be thoroughly reviewed according to the ten guidelines I will publish. No code will be committed without my approval. I really, really, really mean that you must always, in any case, whatever happens, perform a serious, complete and high quality reviews. Or heads will fly!

Team Lead: Oh, I see. Why didn’t you just say so in the first place?

Continued in part II.

About these ads

Tags: Business, Code Review, David Lynch, developer, Jack Welch, Management