Talent & Quality of Software Deliverables - 2

How does one recognize talent?

The first step is to be aware of what talents you require. In my previous post I had identified talents I wanted for the programming tools business unit. I had also mentioned what was expected of specific talents. The way I did it was to work from the process practices that we needed to adopt. (I shall post these practices in a later post.). The process practices were in turn based on our business reality. What was our business reality? It was defined by:

1. Programming tools  have a long life. These required to be maintained over many generations of developers. In the tools BU Maintenance is Renovation.
2. Optimizing compilers are complex. Complexity leads to difficulty in maintaining them.
3. Turnover of personnel.

Therefore, to ensure quality of deliverables it was important to maintain a pipeline of new developers who had to be trained and inducted into the teams.

To identify talents at the entry level it helps to have an internship program. The longer the internship, the better the chances of determining if the required talents are present. MCA programs require a final semester of industrial experience. That is a very good opportunity to check for the talents I have listed in the earlier post.

The normal interview process does not have enough time for determining talents. However, for companies that can afford them, hiring qualified psychologists as consultants to test for the required talents, could be an option.

In either case it is absolutely important for managers to continually monitor the performance of all their team members. They must see that required talents are indeed being displayed. If any previously unspotted talent is noticed, it must be discussed with the person. All should be provided feedback. I believe in highlighting both desirable and undesirable behaviour to the whole team. And as close to the episode as possible. That way everyone learns what is the expected behaviour.

Most importantly, the annual (at acmet it was bi-annual) assessment must be designed to evaluate the behaviours which are evidence of the desired talents. At acmet our assessment forms did that.

Talent & Quality of Software Deliverables - 1

In Apenndix C of their book, First, Break All the Rules: What the World's Greatest Managers Do Differently, the authors briefly describe the talents that are found most frequently across all roles. They classify them as Striving Talents, Thinking Talents, and Relating Talents.

Striving talents are what drives a person. Thinking talents are thinking patterns, frameworks, view points, which come naturally to a person. Relating talents are how a person engages with others.

For entry level for business unit that I headed, the talents that I would look for are:

Striving Talent

• Ethics: Total honesty about work done.
• Belief: In the values of the organization
• Service: A readiness to put team before self
• Acheiver: A drive to meet commitments.
• Competition: This is a no-no. See relating talents

Thinking Talent

• Discipline: Structure in planning and executing commitments, and in writing code
• Focus: On meeting commitments and not getting diverted by interesting side issues.
• Problem Solving: Construct experiments to learn about problems. Devise tests to validate unserstanding. Recognize patterns.

Relating Talent

• Team: Be a team player. Support others. Be ready to take on extra work to help out others going through a difficult patch.
• Empathy: Be sensitive to feelings of others. Review comments should not be personal. Information should not be delivered in a manner that seeks to run down others.
• Persuasion: Use logic - not prejudice, nor authority, nor  politics - to convince team members during reviews of project artefacts.
• Developer: Educate new members of the team. Share information. Involve less experienced persons in the discussion and explain the discussion. Help others learn. Do not form cliques. Document code and tests so that future team members can learn.
• Multirelator: Build relations that are not based on langauage, region, caste, or political affliation.

Realting talents I hold to be the most significant.

My experience had convinced me some time ago of the kind of person we should be selecting for the business unit that I headed. I have linked that to the some of the talents mentioned in the appendix of the book. I wish I had read the book a few years back. It would have enabled me to craft a better selection, assessment and retention scheme.

So how does one identify the talents that I have mentioned? I propose to deal with that in the next post.

Discipline & Software

Discipline calls to mind regimentation. Discipline therefore is not commonly associated with creative activities. That is unfortunate. Any craft, or art, has its own discipline.

Discipline does not constrain creativity. It liberates it from the tyranny of the minor error. It saves time and energy.

The sole justification for discipline in the military is that it saves lives.

The sole justification for discipline in software development and maintenance, is that it as it prevents defects.

See Edsger W. Dijkstra's "A Discipline of Programming" for a description of the mental discipline required for programming.

Talent & Quality of Software Deliverables - 0

A few weeks back, I finished reading Marcus Buckingham's & Curt Coffman's first break all the rules. I found it very thought provoking from the perspective of someone who has built and managed software teams.

