Are all software developers introverts?

I realize that it has been nearly a year since I have posted on this blog. I was short of time rather than short of ideas. To make amends, I have come back with something slightly more ambitious than previous publications, the first of many I hope. In this article I will explain to you the results of a small study that attempts to verify a stereotype that was often mentioned to me during my career in IT: that software developers are introverts. This vision of the programmer runs counter to another persistent stereotype you might know: that software developers are attracted to novelty. Indeed, it has been shown that novelty seeking is positively correlated with extraversion and emotional stability (De Fruyt, Van De Wiele, & Van Heeringen 2000). This was confirmed to me by Michel Hansenne, professor of differential psychology at the University of Liège (2014). If these two stereotypes are contradictory, which one is true?

The first clue I found was in the search for novelty: it may be noted that headhunters specializing in the recruitment of software developers have not waited for the results of scientific studies to use this argument to entice new recruits by telling them about new technologies, they address this before even the issue of finance. This aspect of the personality of the average developer seems quite plausible because I have noticed many times that some of them adopt what I call “CV Driven Development” This is a counterproductive practice (for the company) which is to focus almost always new technologies, not for objective technical reasons but to be able to add this new knowledge to their resume or only for the pleasure of experiencing something new.

I then asked if anyone else had asked the question. Although I found no academic scientific study on the issue, I can still quote the Evans Data Corporation report “Developer Marketing Survey 2014“, the results were included and discussed in the popular online specialist magazine InfoQ (Avram, 2013). The report from this company, specializing in the analysis of the target population for this study attempts to provide an answer to this hypothesis through a questionnaire sent annually to its panel of over 75,000 developers in 85 different countries. Their results confirm the absence of introversion and confirms novelty seeking as a very common characteristic in the target population. My study attempted to determine whether similar results can be obtained using a standardized personality survey rather than self-evaluations in simple questionnaires.

To test my hypotheses, I used two personality surveys which compared the results to the mean population using the Student t test. One is the Temperament and Character Inventory-Revised (TCI-R: wiki) Cloninger. The second is the Revised NEO Personality Inventory (NEO PI-R: wiki) of Costa & McCrae.

The sample consisted of a total of 50 subjects, all masculine, some of whom responded to both questionnaires (32) and some only one (TCI-R: 38; NEO PI-R: 44). Note that this is a convenient sample since all these subjects are final year students of computer science who participated in a specialized coaching program of my design for which access was conditional on performance in an entry test.

If the results shed light on our question, they also give some interesting insight on other matters. First, with the TCI-R, there is a strong difference in the temperament “Novelty Seeking” (p = 0.000), which confirms the hypothesis that the developers would be eager for the new, this is not very compatible with introversion. One can also note an interesting way that the character “Self-Transcendence” which is associated with spirituality, is also significantly different from the mean population (p = 0.037), despite the fact that the sample was culturally eclectic.

Developers TCI-R Results

The results from NEO PI-R found one statistically significant difference in the factor “Neuroticism” (p = 0.015) which determines emotional stability. This could be explained by the fact that most of the sample consisted of placed (ie successful) students. One can also note the interesting way that extraversion is a slightly above average level, which also confirms the hypothesis.

Developers NEO-PI R Results

My results show that, for my sample, the dominant personality type is far from introversion. In fact we can demonstrate a clear difference from the general population in the dimension of novelty seeking, the opposite of introverted behaviour.

It is possible that the origin of this stereotype comes from a misunderstanding about what introversion is. The concept could be confused with another facet of the personality: ie sociability. But even here, the results of my survey do not support the idea of introversion (Agreeableness in the NEO Pi-R or reward dependence of the TCI-R). I think the genesis of this stereotype is in the very nature of computing that by its apparent complexity, may have created a divide between IT and others, in specific contexts, and perhaps even at different times. To test this idea would require the development of a larger study.

With the limitations of this study, one might assume that the difference is only statistically significant due to a sampling problem. Indeed, the subjects were all involved in an internship supervised by a center for innovation and creative projects. One could easily imagine that these subjects have applied to do their internship with us because they were originally already very interested in innovation and new technologies.

In conclusion, I would say that this study and the various initiatives in this area show that studying this particular population could prove to be a very interesting opportunity. The financing of an international study could also be possible: most customers mentioned on the website Evans Data Corporation consist primarily of multinational technology companies like Microsoft, IBM, HP, Google or Adobe for example. It seems to me particularly appropriate to find collaborators with one foot in the industry of these companies and the other in an academic institution doing research in psychology….

Want to participate in one of my future studies? Please fill in this form and I will contact you: http://bit.ly/psydevform

References

  • Avram, A. (2013, Février 20). Are Developers Introverted or Extroverted? Are They Intuitive or Logical? Retrieved from InfoQ: http://www.infoq.com/news/2013/02/Introverted-Intuitive-Logical
  • De Fruyt, F., Van De Wiele, L., & Van Heeringen, C. (2000). Cloninger’s Psychobiological Model of Temperament and Character and the Five-Factor Model of Personality. Personality and Individual Differences, 441-452.
  • Hansenne, M. (2014). Entrevue & echange d’emails. (P. Mengal, Interviewer)
Incoming search terms:
  • Areallsoftwaredevelopersintroverts?|MindfulHacker
  • Are all hackers introvert?

Hope, confirmation bias and entrepreneurs

Entrepreneurs are often trapped in a vicious circle of hope.  Hope clouds judgement and can be what prevents the entrepreneur seeing things clearly and taking the appropriate decisions.  Hope is so seducing that it’s what is used in most personal development or “get rich in x lessons” books.  Hope is also so powerful and rewarding that it is fed by proofs generated by the confirmation bias, that is itself fueled by hope. Entrepreneurs must learn its underlying concepts and learn to get objective opinions from others.

