The Psychology of Reviews: Distinction Bias, Evaluability Hypothesis and the Framing Effect

Posted on October 21, 2012 by Hayim Makabee

Design Reviews are one of the most important activities in the software development process. If a bad design is approved and implemented, it is very expensive to correct that afterwards. Therefore, we want to have high confidence in our decisions when we are reviewing a proposed design.

Suppose someone is presenting us the design for a server-side system, whose non-functional attributes are described as follows:

The server is stateless and session data is stored in a shared database. Each instance of the server will hold a cache for 10,000 active sessions, being able to handle 400 transactions per second (TPS), with average latency of 150 milliseconds. The service is expected to be up 99% of the time.

How does that sound? If you have some experience with server-side development, this numbers probably appear to be quite standard. If you are reviewing such a design, the two main questions are:

  • Are these performance attributes reasonable?
  • Do they satisfy the requirement of the Service Level Agreement (SLA)?

If your answer to both questions is affirmative, then you would probably approve it.

But what would be your opinion about a service described as follows:

The server is stateless and session data is stored in a shared database. Each instance of the server will hold a cache for 15,000 active sessions, being able to handle 300 transactions per second (TPS), with average latency of 100 milliseconds. The service is expected to be up 99.9% of the time.

This description sounds very similar to the previous one, right? Actually, they are so similar that if you have approved the first one you would approve this one also, and vice-versa. But when we compare the two descriptions we may ask very interesting questions. To help this comparison I will present the two options in a table:

Attribute Option 1 Option 2
Cache Size (# sessions) 10,000 15,000
Throughput (TPS) 400 300
Latency (ms) 150 100
Robustness (up-time) 99% 99.9%

Here are some of the questions raised by comparing these two options:

  • What is the expected number of active sessions at any point time? If this number is 30,000 then the first option would require 3 instances of the server, while on the second option two instances are enough.
  • What is the expected TPS per active session? In the first option the ratio is 400/10,000 = 4/100 while in the second option it is 300/15,000 = 2/100. So the ratio in the first option is twice as bigger as in the second option.
  • What is more important, the latency or the throughput? There is a clear trade-off here, because Option 1 has better throughput while Option 2 has better latency.
  • How do you compare the Robustness of the two options? If you think about up-time, there is a 0.9% improvement in Option 2: From 99% to 99.9%. But if you think about down-time, Option 1 could be down 1% of the time, while Option 2 can only be down 0.1% of the time. So you could say that the second option is ten times better. In practice, for an entire year, the first option could be down during 3 days and 15 hours, while the second option can be down during less than 9 hours.

I believe that it is clear in this example that comparing two options is different from reviewing each option separately. In other words, the reasoning involved in the review of a single option is not the same as in the combined analysis. This is not a special case, and actually these differences have been studied by psychologists who reached interesting conclusions and defined some general phenomena, such as:

  • The Distinction Bias
  • The Evaluability Hypothesis
  • The Framing Effect

Now let’s take a look at each one of these theories and observe how they relate to our concrete design review example.

Distinction Bias

The Distinction Bias is an important concept that was studied in the context of Decision Theory. This is a definition from Wikipedia:

“Distinction bias is the tendency to view two options as more dissimilar when evaluating them simultaneously than when evaluating them separately.”

In our example above, the two design options initially looked very similar, but when they were compared side-by-side their differences became more apparent.

There are situations in which the Distinction Bias may cause bad choices. For example, this happens when we decide to pay more for a product that has a feature which we don’t really need. But in the case of design reviews, I believe that the Distinction Bias is normally beneficial, because the people doing the reviews are professionals that should understand the real meaning and importance of the diverse attributes.

Evaluability Hypothesis

The Evaluability Hypothesis describes another phenomenon that was observed by psychologists when studying how people choose between options. The basic observation is that there are attributes that are easy to evaluate in isolation, while others are hard. These hard-to-evaluate attributes need to be compared to something else to be understood.

When people assess options independently, they tend to focus on the easy-to-evaluate attributes. But when comparing two options they can take in consideration the hard-to-evaluate attributes. This may cause an Evaluation Reversal: The option ranked as the best one in isolated assessments may be considered the second-best in a joint-assessment.

In our previous example, if we asked software engineers to rank the two options in isolation, it is likely that the second option would be considered the best. It was better in three of four attributes: Bigger cache, lower latency and higher up-time. But there is an attribute that may be hard to evaluate in isolation: The TPS per active session, or the rate between the throughput and the cache size. As we saw, it is much higher in the first option than in the second, and thus in a joint evaluation the first option could be chosen.

Framing Effect

The Framing Effect is a cognitive bias in which people make different decisions when presented with equivalent options depending on the way these options are expressed. More specifically:

“People react differently to a particular choice depending on whether it is presented as a loss or as a gain.”

In our previous example, we observed this phenomenon when analyzing the robustness of the two design options, which can be expresses either as a small increase in the up-time or a big decrease in the down-time.

Possible questions that could cause this Framing Effect would be:

  • Are you willing to pay $X to increase the up-time from 99% to 99.9%?
  • Are you willing to pay $X to decrease the down-time from 1% to 0.1%?

Or also:

  • How do you rate a system that is up 99% of the time?
  • How do you rate a system that is down 1% of the time?

In both cases the questions are logically equivalent. But if you present them to groups of people, you can expect that the answers will not be consistent.

Conclusions

The understanding of the psychological biases behind people decisions should be used to improve our processes. These are in summary the lessons we can learn:

  • Distinction Bias: For better insight, we should always compare alternatives instead of reviewing a single option.
  • Evaluability Hypothesis: To really understand the meaning of hard-to-evaluate attributes, we need diverse options.
  • Framing Effect: The answer to a question depends on how it is formulated. Different questions with the same logical meaning may get different answers.

Thus, by making sure we have diverse options and by asking the right questions it is possible to greatly increase the efficacy of our design reviews.

What do you think? What has been your personal experience with design reviews? Have you observed these psychological biases in practice? Please share your comments below.

Did you like this post?

Posted in Efficacy, Psychology of Programming, Software Architecture | Tagged , , | 10 Comments

Illusory Superiority: Are you a good programmer?

Posted on October 14, 2012 by Hayim Makabee

Programmers are known to be proud of their work. Some developers even feel that writing elegant code is a form of art, and thus they call themselves “software craftsmen”. I am sure that the desire to perform outstanding work is normal in any profession, but in the case of software development the programmers are constantly exposed to pieces of code written by their colleagues. If everyone can see your code, you naturally feel the need to write well.

So now I ask you: Are you a good programmer? Are you above average as a software developer? Perhaps you are in the top 20%, or even in the top 10%?

I’m almost sure that your answer is that you are above average. Most programmers feel like that. But, of course, if most programmers think they are above average, many of them are wrong…

Illusory Superiority

This general phenomenon of feeling “above average” is called Illusory Superiority, and it has been studied by social psychologists. Here is a definition from Wikipedia:

“Illusory superiority is a cognitive bias that causes people to overestimate their positive qualities and abilities and to underestimate their negative qualities, relative to others.”

Here are some concrete examples that were observed by researchers in this field:

“87% of MBA students at Stanford University rated their academic performance as above the median.”

“For driving skill, 93% of the US sample put themselves in the top 50%.”

So MBA students and drivers are just two examples, but the same phenomenon has been observed in diverse environments. If you have experience with software development, you probably agree that programmers are no exception.

But what is wrong about this Illusory Superiority? Self-esteem is certainly a good think. A good professional should have confidence in his abilities to handle his tasks. No one would like to work with a person who is insecure.

The problem with Illusory Superiority is when someone underestimates the capacity of others. This is particularly dangerous when we expect people to work as a team, but someone in this team believes he is much more skilled than his colleagues.

Respect and Recognition

What is the cure for this illusory feeling of superiority? How can we make the programmers in a team respect each other, and even admire their peers because of the recognition of their experience and skills?

I believe that the key for respect and recognition is joint work, as close as possible. And in this case the Agile methods provide more opportunities for cooperation than traditional approaches.

Perhaps the closest form of joint work is Pair Programming. In this case, software developers work in pairs, writing the code together. Several studies have demonstrated that Pair Programming has a positive impact in the quality of systems. But in my opinion another important benefit is the ability to strengthen the bonds among programmers working as a team.

In the case of Scrum, the daily stand-up meetings are an opportunity for each person to learn about the progress of the other members of the team. Even if each programmer is working alone on his individual tasks, he is able to follow the implementation of the system as a whole. In other words, we could say that Scrum promotes a holistic view, allowing each team member to appreciate the challenges being faced by the others.

Real Superiority

But what happens when you are really superior? How should you behave when you are the most experienced developer in a team, or when you are the only one with particular skills? What happens when in your team there are programmers writing poor code?

I believe that when you are the most experienced developer in a team, this should give you a special kind of responsibility. Or, as in the famous quote from Spider-Man: “With great power comes great responsibility”.

In a working environment in which there is real cooperation between team members, your outstanding capacity will be soon recognized and respected. Then you can assume a natural role of leadership, at least in the areas in which you have special skills. Assuming this technical leadership role means:

  • Teaching: If you are the only one with a particular skill, teach others.
  • Sharing: If you are the most experienced, share your knowledge.
  • Reviewing: If other programmers are writing poorly, review their work.
  • Helping: If you can boost productivity, help people to handle their tasks.

But you must always remember that, even if you are “superior”, you can always learn from others. As it’s written in the ancient Jewish book “Ethics of the Fathers”:

“Who is wise? One who learns from every man.”

In this spirit, I will be happy to learn your opinion in the comments below. Thanks!

Posted in Agile, Efficacy, Psychology of Programming | Tagged , , | 11 Comments

Continuous Learning: Keeping up-to-date and acquiring new skills

Posted on September 24, 2012 by Hayim Makabee

According to the Bible, after Adam sinned and ate the forbidden fruit, God said to him: “By the sweat of your face you shall eat bread” (Genesis 3:19). Hard work has been the reality of humanity during known history, however things got worse recently: Everything we know, including our professional skills, is rapidly becoming obsolete. This means that it’s not enough to work. We must be constantly updating our knowledge and acquiring new skills.

A recent article in the New York Times, entitled “To Stay Relevant in a Career, Workers Train Nonstop”, discusses the problem of obsolete professional skills. According to them, “virtually everyone whose job is touched by computing are being forced to find new, more efficient ways to learn as retooling becomes increasingly important not just to change careers, but simply to stay competitive on their chosen path”.

This situation is particularly problematic for software developers. I have been working as a programmer for more than 20 years. I got my B.Sc. in Computer Sciences in 1992. Almost everything I learned then is now obsolete. And almost all technologies I’m using now did not exist then (one exception is UNIX).

Now the question is: How do I keep up-to-date? How do I learn new skills?

Below are some strategies that I have been applying to keep constantly learning:

Make Sure You Are Learning at Work

The best place to learn is at work, by putting your knowledge in practice. However, even in the most dynamic workplaces it is easy to get too accommodated by becoming an expert on some field while ignoring new developments. Thus, to be constantly learning at work, you should either join new projects from start or apply new technologies in existing projects.

In the worst case, if you feel you do not have the opportunity to learn anything relevant in your current job, you should consider seriously moving to another company. Then, you should investigate and select potential workplaces according to the technologies being used at these companies. Very often it is more interesting to apply to a job in which you will have the opportunity to learn new skills than looking for a position in which you will mostly use your current knowledge.

Develop Your Own Pet Projects

If there is some technology that you really want to learn and if you do not have the opportunity to apply this technology at work, then you should invent your own project to use it and develop this project during your free time. Luckily for you, for almost all technologies that you may be interested in, there should be Open-Source platforms providing it. Also, your personal computer at home certainly is strong enough to develop interesting projects.

Learn from Online Courses

Today there is a great diversity of free online courses. Sites such as Coursera, Udacity and edX offer many interesting courses organized by known professors of some of the best Universities in the world. These courses are completely free, and besides material such as videos and slides they may include real home works and programming assignments. They are planned to extend during several weeks, and thus are able to cover the proposed subjects in relative depth.

Go to Technical Meetings

Programmers like to meet to discuss new technologies and share their experiences. If you live in a place with a big concentration of hi-tech companies, you certainly will be able to find groups of software developers organizing such professional meetings. Besides the interest in discussing technical issues, these meetings are a great opportunity for networking and allow you to learn what is being done in other companies. You can search for meetings in sites such as Meetup and Eventbrite.

Participate in Online Forums

Online Forums are a great way to communicate with other developers that may be located very far from you, but even so they share exactly the same interests. These forums are the ideal place to promote discussions, exchange opinions and ask for advice. For example, there is a great diversity of interest groups on LinkedIn. In the most active groups you can find new discussions every day, and even job announcements. Another great place for debate is Quora, in which discussions are organized as questions and answers.

Read Technical Blogs

You are already reading this blog, but: is reading technical blogs a habit? Ideally, you should reserve some time every day to read posts from your favorite blogs. Now you can ask: “Where can I find relevant blogs to read?” Of course you can always use a search engine, but it is a good idea to follow software development gurus on Twitter, as well as enthusiastic programmers that like to share their favorite posts.

See Presentation Slides

Good presentation slides are a very concise way to transmit information. If you want to get some initial idea about a technology or platform, and if you do not have much time to invest on it, then finding introductory slides is an easy and fast solution. Sites such as SlideShare have a huge quantity of such professional slides. After you get an introduction, you can decide if it’s interesting to look for more in-depth material.

Watch Videos

For the more popular subjects, it is easy to find videos on YouTube or Vimeo. These may be recorded lectures in Universities, presentations in conferences or talks in group meetings. Videos are very suitable to get a first taste of new subjects, sometimes giving you the opportunity to get out of your comfort zone. For example, TED talks are known for their ability to provide inspiration and make watchers think.

Use Question-and-Answer Communities

If you have a technical problem, then it’s very probable that someone before you already had the same problem. Thus, you should try Q&A Communities such as StackOverflow to search for a solution. If you cannot find an existing question that fits your needs, you can always ask a new question yourself. And sometimes, even if you do not have your own doubts, you can learn a lot by checking what other people have been asking recently.

In Summary

Today, thanks to the Web, it is very easy to find material about any subject you may want to learn, and it is also easy to contact other professionals that share your interests. There is absolutely no reason you should become obsolete: with dedication and discipline you can continuously acquire new skills by following the strategies above. Ah, and of course you can always read an old-fashioned book as well. Good luck!

Do you have other strategies for continuous learning? Please share your experience in the comments below.

Posted in Efficacy, Social Networks | Tagged , | 19 Comments

Four Myths of Software Evolution

Posted on September 9, 2012 by Hayim Makabee

As software developers, we know that our systems will evolve with time. We must understand the forces that drive this evolution, in order to design systems that are easily evolvable. Unfortunately, many programmers have misconceptions about the real drivers of software evolution and about their own ability to predict how a system will evolve.

In my many years of experience as a professional software developer I had the luck to work on many projects from start. But on other occasions I joined projects that were already mature and deployed to real users. In these projects I observed the difficulty to maintain systems that were not planned for change. I condense my personal experience below in the form of four myths of software evolution.

Myth 1 – Changes are driven by improvements in implementation

Very often programmers believe that they will only have to change their code if they think about a better way to implement it, but this is not true. Most modifications are caused by new requirements originating from real users, who are not satisfied with the current functionality. For this reason, it is always more important to invest time understanding the user requirements than optimizing your algorithms.

Reality: Changes are driven by better understanding of user requirements.

Myth 2 – If you did your best, you will not need to change it

Many programmers are perfectionists; they will try to do their best and only be happy with a piece of code if they feel they cannot improve it. However, any code can be improved when these improvements originate from new user requirements. The idea of a “best possible code that cannot be improved” is a dangerous illusion. It is dangerous because it focuses on the quality of the implementation details, and not on the satisfaction of user needs.

Reality: Even if you did your best, you can still improve it.

Myth 3 – After many improvements, the code will not be changed again

Some programmers believe that if they have already invested a considerable amount of time improving a piece of code, it has reached a “stable” state in which it will not be necessary to change it again. However, the truth is that the number of changes is always proportional to the usefulness of the code. When people use your code they discover the need for new functionalities, which is the main source of changes. Thus if your code has been changed a lot in the past, it is probable that it will need to be changed again.

Reality: The more a code is used, the more it will need to be changed.

Myth 4 – You can predict which parts of the system will need to be changed

It is not possible to predict the new requirements originating from real users. The best we can do is to identify the components that play the most central role in the functionality of the system, and to design them to accommodate easily the future changes in requirements. Of course the system may also need to be changed to improve its performance, but this should be done after appropriate profiling of real usage and identification of the bottlenecks.

Reality: Evolution cannot be predicted. The users will always be able to surprise us.

In Summary

The conclusion from the myths above is that when you know that a piece of code is important and will have many users, the best you can do is to design for maintainability. In other words, if a component is likely to be changed, it is more important to design it to be easily modified than to implement it perfectly using the more efficient algorithms.

Now you can ask two questions:

1) How do I design for maintainability? I think that the response is to focus on the Separation of Concerns, keeping low coupling and high cohesion.