They define four key activities of a great manager: Select for talent, define outcomes, focus on strengths, find the right fit. Except for the second, the other three are about talent.

Talent is, as they describe it,

" a recurring pattern of thought, feeling, or behaviour that can be productively applied".

These patterns are formed early in life and become progressively harder to change. By the time one is getting out of one's teens they are fixed for life.

Therefore, when selecting an entry level software engineer, one must be very clear about what talents the organization expects of a software engineer. What it expects has to be based on what are the organizational values and culture (more on values and culture in a subsequent post). Values and culture decide how the talent will be used. A person may have a talent for problem solving. The problems the person likes to solve is decided by the person's values. No company wants problem solvers whose values do not prevent them from hacking the company's accounting system.

In appendix C the authors list some talents which are most frequently required across different roles. In the next post I will discuss some that I would look for in selecting at the entry, and team lead levels.

Documenting Source Code - How It Was Driven Home to Me

This happened almost two decades ago. It was my first startup. We had built a radar Moving Target Detector using four DSP processors, plus another DSP as a controller. I had taken it from proof of concept, to field trial, to ruggedized prototype. Over that time the team size had grown from one (me) to three.

The ruggedized prototype was now to be put through acceptance checks. We gave a final check and then packed it for transporting to the customer's site. When we assembled it, and put it into operation, the ouput would not settle down as it was meant to. That got me into a flap. I was sure that during transportation some damage had been done to the hardware. I had visions of doing a messy hardware debug on the customer's premises. Luckily, I decided to sleep on the problem.

The next day I asked one of my engineers if anything had been done to the code that was in the EEPROMs. He said that there was a long sequence of code which did nothing but write zeroes into the RAM. He had taken that out. The data memory was no longer initialized.

So was my engineer at fault? No, I was. This was code that I had written almost at the start of the project. The purpose of the code was clear to me. But I was no longer "in contact" with the code. And I had failed to document it.

I have since then, been rather fanatical about documenting the intent of any block of code. Documenting the WHAT [is intended to be acheived], and the WHY [it is important that it be acheived]. The HOW is not that important; the code should say that - unless of course the code is convoluted. But then one should not be writing convoluted code in the first place:-)

This incident led me to formulate my extension to Murphy's Law:

If anything can go wrong, it will - and it will happen in the presence of the customer!

Toyota Recall: Hubris was the root cause

Quote from Under the Hood of Toyota's Recall: 'A Tremendous Expansion of Complexity'. Watch the video

Prof. Takahiro Fujimoto says:
(Quote)
I would probably say middle managers, particularly at headquarters, started to deviate from the Toyota Way by being arrogant, being overconfident, and also they started not to listen to the problems that customers raised. Toyota is a problem-finding, problem-solving company. This culture is still there in the factories and in product development centers. But in some parts of the headquarters, someone started to say, "Hey, this is our problem. I am responsible for finding my problems and solving my problems. It's not [for] you [outside Toyota] to find our problems."

Sometimes I'm critical of Toyota. But they get angry. They always say, "We want to find problems. So please, give us any clues on the problems you see." But if I actually say, "This is a problem for you," they say, "This is none of your business. We have to find the problem. Not you." This attitude was growing for some time, I think, in some parts of headquarters. That was very dangerous. It is a good time to correct this kind of attitude and go back to the basics of the Toyota system.
(Unquote)

Phenomena, Hypothesis, & Defect

A few days ago my washing machine developed a problem. The phenomena was: The inflow of water would not stop when the power was off. Resulting in flooding.

A service engineer came and inspected the machine. He observed the phenomena. But then he went a step further and created a hypothesis: The water did not stop as the input valve was stuck at open because of sludge(I live in Noida). Then he formulated the corrective action: Chemical wash of the machine to clean out sludge. And that was all that went in his inspection report - no mention of the phenomena.

The workshop people came and collected the machine. The next day they returned a bright-as-new washing machine. But the reported phenomena was still observed! Obviously a chemical wash was not the correct corrective action.

Lesson: Always report the observed phenomena that is to be investigated. Hypotheses should be marked for what they are - reasonable guesses. Most importantly - do not specify a corrective measure without first establishing the defect.