Confirmation bias refers to a type of selective thinking whereby one tends to notice and to look for what confirms one’s beliefs, and to ignore, not look for, or undervalue the relevance of what contradicts one’s beliefs.  [Skeptics Dictionnary]

Before talking about confirmation bias, let’s understand what is hope from a psychological point of view.  Hope is one of the many mental defense mechanism we have that is triggered in order to disconnect us from hurtful emotions (anxiety, sadness, despair, ….).  It uses thoughts to construct a positive scenario of the future.  People often grab these thoughts as a life buoy to avoid the reality of the present moment. We usually hope for a better future when we are  uncomfortable with the present.  Hope is what drives many wantrepreneurs.  Hope will make entrepreneurship’s book writers rich, not you.  Happy people hope for the best, once, then stop thinking about it.

In order to fuel hope, you need proofs that what you see in the future is possible and is likely to happen. This is when the confirmation bias enters into action. Every single proof you see that makes your predictions credible is highlighted, while every single piece of evidence that it won’t is denied. Those proofs stimulate hope that itself forces you to suffer from the confirmation bias. It’s a vicious circle.  One great example of the relationship between hope and the confirmation bias is seen with believers of the 2012 end of world event.  They can point to you dozens of  scientific  studies that prove it will happen, ignoring the hundred other proofs that it won’t.  One seducing thought in the 2012 case is that the event can potentially make them better than they are now.  Hope is triggered by a desire for change and fueled by confirmation bias.  Desire for change is not the only way to trigger hope.  Any unwanted emotion, such as fear, can also be a very good motivator: some religions claim that if you are not a good practitioner, you won’t go to paradise, but burn in hell forever. With entrepreneurs the desire for change is the key to the process.

Hope & Confirmation Bias

Conscious thinking is not the only factor: things get worse when we take into consideration theories of biological psychology.  Desire to change is not the only motivator for hope. There is a physiological reward for the behavior. Dr. Robert Sapolsky, professor of biology and neurology at Stanford University conducted experiments that showed that there is a direct link between hope and dopamine (pleasure hormone) releases in the brain.  Studies even show that we get higher dopamine releases when there are more uncertainties. Uncertainties? That is certainly something that entrepreneurs can relate to.

The ability to cope with temporary difficulties is one of the entrepreneur’s required abilities. Too many people can’t go through what Seth Godin called The Dip.  Defeatism, the opposite of hope, is one of the obvious failure factors in entrepreneurship.  Often they decide to stop.  They think their efforts are not worth it anymore.  Defeatism works just like hope. Your judgment is biased and you see things from the negative side.  It is also fueled by the confirmation bias in the same way.

The Dip Illustration

Optimism is often suggested as a strategy to fight defeatism.  It’s true that if you tend to be defeatist, hope can counter balance the feeling by replacing negative thoughts by positive ones.  It’s positive psychology. And it’s even suggested by the Emotional Intelligence guru Daniel Goleman.

Having hope means that one will not  give in to overwhelming anxiety, a defeatist attitude, or  depression in the face of difficult challenges or setbacks. [Daniel Goleman]

Just as defeatism must be avoided, hope can’t be a strategy on the long term. It can even  hurt as much as defeatism.  Do you remember how you felt after you really hoped that something would happen and it did not? You would be really surprised if you noted each prediction you make and compare them with what actually happened.  Hope will play against you.  It will hurt, it will hide a more concrete problem, and more importantly, it will bias your judgment.

Self awareness, again, is the key. To manage the process, consider hope (or defeatism) as a signal you must decode by being aware of the physical and psychological mechanisms. If we suspect we are biased, we must not believe entirely what we think and assess every hypothesis we make with realistic information.  Market studies and/or customer development are ways to assess our assumptions, as well getting mentorships from more experienced people who have learnt the hard way. With some practice, you will be able to acquire the self awareness required to avoid being trapped in those loops. Be a mindful hacker.

 

 

If you know neither the competition nor yourself, you will fail

There are two common types of behavior I have noticed in people regarding their competition. You have the competition driven people, and the competition denial people .

The first constantly monitor their competitor’s activity by visiting their websites & forums or googling them constantly, while the latter meticulously try to avoid any piece of text mentioning their names.  Sometimes, the latter behaves like the former by accident, triggered by some source of information they have read by mistake… Both emotionally driven behaviors are very dangerous for their business.

A third widespread behavior, linked to the same concept, is to not enter a market because of the presence of one or more competitors or even worse, entering a market without studying the competition in detail. All these types of behavior will make your business decisions weaker. The solution is to take your competition for what it is, no more, no less and try to intelligently decode your emotions and thoughts (both are linked).

When someone is competition driven, he will often take any of the competition’s initiatives as something he doesn’t have (and therefore he must have), instead of taking it for what it is: an initiative that can be equally good or bad.  The resulting action is to try copying the competitor’s ideas (but perhaps doing them better…). The problem with that behavior is that the competition will always be significantly in advance and the market will inevitably perceive him as the follower, not the leader, constantly competing on basic stuff such as features & pricing.  It’s not only his innovation that will be affected, but his overall entrepreneur’s ability to take good decisions.  Being so abnormally obsessed by a competitor can be the start of very serious trouble possibly leading to burnout or worse, to the abandonment of the venture.  His fear of competition is irrational.  Many of his important decisions will be biased by his distorted perception of his challengers.  It’s not how he should develop a wealthy company.