2) Which methodology makes evolution easier? I think that Iterative Software Development is the best way to handle constant software evolution.

What do you think about these four myths of software evolution? Do they fit your own experience? Please share your comments below.

Posted in Requirements Specification, Software Evolution | Tagged , | 9 Comments

Planning Poker: Avoiding Fallacies in Effort Estimates

Posted on August 5, 2012 by Hayim Makabee

Many years ago I was working as a software developer in a team with three other programmers. We once had a meeting in which our Team Leader said:

“You are late again! All of you are late! Actually, you are always late! We cannot continue like that!”

Then I replied to him:

“If all of us are late, and if we are always late, then there must be a problem in the way we do effort estimates…”

In this case, the Team Leader himself was the one doing the estimates. He did it alone, based only in his own judgment, without consulting us, the developers. When he assigned new tasks to us, it was something like:

“You now must do this task, and it must be ready in X days.”

Certainly this is not a very nice way to talk to people working with you, but the main problem here is that it is not effective. For any person, it is very difficult to do precise effort estimates. Thus, we should always avoid doing estimates alone and without asking for other opinions.

Planning Fallacy: Why Estimates Are Hard

The difficulty of people to make good effort estimates is a well-known phenomenon, and as such it was the subject of research. Scientists have called it the Planning Fallacy:

