I have heard that this is behaviour peculiar to Indian crabs, though recently I did come across an email which said Alaskan crabs too behave the same way, (I suspect the sender is a person of Indian origin settled in the US:-)
According to people who tell the story, the crabs on the top cannot escape because the ones below are pulling them down. (Actually the top crabs have the option to jettison a limb and escape. Somwhat like in the erstwhile Iron Curtain countries:-)
Here are some ways I like to look at it:
1. The crabs below are ambitious. They want to get on top. The top crabs have the option to either get out or go down. Nothing wrong with that. It is competition.
2. All the crabs know the danger. They want to cling on to each other out of sheer fright. Result - none can escape to live. Splitting a company going down may permit some of the spin-offs to survive. Some management teams will not think that way.
3. The top crabs know the danger and ,because they see it as their duty to protect the crabs below, are supressing them to protect them:-) They tell stories about how safe the lower crabs are in their current postion and they should not think of leaving. Some management teams behave this way.
No matter what, the best they can hope for is to land up on someone's menu. Hopefully, some chefs convert the crabs into quality dishes:-)
29 May 2010
28 May 2010
Documenting Tests
Scientists formulate and carry out tests and record results to verify theories about nature. Software persons formulate and carry out tests to verify their theory that a given piece of software does what it is meant to do, or not do.
Should not tests be documented like experiments?
Should not tests be documented like experiments?
27 May 2010
Development or Maintenance, What should a fresher choose?
The late Wg Cdr R Raghavan (RR) and I co-founded Ergo Electronics in 1989 and then in 2000, along with some others, co-founded Acme Technologies. He was also my friend and boss. I learnt a lot from him. He will crop up frequently in this blog.
RR had also co-founded Ergo Software Systems in 1986. That was with another person.
He was held in great respect by all software engineers for his software skills. He could quickly diagnose problems in the code, suggest better data structures and module organizations, understand convoluted code and show how it could be simplified. Yet he always maintained that he had written just 4 programs - that too in COBOL! None of the engineers (all working in C) believed him.
After many years of listening to this I asked one of the engineers, "Why do you not ask him how many programs he has read?" The answer: He had lost count. But it is safe to assume it was in the tens of thousands.
RR was one of the founders of the Indian Air Force's computer center. He remained there for about a decade. It was there that he got to read the code for the ICL computer's operating system and other system programs - most in assembly language. He also got to read the application programs written by application developers and learn through their mistakes.
So what should a fresher choose? To me it is a no-brainer. Maintenance - because that is where the greatest opportunity to learn about structure (both good and bad) of programs and data. To learn what make code difficult to maintain. (That is important as any code that is useful will spend most of its life cycle in the maintenance phase. I highly recommend reading Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
.)
As the saying goes, "Those who do not learn from history, are condemned to repeat it." So too for software engineers who do not learn from others mistakes.
RR had also co-founded Ergo Software Systems in 1986. That was with another person.
He was held in great respect by all software engineers for his software skills. He could quickly diagnose problems in the code, suggest better data structures and module organizations, understand convoluted code and show how it could be simplified. Yet he always maintained that he had written just 4 programs - that too in COBOL! None of the engineers (all working in C) believed him.
After many years of listening to this I asked one of the engineers, "Why do you not ask him how many programs he has read?" The answer: He had lost count. But it is safe to assume it was in the tens of thousands.
RR was one of the founders of the Indian Air Force's computer center. He remained there for about a decade. It was there that he got to read the code for the ICL computer's operating system and other system programs - most in assembly language. He also got to read the application programs written by application developers and learn through their mistakes.
So what should a fresher choose? To me it is a no-brainer. Maintenance - because that is where the greatest opportunity to learn about structure (both good and bad) of programs and data. To learn what make code difficult to maintain. (That is important as any code that is useful will spend most of its life cycle in the maintenance phase. I highly recommend reading Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
.)As the saying goes, "Those who do not learn from history, are condemned to repeat it." So too for software engineers who do not learn from others mistakes.
12 May 2010
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:
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.
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:
- Programming tools have a long life. These required to be maintained over many generations of developers. In the tools BU Maintenance is Renovation.
- Optimizing compilers are complex. Complexity leads to difficulty in maintaining them.
- Turnover of personnel.
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.
06 May 2010
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
- 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.
- 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.
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.
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.
04 May 2010
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,
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.
. 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.
Subscribe to:
Posts (Atom)