Competition denial on the other hand, is the action of ignoring the competition completely. This is a very commonly suggested strategy to solve the results of competition driven behavior. That is, by ignoring anything the competition do, his judgment, innovation & decisions are not affected by what they are doing. After all, he may say, listening to the market and customers is the only valuable thing to do.  Instead of being competition driven, he becomes customer driven.  It’s a seducing way to drive your business, but ignoring the opponent can hurt you as much as being obsessed by them.

If you know the enemy and know yourself, you need not fear the result of a hundred battles.  If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.  If you know neither the enemy nor yourself, you will succumb in every battle.

Sun Tzu, The Art Of War

This is something I learnt from practicing martial arts. Before an important fight, you must watch videos of your opponents previous battles (or previous fights in a competition).  Watch how he moves, what he is good at, what he sucks at.  It will helps you develop effective ways to attack him and defend yourself.  Strategy is not the only important thing in a battle.  Attitude can make all the difference.  If you have a very determined opponent in front of you, this will affect your morale during the battle, and therefore your performance.  Invest in strategy by analyzing the market, including competitors, and in self confidence.  The former will help your differentiation in the market.  The later will surely contribute to making your competitor fear you, leading them to one or both of the unwanted behaviors described in this post, and making you the leader. Maybe.

Controlled input: the missing piece of time management

In this post, I’ll talk about a problem that affected me personally really badly and that I see in too many other fellow entrepreneurs & developers.

Twelve years ago I thought that increasing my productivity would solve my problems.  It did the exact opposite.  My problems did not disappear.  They became bigger as I became more highly productive.  Until I learnt that I was missing an obvious piece of perfect time management: commitment or what I prefer to call: controlled input.  For those who don’t see the obvious coming (like me a few years ago), this is for you.

In 2000, I started freelancing as I was hit by the entrepreneurial fever. Very quickly I became overwhelmed by work and projects. Sometimes, I had to completely stop moving and think “what is it you are doing?”  I was doing 3 things at the same time, in addition to reacting to every external disturbance such as phone calls. That’s when I decided to invest in something I hadn’t been taught at school or by my parents: organizing myself.  At the time, delegating was out of my reach.

I purchased top rated books on the subject and went to training courses. I started to learn and to put everything into practice.  Productivity increased dramatically.  I became an unstoppable working machine.  In the less than 2 years that followed this, I was able to create 5 companies (with the satisfaction that all still exist today) in addition to freelancing and working on the numerous side projects I had.   This was made possible with increased productivity and the fact that almost 95% of my conscious time was spent working. I started to earn a lot of money, more than I could handle.  But all of this had a price: I became like a zombie and eventually, I burnt out.

I had missed something very important that I hadn’t learnt how to manage yet: my commitments.  I was tempted to say yes to everyone, and more importantly, to myself.  As an example, any new idea I had would be turned into a new company, immediately.  I finally learnt how to solve that problem the hard way.

When I talk about it to friends, employees or students, I use the illustration of the tap and the funnel. The tasks coming in flow from the tap, your input, while the bottleneck of the funnel is you, your maximum output, your productivity. What’s in the funnel is your commitment.

Funnel

Below is an illustration of three possible scenarios.

  • Overwhelmed: you have too much work and you can’t face it. The fact you are overwhelmed affects your productivity negatively because of stress and other technical factors, eg having to multi task. Not to count the waste of unfinished tasks (or low quality).
  • Increased Capacity: you decide to learn GTD to increase your productivity. It works, you have a larger bottleneck, but you are still overwhelmed. You do more with the same time.  By your new behavior, you teach others (and yourself) that you can do even more. Instead of solving your problem, this actually worsens it.
  • Controlled Input: you control both external solicitations and personal commitments. Input is controlled and matches your capacity. Everything is under control. This is a part of self-awareness.

Funnel Details

Properly or improperly managing your commitments has many other effects, for example – trust. The more commitment you fail to meet, the more you teach others (by conditioning) that you are not reliable. They will progressively lose trust. Everything you say will be seen as something said by the unreliable guy. It works both sides: if you succeed in meeting almost every commitment you make, you will teach others that you are very reliable. You will build trust and increase your circle of influence. This includes trust in yourself.  

Here are few ideas on how to manage input:

  • Deadlines set by others: in the developer’s world, we often face situations in which other people set deadlines for us. When I face such situation, I re-estimate the task myself and compare it to my actual commitments. If there is a difference, I confront the person who set the deadline. In short, I learn to say no, but with a proper argument. Saying no without any explanation is not only rude, but unprofessional.
  • External disturbances: I’m always amazed when I see someone looking at his ringing phone saying: “oh no, not him, he disturbs me all the time“. Why not simply ignore the call? You are NOT committed to answer the phone, you can call him back at a better time. This statement is valid for everything including emails. They can wait another 3 hours to get an answer, right? In addition, these interruptions are real productivity killers (Nass, Ophir, Wagner 2009).
  • Ongoing projects: Limit your ongoing projects. Don’t involve yourself in two big projects at the same time. I limit myself to one large project and one or two much smaller ones. In order to do that, I put every idea or thing I would like to do on a list. I update the list often with new stuff, but nothing goes out of it until I have the free room (time) for it.

Increasing your productivity is very easy. The techniques work and are easy to learn. The hard part is learning to say no. To others, but also yourself.  If you are like me, it will take some time to be completely healed from this bad behavior.  But being aware is certainly one big step.  Be productive, control your input, be happy (Oswald, Proto, Sgroi 2009).


 

 

 

Incoming search terms:
  • Controlledinput:themissingpieceoftimemanagement|MindfulHacker

Critical thinking for developers

You gain knowledge from information coming from many different sources including books, articles, blogs, conferences and all the discussions you have with other professionals. Being able to interpret, evaluate, assimilate, synthesize and apply the data you collect is called critical thinking and is an essential skill for anyone (including the developer).