“The Planning Fallacy is a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running.”

The Planning Fallacy is discussed by Daniel Kahneman, Israeli Nobel Laureate in Economics, in his book “Thinking, Fast and Slow”. According to him, plans and forecasts suffering from this effect have two main characteristics:

  • “are unrealistically close to best-case scenarios”
  • “could be improved by consulting the statistics of similar cases”

Psychologists have tried to explain the causes for the Planning Fallacy. Some claim that the main reason is that people have a tendency to focus on the most optimistic scenario, actually believing that this optimistic scenario is more probable than it really is. Others claim that this is just another example of wishful thinking. This means that people think about what they would like to happen, and not about what is likely to happen.

I think that in the workplace there are some other reasons for the Planning Fallacy:

  • If the manager is the one doing the estimates, he has an interest to make them hard to achieve, in order to push people to work more productively. Managers always want to see the work completed as fast as possible.
  • If the worker is the one doing the estimates, he will be ashamed to assign too much time to himself. People are afraid of doing pessimistic estimates for their own tasks, because they may appear to be lazy or inefficient.

Thus, it is quite clear that there should be other people participating in the estimates, and not only the manager and the worker who will perform the task. People estimating from the outside, who do not have a personal interest in the task and will not be responsible for it, can be more objective.

Planning Poker

The methodology of Agile software development has addressed the problem of poor estimates through the concept of the Planning Poker, in which all members of the team participate and contribute. Each member of the team has a set of numbered cards, with the numbers representing the effort to implement a task. For each feature in the backlog, each person makes an independent estimate using the cards. Then, the cards are simultaneously shown and people can compare and discuss their estimates.

The goal of the Planning Poker is to reach consensus, in which all participants agree with an estimate after they have discussed it and understood each other opinions. There are several reasons that cause this process to provide more accurate estimates:

  • There are more people participating in the estimates, including team members that will not be directly responsible for performing the task.
  • People are not influenced by others when making their original estimate, since they do that simultaneously and independently.
  • People have to justify their estimates, especially if they are too low or too high.

I think this is a great approach for addressing the Planning Fallacy, and it also has the advantage of being fun and strengthening the bonds among team members.

Do you have experience with the Planning Poker? Please share your thoughts in the comments below.

Posted in Agile, Efficacy, Psychology of Programming | Tagged , , | 20 Comments

Industrial Projects at the Technion

Posted on August 1, 2012 by Hayim Makabee

The faculty of Computer Sciences at the Technion has an Industrial Projects initiative in which undergraduate students work under the supervision of software professionals. I think this is a great idea, a real win-win situation:

  • The students have the opportunity to gain experience working on real projects, under the supervision of industry veterans.
  • The companies proposing the projects gain access to talented students to develop prototypes or proofs-of-concept at no cost.
  • The CS faculty gains access to many industry professionals each semester that effectively become part of their training ranks, also at no cost.
  • The early connection between companies and students may help the students to find a job in the future, as well as help the companies to find good candidates.