“A persistent effort to examine any belief or supposed form of knowledge in the light of the evidence that supports it and the further conclusions to which it tends” Edward M. Glaser

The word critical derives from the Greek word kriticos, which means discerning judgment. The roots of critical thinking come from analytic philosophy (Greek Socratic tradition) and pragmatist constructivism (Buddhist teachings).

In this article, I’ll try to isolate the 3 most common steps to practice critical thinking which is similar to scientific skepticism.

1. Identify potential cognitive bias

Cognitive bias, such as the confirmation bias, is a pattern of deviation in judgment that occurs in particular situations. Everybody is more or less affected by it. The more you know about those biases, the less likely they are to affect your judgment negatively. Here are some well-known cognitive biases:

  • Confirmation bias: the tendency to search for or interpret information in a way that confirms one’s preconceptions.
  • Mental filter: inability to view positive or negative features of an experience, for example, noticing only a tiny imperfection in a piece of otherwise useful clothing.
  • Gambler’s fallacy: the tendency to think that future probabilities are altered by past events, when in reality they are unchanged.  This results from an erroneous conceptualization of the Law of large numbers. For example, “I’ve flipped heads with this coin five times consecutively, so the chance of tails coming out on the sixth flip is much greater than heads.”
  • Overgeneralization: Extrapolating limited experiences and evidence to broad generalizations.

Sometimes journalists, politicians and even experts are affected by the overgeneralization bias and write like this: “The scientists confirmed global warming”. Try to replace words like “the scientists” or “the experts” respectively by “some scientists” and “some experts” which usually reflects the reality. It will give a very different meaning to the text. Be aware that identifying another’s bias is easier than identifying your own and don’t forget some people will use tricks to consciously manipulate opinion.

2. Separate facts from opinions

Anyone can post anything online and this is a great opening for narcissist leaders and other fake experts with extrovert personality.  The internet is full of information coming from these sources and a lot is based on opinions rather than facts. A critical thinker is able to separate the two.

You will prefer references to recent scientifical studies. Serious papers will reference multiple sources. But as you will see in next point, mentioning references is not a guarantee that the information and its interpretation are correct.

Always verify the credentials of the experts.  Has the business expert only created one or two businesses or has (s)he created several ones facing difficulties? Is it easy to find information about them or does any data about their past seem hidden or difficult to reach?

3. Analyze the data

To be reliable, the source must be based on empirical data that is produced by observation or experiment. The theory based on the experiment must be refutable.

“A theory which is not refutable by any conceivable event is non-scientific”. Karl Popper

In human sciences, any experiment which aims to define a theory or methodology should be reproducible in at least 95% of the attempts. A good example of non scientific theory is the Freud’s Oedipus complex in psychology. There is no way to refute the theory because Freud states that if the behavior doesn’t appear, it’s because it is repressed.  There is no way to validate or invalidate the theory. Even if there is a possibility than the theory is true, there is no way to verify it and so it should treated with care.

Here are the research methods commonly used in human sciences:

  • Observation: usually the first step of research to attempt to identify potential causes of a behavior.
  • Surveys & tests: if you can’t observe thoughts, we can ask people to describe them. The problem with surveys is that you can’t be sure that the answers are correct.  Social desirability bias, demand characteristics, memory errors are some of the problems you will encounter in addition to the sampling bias. After that, when you interpret the results using correlational approach, it’s impossible to prove that changes in variable A causes changes in variable B. At best, this method can be used effectively to describe or predict a behavior (what), but not to explain it (why).
  • Case study: this is the most popular research method in software as it is easy to do. Observe a few persons and try to determine a pattern. You can’t really prove a causal effect,  just like with surveys. But like observation, this is a good first step for the experimental approach.
  • Experimental: the experimental approach is the only type of methodology that, if well conducted, is able to make causal statements.  They are very difficult to carry out, especially in the field of software development. A well conducted experiment will include the following:

Have you ever read a book written by successful entrepreneur or software developer that converted his own and unique experience into a methodology? Your critical thinking would force you to evaluate the methodology by calculating how many successes have been made out of the millions readers. How many of these would have been successes anyway even without applying the methodology? As a reader with critical thinking you will be able to take what is useful in the book and leave the rest for what it is: a case study at best, observation in most cases. This applies, of course, to any source of information.

But even the results of well conducted studies can be wrongly interpreted, consciously or not, by the person that mentions it. Sometimes it is even conscious: a great example is how some people are caught lying with statistics. Politicians against the decriminalization of marijuana claimed that studies showed 87% of heroin addicts started by using cannabis. Cannabis would  therefore lead inevitably to hard drugs. What they forgot to mention are the millions of people smoking cannabis that never use heroin. The information is true, but manipulated.  In fact, we could present a study that demonstrates that 100% of heroin addicts used coca-cola! Should we prohibit coca-cola?

The 3 steps

Developing a critical mind is not easy, and we must be prepared to accept that a certain number of our current beliefs are wrong. To summarize, here are the three steps to follow to ensure you won’t be intoxicated by the information you gather:

  1. Step 1: identify potential cognitive bias.
  2. Step 2: separate facts from opinions.
  3. Step 3: analyze the data.
To learn more

How much of your current knowledge and beliefs are opinions rather than facts?

Check the cognitive bias list on Wikipedia to learn more about them. You can read more about the different methods summarized above on this page.

Book recommendations:

            

8 reasons why you shouldn’t rely on source lines of code as a software metric

The estimate of the value of production of software based on the number of lines of code (LOC or KLOC or SLOC) is as popular as it is controversial. The main criticism is that there are too many factors influencing the final measurement value. Robert E. Park (1992, page 140), software metrics specialist & staunch defender of the method, responded to critics with the following:

“When we hear criticism of SLOC as a software measure, we are reminded of a perhaps apocryphal story about a ditch digger who, when asked one day how he was doing, replied, “Dug seventeen feet of ditch today.” He didn’t bother to say how wide or how deep, how rocky or impenetrable the soil, how obstructed it was with roots, or even how limited he was by the tools he was using. Yet his answer conveyed information to his questioner. It conveyed even more information, we suspect, to his boss, for it gave him a firm measure to use as a basis for estimating time and cost and time to completion.”

Originally, this technique could probably be used in the conditions mentioned by the Park. Later models such as COCOMO (Boehm 1981) also allowed developers take into account a number of parameters whose variability was probably reasonable at the time. But since then, the number of factors affecting the number of lines of code has become so important that it is very unwise to take this action seriously both in the evaluation of the software and the productivity of the design team.  I will try to illustrate the problem using eight arguments.

1. Different languages and different frameworks

Today hundreds of different languages exist (Wikipedia 2013).  For each of these languages there are several frameworks.  For the same functionality, there may be a very different number of lines of code produced depending on which technology is chosen.  In addition, modern architectures use different technologies, which further complicates calculations. Correction factors exist but they hardly seem defensible given the wide variety of types of applications that are being developed today.

2. Experience and competence of the developers

We must also take into account the experience of the developers involved as this may affect the calculation in many ways. A very competent developer often writes fewer lines of code than other less experienced developers because they will use design methods created for the sole purpose of reducing the number of lines and increasing readability and maintainability. In addition, they are more competent with the functionalities offered by tools (technology stack). Indeed, through ignorance of these, many programmers rewrite existing code, greatly increasing the number of lines of code.  In this regard, many experts in the area do not hesitate to speak of “lines of code spent” as opposed to “lines of code produced” (Dijkstra 1983).

3. The practice of refactoring

The fact that the same piece of code can change over time with the refactoring (reworking of code) can skew the results. This practice reworks the source code without adding functionality (Wikipedia 2013) and it is becoming more common because it can increase code quality and reduce technical debt. This can cause unexpected situations: if many developers practice this technique while the lines of code are being measured, the result could give the appearance of a reduction in output (fewer lines of code than in the previous measurement), while it is clear that the opposite occurs.

4. The practice of reuse and / or code generation

The reuse of existing code is very common and highly recommended in DRY (Do not Repeat Yourself). So many parts of the code can be retrieved from a previous project or copied from an open source project, library or another blog post. In addition, modern development tools can automatically generate code for the developer who works with various high level design tools.

5.  Tasks outside development

Activity in the development of software is not limited to writing code on a keyboard. In fact, many other tasks are needed to produce quality code. Here, a high variability can emerge according to the different methods used, the composition of the team or the documentation requirements.

6. The reliability of the measurement tool

A wide variety of measurement tools are available on the market. Given the lack of consensus on the method of counting the amount of lines of code in a source file, the outcome may be materially different depending on the tool used.  In addition, certain technical problems can arise when it comes to identifying what should actually be counted or not. For example, some software has difficulty differentiating comments from instructions when they are mixed (Danial 2013). The efficiency and quality of those source line counter is also very variable.

7. The (potential) manipulations

When a measure may have an impact on one or more person, we need to consider the possibility that some of them try to manipulate it to their advantage. Thus, if the productivity of a developer is measured based on the number of lines of code (or functions), they could very easily manipulate the source code to inflate the results. This problem is very common in companies that use KPIs to conduct assessments of their employees. One can also easily imagine a company trying to maximise the numbers if they know they will be evaluated based on this metric.

8. Time

Almost all the above elements are time sensitive. For example, the competence of a developer does change with practice (this includes the famous learning curve). More features of languages ​​and frameworks are also evolving to increase the productivity of the developers. The longer a project takes, the longer the measurement will be sensitive to this bias

Conclusion

In conclusion we can say that estimating the production effort or value of a program using this software metric is very risky. However, this technique is widely used. Some estimate experts such as Steve McConnell (2006) are very aware of the ineffectiveness of the method but still use it in the absence of anything better. Other methods based on “function point” (business functionality) have attempted to resolve some of the issues addressed above, but the values ​​remain highly correlated with the number of lines of code (Albrecht 1983).  For me, the information obtained by these metrics, and anything based on them, should never be considered as reliable and should be used with great caution in your decision making process.

Note: Some of the information in this text come from the fruit of the research I have done for LIEU (Liaison Entreprises-Universités) a network of valorisation units of Universities and colleges of the Wallonia-Brussels federation.

References

Albrecht, A. (1983). Software Function, Source Lines of Code, and Development Effort Estimation. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1703110&searchWithin%3Dp_Authors%3A.QT.Albrecht%2C+%2FA%2F.J..QT.%26searchWithin%3Dp_Author_Ids%3A37850740200

Boehm, B. W. (1981). Software Engineering Economics.  Englewood Cliffs, NJ. http://userfs.cec.wustl.edu/~cse528/Boehm-SE-Economics.pdf

Danial, A. (2013). CLOC Limitations. Retrieved the 2 august 2013 from http://cloc.sourceforge.net/#Limitations

Dijkstra, E. W. (1983). The fruit of misunderstanding. Retrieved the 2 august 2013 from http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD854.html

List of programming languages. (2013, July 30). In Wikipedia, The Free Encyclopedia. Retrieved 12:48, August 2, 2013, from http://en.wikipedia.org/w/index.php?title=List_of_programming_languages&oldid=566431816

McConnell, S. (2006). Software Estimation : Demystifying the Black Art.Microsoft Press. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/

Park, R. E. (1992). Software Size Measurement : A Framework for Counting Source Statements. http://www.sei.cmu.edu/reports/92tr020.pdf

Réusinage de code. (2013, juillet 5). Wikipédia, l’encyclopédie libre. Retrieved the 12:04, august 2, 2013 from  http://fr.wikipedia.org/w/index.php?title=R%C3%A9usinage_de_code&oldid=94719037

A personal kanban to beat procrastination

This personal kanban could just save your life.

This is an extremely simple method of personal organization based on concepts just as simple.

Along with many other advantages it will help you to:

Used in work (or family) teams a Kanban can also help to improve collaboration.

To make your personal kanban

You can get everything you need for around $ 50:

I chose products from Staples (prices may not be the same), but you can use whichever products you prefer, provided that:

  • The total area of the corkboard does not exceed 1.5′ x 2′. This is important – we will see why later.
  • The business card holder must be able to contain up to 30 notes or more.

Assembly is simple.

  1. Take a sheet of white paper and cut two strips along the length of about 0.3 inches. Place them vertically, equally spaced, on the corkboard.
  2. Although optional, you can add a heading to each of the three sections you have just created (you can use what is left of the white paper for this). The sections are: TO DO; IN PROGRESS and DONE.
  3. Finally, paste the business card holder at the bottom of the third section.

Once assembled, your personal kanban should look like this:

Personal Kanban

 

Implementation

The central element of your personal kanban is the backlog. The backlog is the list of everything there is to do. It is constantly evolving and to be effective, you must trust it.

Collection

Take the notes and begin to list all the tasks that are going through your head. Use one note per task. Do not worry if you forget something, one of the best things about this tool is that you can add things later to get them in the process. For more information on the collection process, refer to the description of GTD.  Fans of GTD will see how you need to have a kanban for each “location context”.

The way you describe your work is essential. The principle of “next action” should be used whenever possible.

For example if you need to call your telephone company to cancel your subscription, don’t write “cancel subscription”, but “Call Phone Company to cancel the subscription.”

The difference between these two descriptions is obvious. The first version describes your goal, while the second invites you to action. This technique is particularly effective against procrastination. Your mind is less likely to find avoidance strategies.

Prioritization

Once you have all your tasks on notes, you must prioritize them. Organize your tasks in order of importance. The strategy is simple: one task is always more important than another. When you set priorities, think long term. An important task that will become tomorrow’s urgent task should be completed before it becomes urgent. Having urgent tasks always creates more anxiety.

Planning

You must “plan” a maximum of five tasks on your corkboard. In other words, you can’t have more than 5 notes in total on the board. To add a new note, you must remove one that is in the “Done” section, provided of course that it is “Done”.

Ideally, you choose the five most important tasks of your backlog. But it may happen that you decide to group tasks for practical reasons such as economies of scale. If you need to do some odd jobs in the garden, it might be more advantageous to plan to do them together.

Execution

When you decide to start a task, you take the note and put it in “In Progress”. This indicates that you really will do the job. If for any reason you decide to put off the job without having begun it, replace the note in the first column.

Here is a very important rule: Never have more than 2 notes in “IN PROGRESS“.
This stops you from starting to do several things at once without completing any of them; one of the root symptoms of procrastination. This simple rule prevents you from having to waste more time choosing between tasks and means that you can advance.

You can browse your backlog regularly (every 2 to 3 days for example), and update and then re-prioritize if necessary.  You add task notes to the “To Do” section as you take them from “Done.”

You can add to the backlog but you should only ever take a task out of the backlog if its completion would no longer provide you with the intended value.

This process is perpetual. That is to say that there is no end.  We will always still have things to do, that is “situation normal”. If you can accept this fact, it will really help you to reduce any feelings of stress.

How does it work?

The problem that all methods of improving productivity face is the need to fight procrastination. Procrastination fuels anxiety.

When you procrastinate, your mind seeks avoidance strategies and your energy goes into implementing them rather than the tasks. Having only a few tasks that are permanently visible allows your mind to unlock faster. This phenomenon is greatly amplified by the power of the “next action” that calls for action and not for more reflexion which just feeds your toxic thoughts.

Procrastination often happens because you are discouraged by the feeling of having too much to do. For this reason, the size of the board only allows you to displays a limited number of tasks.

How do you eat an Elephant? One bite at a time!

Having a list, or backlog, (and being able to review and update it) gives you peace of mind.  When there are too many unknowns your thoughts often go in all directions in search of potential threats rather than focussing on what needs to be done.

The kanban is more effective than the standard task list, because a long task list, although it helps you to see all the tasks clearly, sometimes generates as much anxiety as it removes.

Seeing a big task list can really discourage you so you must make your task list accessible but not visible. You can do this really simply with the personal kanban. Place the notes in the business card holder. Your list will instantly seem smaller than it is. The first note in the stack is the most important and therefore it is most likely where you need to start.

The personal Kanban reassures you.  Your tasks are visible but, thanks to the contrast between the notes tucked away in the business card box and those displayed on the board, the size of the backlog is not advertised. Your attention is directed naturally to what matters most at that moment i.e. the 5 tasks on your board.

Also, having a real, physical board which involves you in real action promotes a direct link between your brain and managing your tasks. Taking a task and moving it across your board creates a concrete sense of accomplishment: much stronger than when you click on a checkbox in software.

Another thing that typically causes anxiety is the fear of forgetting something.  The availability of the backlog, easily accessible and convenient, removes this fear. Having the backlog (and regularly updating it) means you can relax.

Finally, the prioritization of the most important tasks allows those which are the least important to fall back to the bottom of the list. You lose less time dealing with trivial things and you are in control of how much time you give to those tasks.