In the last semester I had the great pleasure to be the supervisor of a project entitled “Movie Quotes Search Engine”, together with my friend Oren Somekh. We were very lucky to “hire” for this project two brilliant students: Meytal Bialik and Zvi Cahana. The results of their work were very impressive, and above our expectations.

You can check the Movie Quotes Search Engine project to learn more about their work. I hope this serves as inspiration for other students looking for practical experience. It should also serve as motivation for other software companies to cooperate with the Technion in this important initiative.

What do you think about that? I will be happy to have your comments below.

Posted in Yahoo! | Tagged | 6 Comments

An Event-Driven Approach for the Separation of Concerns

Posted on July 4, 2012 by Hayim Makabee

Last week I presented a paper at the International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2012), at Wroclaw, Poland.

Title: “An Event-Driven Approach for the Separation of Concerns”

Abstract: “This paper presents an event-driven approach for the separation of concerns in software systems. We introduce the EventJ framework that provides an event-driven extension to the Java programming language. The paper describes a general methodology that can be used to identify the cross-cutting concerns and separate them from the main functionality using events and event handlers. We discuss the pre-requisites to perform this change and illustrate it with a concrete example. Finally, we make a comparison between the event-driven approach and the aspect-oriented one, and conclude that the use of events to separate concerns has a positive effect on software quality attributes such as maintainability, extensibility and reusability.”

You can freely download a full-copy of the paper.

You can also view the slides:

An Event-Driven Approach for the Separation of Concerns

View more presentations from Hayim Makabee

I hope you find that interesting. Feel free to leave a comment below.

Posted in AOP, OOD, OOP, Research | Tagged , , , | 4 Comments

Self-meetings: Avoiding distractions in the workplace

Posted on June 15, 2012 by Hayim Makabee

In the modern workplace, in which we are always connected, there are simply too many distractions. You need lots of discipline to really use your time effectively, besides the capacity to clearly define your priorities. You must be able to identify the reasons your valuable time is not being spent in the most effective way, and then develop methods to fix that.