In praise of technical support

I’ve been doing technical support for the last 13 years and still do it today, I love it.  I love it so much that I’ve now got friends all over the world.  I used to have a map of the world in my office with pins that located them.  I’ve even been invited to the wedding of one of them on the other side of the planet, which I attended with great pleasure.  This is invaluable experience and just for that, I’ll continue for the next 13 years in the exact same way.

But in addition to the social aspects that are obviously linked to my personal interest in multiculturalism, technical support is a real opportunity to grow for both developers & business owners.  Support connects you to your users and it’s one of the best channel of gratification you may have.  The comments and suggestions you receive positively from it help you improve your products, skills or strategy.  If you are doing great at support, there is a great chance you are or will be great as an entrepreneur or lead developer.

There are many motivational theories and they are not universal as we are all different. We are all driven by both extrinsic and intrinsic motivation at different levels.  A good example of extrinsic motivation is salary or threats (the donkey, the carrot and the stick). You do support because you are asked to do it or only for money (or because potential loss of money), or both.  Intrinsic motivation on the other hand is the motivation you get from just doing the task.  You are aware of your own performance and you are not specifically seeking for extrinsic motivation.  In fact, that kind of motivation often comes naturally afterwards.

Many, many thanks Pierre for helping me out […]. It’s rare to get such service and I really appreciate it. […]. I owe you a beer or three next time I am in Brussels!” A customer from UK

Because technical support agents are often at the very bottom of the hierarchical pyramid, it is likely to be perceived as a low profile job.  Many technical support guys try to do the bare minimum and hope they will be promoted soon to get out of that awful situation.  I believe it’s the exact opposite.  The essential skills needed to be a great technical support agent are the same you need to be a brilliant developer or successful entrepreneur.  Great developers & great entrepreneurs have strong interpersonal skills.

Strong interpersonal skills include being genuinely interested in your users and being able to put yourself in their shoes.  Empathy through social awareness is one of the core element of emotional intelligence.  If you don’t understand your users, you will face strong problems.  Some users have difficulties expressing their needs or feelings.  Your great ability to decode what your customers need or want will not only make them happy, but also help you improve your products and overall company strategy.

“I must say Pierre that we are very impressed so far not only with the product but with your overall attitude and all the assistance you have given us. I can’t thank you enough but hope to thank you soon as a customer.” A customer from US

Because support is an integral part of your product, support is also one of your main sales & customer relationship channels.  A study conducted by RightNow® Technologies has found that 46% of Australians declared they would leave their current internet provider because of poor customer service.  The same survey states 21% already left a previous provider for the same reason.  How many customers can you keep or get with a great support?  In software development, support is often the first human to human contact your customers get and how it will goes will be weighted in their overall perception of your product.  In fact, your product is not the bits that get downloaded and installed on your customers machines, your real product is the whole experience your customers will get with your company.

Since your product is your company, including its support, any assistance you give to your users should be free and optimized.  To make it painless for both our users and ourselves, we try to use the following procedure once we receive a request:

  • If it’s a reproducible bug, we add it into the backlog and give its ID to the customer/user. We also take the ID of the customer/user to notify him of resolutions and releases personally. This is easy if you collect his email directly.
  • If it’s a problem using the software, we take this as an opportunity to improve the documentation.  Any answer is written like a knowledge base article that we add in our database afterwards.  It takes triple the time to write, but we don’t have to repeat ourselves later (most users prefer browsing in KB).
  • If it’s a feature request we connect the user with the product owner directly.  This is very valuable.  Of course we use systems like uservoice.com, but talking with the user directly is a lot better.
  • If it’s a complaint we try to manage that outside the process.  People that complain like to be considered as important (even if the complaint is trivial).

Support is your free & perpetual market research.  Support is one of your main sales channels. Support is your opportunity to learn how to improve your social awareness.

How to become indispensable

All social groups seek the company of people who help them reach their goals. For example a network-gaming oriented group will generally be composed of people with profiles compatible with the purpose of the group: gamers. On the other hand, people with generally incompatible profiles are rejected. This becomes a problem when someone still wants to join with an inconsistent group. The only solution for that individual is to adapt and align their goals with those of the group, or find another group compatible with their current profile.

In the case of a social group, this process is more or less unconscious. In a company, it’s the same thing, but with the aggravating circumstance that you generally cannot choose. If you are not aligned with corporate goals, you will eventually pay the price. On the other hand, if you understand that the closer you get to the corporate goals, and show that you will help achieve them, you will become indispensable.

This type of person was recently named the Linchpin in the latest book by Seth Godin (which has the same name). Here is his description:

There used to be two teams in every workplace: management and labor. Now there’s a third team, the linchpins. These people figure out what to do when there’s no rule book. They delight and challenge their customers and peers. They love their work, pour their best selves into it, and turn each day into a kind of art.

Linchpins are the essential building blocks of great organizations. They may not be famous but they’re indispensable. And in today’s world, they get the best jobs and the most freedom.

This book is really worth every penny, and if you like this article, I strongly suggest you to buy it as it is full of similar content.

In this article I will tell you about a simple and effective way to become indispensable: make sure you do not create new problems, and on the other hand, that you solve a lot. Become a problem solver.

The trick in organizations is to identify what is “creating a problem” and what is “solving a problem“. For example it is not necessarily creating or resolving bugs. It’s evident that if you create many bugs, you’re creating problems, even though when you solve them, you are solving problems. I will focus on another kind of behavior that can be considered, generally unconsciously, the same as the act of creating problems. Some problems that you are not directly responsible for will still be associated with you just because you report them. Or worse, you don’t report them. Here are examples of behavior that will be seen by your management as problems that you create (or bring) while this is not necessarily the case:

  • You complain to your hierarchy about your work environment.
  • You indicate that your application has serious performance issues.
  • You report that the components suite that you purchased is not suitable for your needs.