The chart below, called “How to Focus in the Age of Distraction” has wonderful tips about effective time management and increased productivity. It’s certainly worth more than a thousand words, so I suggest you take a good look at it:

One form of distraction that is not mentioned in this chart are the meetings in the workplace. If we really want to “work in focused bursts”, we must assure that our work is not interrupted by a meeting.

In my experience, this is particularly important for software developers. If a programmer is focused, he can accomplish in two consecutive hours much more than in two periods of one hour each. Every time a programmer starts working on a task, he needs considerable time to “enter the zone”, reaching a state of “flow” and working with maximum productivity.

Too many meetings are certainly a productivity-killer for any professional. But, for a software developer, even a small number of meetings randomly distributed during his work day can reduce drastically his output.

The question is: How can I avoid my work to be interrupted by a meeting?

Self-Meetings

I’ve adopted a simple technique that works very well: When I know that I need time to work on an important programming task, I just go to my calendar and reserve this time for myself, marking it as “busy”. In other words, I create a “meeting” in which I’m the only participant, a meeting with myself. If I know I will need to work for several days on a task, I may just reserve all the mornings in a week. For example, I may create self-meetings, every day, from 8:00 to 12:00.

Thus, when someone tries to invite me for a meeting, he will see that I’m busy, and then he will need to look for an alternative time in which I’m free. Better yet, he may decide that I’m not really needed in this meeting.

Of course you must always leave a certain amount of free time in your calendar. After all, there are meetings in which you need to participate, and you do not want to make it extremely difficult for the meeting organizer to find a suitable time slot.

This technique will not work if your organization has a really bad meeting culture. There two types of common problems regarding meetings:

  • Too many meetings: People are creating meetings that are not really needed.

  • Too many participants: Too many people are being invited to the meetings.

In both cases it is extremely difficult for the meeting organizer to find a time slot in which all the participants are free. Then, you will eventually be invited to meetings during your “busy” time. If your company has such problematic meeting behavior, you must discuss that with your management and your peers. That’s not something that you can solve personally using any individual technique.

Finally, you should avoid as much as possible to use the “suggest alternative time” option when replying to a meeting invitation. This should be done only in unforeseen situations, for example when there is an emergency and you will no longer be able to participate in a meeting that you had already accepted. If you know that you will be busy at a certain time, you should make it explicit in your calendar as early as possible.

So good luck with your self-meetings, I hope this technique will help you become more productive.

You may also want to read my previous post about Super-Productivity.

I will be happy to hear your comments!

Posted in Efficacy | Tagged | 4 Comments

The Seven Rules of Effective Communication

Posted on June 3, 2012 by Hayim Makabee

In every professional environment, it is essential to communicate effectively with your peers. This is particularly true during meetings, in which people expect to discuss a subject, reach conclusions and make related decisions in a short time. Here are seven rules of effective communication:

1. Respect Experience and Seniority

As I’ve discussed in a previous post, there is a very important difference between knowledge and experience. Sometimes it’s hard to believe, but most people reach senior positions through real competence and accomplishments. Thus you should always listen carefully to what the veterans have to say, even if it appears to be wrong. Most probably they can see something that you can’t, so if you disagree with their opinions first ask them to justify their point.

2. Don’t Interrupt the Speaker

If you are participating in a meeting, you should be very interested in understanding what the other participants have to say. But by interrupting others you are not giving them the opportunity to clearly communicate their opinion. This is first of all a sign of disrespect that may cause bad feelings. But interrupting others also gives them the right to interrupt you, creating a chain-reaction with very negative consequences.

3. Think Before You Answer

Of course we must think if we are not sure about the answer, but we must also think even if we could answer immediately. When participating in a meeting, we are not only interested in expressing our views, we must also be able to explain and justify our opinions. Especially when we know in advance that someone may disagree with us, we need to think about how to present our ideas in a clear and solid way.

4. Focus on the Subject

For meetings to be effective we must focus on the topic being discussed. There is a limited amount of time available to reach a conclusion, and we do not want to waste this time with parallel issues. If there are other important topics that need to be discussed they should deserve their own meeting. Thus when answering  to someone always address directly the question, and never ask questions that are not related to the discussion.