All these examples are your problems until you talk to your manager. They become the problem of the manager from the moment you bring them to him. Even if you are not directly responsible for these worries, you’ll be automatically associated with them. The average manager has no time to deal with new problems and he will try to avoid anything related to them.

The first tip is to manage them yourself as much as possible and thus to take responsibility. You have everything to gain with this attitude. Because in this case, you do not create the problem, you are really solving them! Very few people have the ability to take responsibility for such decisions. But we can develop that talent by doing. When you face a problem, ask yourself the question “can I myself, or with the help of my colleagues solve this problem?

Unfortunately in many cases this is not so easy. You will simply not be able to adopt that attitude for organizational reasons, such as hierarchical approval processes. If you can’t be the decision maker, you must pass it to the management. Faced by what seems to be a great constraint, there is a very simple technique that is used by the indispensables and almost always overlooked by others: report the problem and your recommended solutions.

Too many people limit themselves to reporting the problem and then are inevitably associated with it. When reporting the possible solutions you are associated with them and then credited for what you’ve become: a person who solves problems. Someone absolutely essential to keep in the organization in contrast to those who create the problems and who it would be better to get rid of.  The more you act this way, the bigger your circle of influence grows. Your opinion will have more and more value. While you are improving your company, you’ll also improve your own working conditions.

Just like the basic concept, the technique is extremely simple to remember. When you encounter a problem that affects you or your company, do the following:

  1. Identify possible solutions to the problem.
  2. If you think you can solve the problem directly, without the advice or approval of a tier, do it without hesitation.
  3. You cannot (yet) make the final decision? Then report the problem with the solutions obtained in step 1.

Examples repeating the above examples:

  • You complain to your hierarchy about your work environment: if the problem can be solved with a purchase, specify the references of the desired material as well as all associated costs. Don’t forget to explain how you are affected and how it impacts the company.
  • You indicate that your application has serious performance issues: don’t excuse yourself, they don’t care. Recommend potential architecture changes instead or at least an external expert that could come up with more advice.
  • You report that the components suite that you purchased is not suitable for your needs: propose a few alternatives that you have tested and always give your personal opinion (what you would pick if you were the boss).

Additional tips to write an effective problem/solution report:

  • Be convincing by using an appropriate response structure (see this article).
  • Write your email so your boss just has to write the word yes or no in his reply.
  • If you have many problems to report together with your solutions, send them in one mail only, even if it’s more logical to have separate threads in case of discussions. The average boss will generally try to avoid discussions.
  • Focus on the problem and the solution and only that. Avoid talking about people when possible.

Becoming indispensable to someone is a lot about solving his problems and having the same goals. Companies are seeking problem solvers. Become one of them.

 

How to choose a technology that has a future

As you build your career, you must make choices. One of the most difficult choices to make is in deciding which  technologies to invest in.  It is not unusual to see consultants who have invested years of their lives in a technology that will eventually be abandoned by the market or its designer. It is virtually impossible to predict the future at this level and the best strategy is to learn how to learn, and be a programmer, regardless of the technology or language. Above all it is always better to invest in things you enjoy doing.  On the other hand there are simple ways to get an idea of what is in demand right now and act accordingly. Simply check for the skills that companies are currently seeking. The law of supply and demand – get it?

One effective method to get answers is to go on large sites offering jobs such as jobserve.com. At the time of writing this post, joberve.com offers no less than 14.626 jobs in IT, just for the United Kingdom!  If you add other countries like the United States, France or Germany, the figure explodes.  The ideal is to use a site that is popular in your region or country.

Browsing the latest offers of employment will give you a pretty good idea of what is being sought. The more criteria you add, the more accurate will be your answer. So if you can only work in the London area, there is no need to search in San Francisco. It is pretty obvious, the nature of IT projects developed in these two cities can be very different.

This research can be tedious. Fortunately, another site that offers jobs provides a faster way to determine the technology application, but at some cost. This is Careers 2.0 by StackOverflow and has an amazing technology tag feature.

I was able to obtain figures in under 5 minutes using the following technique: I created a sheet in my favorite spreadsheet. I typed each tag that I found, one after the other – for the latest 25 bids only (1 page) initially. I then aggregated the occurrences and found myself with a list of technologies and the number of times each was mentioned overall. The following result is for the latest 25 or 50 job offers near London (occurrences are in % for comparison).

Tag occurences by technology

I compared 25 to 50 because it is well known that the more data you have, the more accurate the result you have. With the 25 latest job offers, I got a total of 120 tags, reduced to 56 after aggregation. When I took the latest 50 job offers, I got 235 tags reduced to 89 after aggregation. You can immediately see without having to do much calculation that the latest 25 job offers is more than sufficient.  Adding more offers did not change the result significantly,  keeping a satisfactory validity for our purpose: having some indication of what is in demand.

Now that we have our results for Careers 2.0, can we generalize them (external validity)?

Of course not!  And this is the main issue.  There is an obvious website bias involved.  Careers 2.0 provides us with a convenient way to test technologies thanks to their amazing tagging system, but companies posting on it are not representative.  It has only 83 job offers for the London area at the time of the test (12th of July 2012). Jobserve.com on the other hand has 8,657 jobs available for the same criteria.

Careers 2.0 is growing fast, so we can expect that in a few years it will be the reference for programmer’s job vacancies and will provide more accurate data.   For now, use them as an indication and nothing more. Until then, be sure to develop your ability to learn and give priority to technologies you love working with rather than just the ones that are currently in demand. Success almost guaranteed!