5. Organize Your Speech

When answering a question you should define your priorities. Say the most important things first, and add more comments only in the case they are necessary. If you were asked several questions, answer them in the same order they were asked. Also, answer each question separately. It will be much easier for the other participants to understand you if you present your thoughts in a clear order.

6. Accept that You Don’t Know Everything

If you are asked a question for which you don’t have a good answer, it’s perfectly natural to say that you simply don’t know. Of course you should know the answer for any question directly related to your personal tasks. But when the topics being discussed are related to the work being done by teams of people, you’re not expected to know all the details.

7. Don’t Argue the Facts

You should have your personal opinion about all the important issues being discussed. This is the contribution that the other participants expect you will bring to the meeting. You should know how to explain and justify your opinions. But you should also know how to stop debating when you are presented with new facts that clearly contradict your view.

Conclusion

What do you think about these rules? Do you agree with them? Do you think that if people followed these simple rules their communication would be more effective? And what if I told you that these seven rules where written more than 2000 years ago, in a Jewish book of ethics called Pirkei Avot?

From Pirkei Avot, Chapter 5:

“There are seven things that characterize a boor, and seven that characterize a wise man. A wise man does not speak before one who is greater than him in wisdom or age. He does not interrupt his fellow’s words. He does not hasten to answer. His questions are on the subject and his answers to the point. He responds to first things first and to latter things later. Concerning what he did not hear, he says “I did not hear.” He concedes to the truth. With the boor, the reverse of all these is the case.”

Yes, technology has changed a lot in the last 2000 years, but it seems that human nature remains the same.

I hope you have enjoyed this post and will appreciate to hear your opinion, please leave your comments below.

Posted in Efficacy, Jewish Sources, Psychology of Programming | Tagged , , | 4 Comments

Code Swarm: Visualizing the Evolution of Software Systems

Posted on May 24, 2012 by Hayim Makabee

Software systems grow over time. They evolve through additions, extensions and modifications. A successful application is not one that satisfies all the original requirements and then is delivered to its users and remains unchanged. If people are using a system, they will require it to be changed. They will have ideas about new features and capabilities that were not originally planned, and will feel that they really need them. Of course users also find bugs that need to be fixed, but this kind of maintenance is actually a small effort when compared to the addition of new functionality. Thus, if a system is not evolving it is because it is not being used, and if a system is being used it certainly will need to evolve.

Now the question is: How do systems evolve?

For a particular system, we can ask specific questions:

  • What parts of the system are being changed more frequently?
  • How the total number of files is growing over time?
  • How the work is being distributed among the software developers?
  • Are there developers that contribute more than others?
  • Is there an “ownership” relationship between developers and software components?

The answers for these questions can be obtained by analyzing the history of the software repository. Every commit represents a change done by a particular developer in a specific file. A commit also means the existence of a relationship between a programmer and a file at a particular moment in time. This relationship may continue for a period of time, if the same person makes several successive changes on the same file.

But for big systems it may be difficult to summarize all this information in order to understand how the system is growing and being changed. Thus, it would be very nice if we could visualize graphically the evolution of software systems. And this is exactly the concept behind Code Swarms, as idealized by Michael Ogawa:

“This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before.“

For an example, see below the Code Swarm for Twitter:

It is interesting to note how a small number of developers play a very central role in the evolution of Twitter, changing a large quantity of files during a long period of time. It is also interesting to see that other developers join the project, give a relatively small contribution, and then “fade away”. Of course here we can only observe the number of files being changed, and not the size of the contribution in lines-of-code (LOC) neither the complexity of the code being added or modified. But even so it is clear that a few programmers are “hubs” while others are in the periphery.

I really find this useful, and intend to run Code Swarm for the systems I’ve developed recently with my colleagues at work.

I will appreciate to know what you think about this idea of Code Swarms, please leave a comment below.

Posted in Software Evolution | Tagged | 2 Comments