Why I Deleted the Facebook App from my Smartphone

delete-facebook-accountToday I deleted the Facebook app from my smartphone. I’ve been considering doing that for a long time, but my final decision came when I understood what was happening to me:

The posts that I created on my free time were afterwards consuming my non-free time.

This is a very simple but also very subtle phenomenon. This vicious circle works like that:

  1. You have some free time, and then you decide to post something on Facebook just to avoid wasting this time, or just because you are bored.
  2. People start liking and commenting on your post, and then you get alerts and go back to Facebook to check who is liking and commenting.
  3. Since you are back on Facebook, you will reply to some comments, and probably like and comment on other people’s posts as well.
  4. Now you will get even more notifications, because besides your original post you will be probably involved in several discussion threads.

The main problem with this sequence is that the only activity that was really done in your free time was number (1). In all the subsequent activities you are probably being distracted by notifications when you should be doing something else.

The only way to avoid this chain is to avoid posting in the first place. In other words, you should only post on your free time if you can assure that you will also be able to handle all the ensuing notifications on your free time.

Other Problems with Facebook

Of course, wasting our scarce time is not the only problem with Facebook. I recently read two very nice articles that I would like to share with you.

The first is called “How to Spot a Narcissist on Social Media” by Aleksandra Atanasova. She says:

“Increased Facebook use is directly linked to narcissism in adults… As psychologist Eric B. Weiser states – social networks may create or reinforce narcissistic tendencies because they serve primarily as self-promotional platforms.”

The second article is called “Quit Social Media. Your Career May Depend on It.” by professor Cal Newport. He says:

“A dedication to cultivating your social media brand is a fundamentally passive approach to professional advancement. It diverts your time and attention away from producing work that matters and toward convincing the world that you matter.”

The messages in these two articles really resonate with me. I read both of them just after I deleted the Facebook app from my smartphone. If I kept using my “free-time” to browse my Facebook stream, I would not have found these articles. But for sure I would see unforgettable pictures of cute dogs and cats…

Posted in Efficacy, Social Networks | Tagged , | Leave a comment

Recommended 20 good habits by James Altucher

In general I make some personal comments on my posts, but the habits below are so clear and objective that I prefer to share them as-is. Credits go to James Altucher.

altucher

Posted in Efficacy | Tagged | Leave a comment

When Software Development Depends on Individual Heroic Efforts

success failureIt is a well-known fact that many software projects fail. Thus it is natural to ask: what is the main contributor for the success of software projects, the processes or the people? In other words, we may ask who has the better chances to succeed: a great team with no emphasis in the process or an average team with a well-defined process?

The Capability Maturity Model (CMM) is a tool to assess the ability of software development organizations to implement software projects. There are five levels defined in the model, which represent gradually improving degrees of capacity to build software systems in a predictable and effective way:

  1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
  2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
  3. Defined – the process is defined/confirmed as a standard business process.
  4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
  5. Optimizing – process management includes deliberate process optimization/improvement.

In particular, I would like to focus on Level 1 – Initial (Chaotic):

“It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.”

rbso_13In this case, software developers are “reacting to events”, in a similar way to which firefighters react to emergencies.

Here is anoter definition by Tom Schorsch from his article “The Capability Im-Maturity Model (CIMM)“:

“Level 1 – Initial Ad hoc and Chaotic: Few processes are defined, and success depends more on individual heroic efforts than on following a process and using a synergistic team effort.”

Tom uses the expression “individual heroic efforts”. Indeed, for organizations at this level, the only chance of success is the heroic behavior of software developers. Again, like firefighters, programmers must risk their own health to deliver a project.

Individual Heroic Efforts are Harmful

The fact the we are comparing programmers to heroes does not mean that this is a positive and desirable situation. No organization should be proud of having its software developers doing such sacrifices in order to succeed.

Sammy Larbi wrote a nice article “Rewarding Heroic Development Promotes Bad Behavior” in which he says:

“When developers have to stay up all night and code like zombies on a project that may very well be on a death march, you’ve got a problem, and it’s not solely that your project might fail. Even when that super heroic effort saves the project, you’ve still got at least three issues to consider:
– Was the business side too eager to get the project out the door?
– Are the developers so poor at estimating that it led to near-failure?
– Is there a failure of communication between the two sides?”

Note that the term “Heroic Programming” also has a negative meaning:

“Heroic Programming, usually a pejorative term, is used to describe the expenditure of huge amounts of (coding) effort by talented people to overcome shortcomings in process, project management, scheduling, architecture or any other shortfalls in the execution of a software development project in order to complete it. Heroic Programming is often the only course of action left when poor planning, insufficient funds, and impractical schedules leave a project stranded and unlikely to complete successfully. It is highly probable that more projects are, in fact, completed by acts of Heroic Programming than by proper analysis, design, architecting, planning, scheduling, budgeting and implementation combined.”

Heroic Efforts are not Sustainable

In my opinion the main problem with these Individual Heroic Efforts is that they are not sustainable over time. Eventually the software developers will lack the necessary motivation to make such sacrifices. In particular this will happen if a project fails despite the heroic efforts of the programmers.

Dan Ariely in his paper “Man’s search for meaning: The case of Legos” describes a series of experiments to show that the effort that a person invests in a task depends on the meaning of this task. Here is the description of the famous Lego experiment:

bionicle“In each of the two conditions, subjects received payments for assembling Bionicle Lego models…

In the Meaningful condition, after the subject would build each Bionicle, he would place it on the desk in front of him, and the experimenter would give him a new box with new Bionicle pieces. Hence, as the session progressed, the completed Bionicles would accumulate on the desk.

In the Sisyphus condition, there were only two boxes. After the subject completed the first Bionicle and began working on the second, the experimenter would disassemble the first Bionicle into pieces and place the pieces back into the box. Hence, the Bionicles could not accumulate; after the second Bionicle, the subject was always rebuilding previously assembled pieces that had been taken apart by the experimenter…

Results: Despite the fact that the physical task requirements and the wage schedule were identical in the two conditions, the subjects in the Meaningful condition built significantly more Bionicles than those in the Sisyphus condition. In the Meaningful condition, subjects built an average of 10.6 Bionicles and received an average of $14.40, while those in the Sisyphus condition built an average of 7.2 Bionicles and earned an average of $11.52.”

Thus we may expect software developers to continue their heroic efforts as long as their success is “accumulating on the desk”. But if for some reason the project fails and their sacrifices bring no fruits, they will not be able to keep working with the same motivation as before. And then the organization will be in serious trouble…

Posted in Efficacy, Psychology of Programming | Tagged , | 3 Comments

Why I don’t plan to retire

work retireIt seems that most people would like to retire as soon as possible, and they also have several dreams about the things they will do when they finally retire. I don’t. I would like to continue working as long as my health permits. My goal is not to stop working sooner, I would like to keep healthy longer and use my remaining strength to do something productive.

This is because my job is much more than simply a source of income. Perhaps I’m extremely lucky, but I really derive lots of pleasure from my work. As a software developer, I’m constantly facing new challenges, and I always have something new to learn. The activities involved in building software systems combine imagination and creativity with the need for organization and planning.

Working for pleasure since my first job

This was true also in my first job, when I was 16 and started working as a programmer. I didn’t need the money. As all my friends, my father would give me a monthly amount sufficient to cover all my expenses. And indeed none of my friends had any desire to work at that early age. But I was different. I knew I could use my programming skills to create real systems with business value. My work was the best way to achieve that.

I actually stopped working at the same time all my friends started looking for their first job. At age 20 I was beginning my last year at the university. I wanted to do a Master’s degree, and in order to improve my grades I decided to stop working and dedicate more time to my studies. Most of my colleagues did the opposite: they started looking for their first job. At that time I already had four years of practical experience as a professional software developer.

Retire early die younger?

Several scientific studies have reached the counter-intuitive conclusion that people who retire early may also die younger. For example:

“A study of Shell Oil employees shows that people who retire at age 55 and live to be at least 65 die sooner than people who retire at 65.” [1]

The Healthy Retirement Study found that “healthy retirees who worked a year longer (over the age of 65) had an 11% lower ‘all-cause mortality risk’.” [2]

Of course I’m not saying that people should continue working to avoid dying prematurely. But I do believe that work is an integral part of our lives. I think that human beings have the need to use their available time and energy to produce, create and build. The person who stops working and at the same time stops contributing to any endeavour outside his personal desires is actually becoming handicapped.

Posted in Efficacy, Uncategorized | Tagged | 1 Comment

The Cat as a Metaphor in Object-Oriented Software Development

booch-bookGrady Booch is a software development guru who wrote one of the most important books about Object-Oriented Programming: “Object-Oriented Analysis and Design with Applications“. In his book, Booch has wonderful illustrations using a cat as a metaphor for some of the main OOP principles. I bring here some of these pictures that certainly may serve as a source of inspiration.

Systems and Sub-Systems

cat-system

Abstraction

cat-abstraction

Modularity

cat-modularity

Encapsulation

cat-encapsulation

Persistence

cat-persistence

Other people have also adopted the cat as a metaphor for software development. Below is a very nice cartoon from the site “Sandra and Woo“:

2012-11-19-0430-software-engineering-now-with-cats

Posted in OOD, OOP, Programming | Tagged , , | 2 Comments

The Logic of Procrastination and the Last Responsible Moment

I had a good friend in a previous job who had this unbelievable procrastination habit. He would always wait to start his tasks as late as possible. But this was not because he was busy. He intentionally waited to begin working as close as possible to the deadline. I asked him to explain his behavior, and then he said:

“It is stupid to work on your tasks as soon as possible. Many of your tasks will simply be canceled before you finish them. Others will be postponed because their priority will be changed. And most tasks will have their requirements changed. So, by waiting to work on my tasks as late as possible, I am avoiding lots of wasted time and efforts.”

Depending on the culture of your workplace, this makes complete sense. Thanks to his procrastination principle, my friend was able to avoid:

  • Working on tasks that will be canceled.
  • Working on tasks that will be postponed.
  • Implementing requirements that will be changed.

This is very aligned with the Last Responsible Moment principle of Lean Software Development:

“A strategy of not making a premature decision but instead delaying commitment and keeping important and irreversible decisions open until the cost of not making a decision becomes greater than the cost of making a decision.”

In the case of my friend, he was not only avoiding making premature decisions. He was eliminating waste by understanding that, in his particular environment, the nature of his tasks was very ephemeral.

How frequently will you face such situations, in which your tasks are canceled, postponed or changed? That depends on your role and the culture of the company you work for. As illustrated in the Dilbert’s cartoon below…

dilbert architect

Posted in Agile, Efficacy, Lean Development | Tagged , , | 1 Comment

Passion vs. Focus

I believe that software developers should have a passion for programming. In one of my previous posts, I claimed that nothing is more effective than enthusiasm. This passion should include a constant desire to learn new things and to create pet projects to put in practice the things you are learning.

However there is a danger in having too many side projects: some programmers have so many ideas they want to try that they end up starting lots of such pet projects but never ending them. This is better depicted in the comics below (from CommitStrip):

Strip-Side-project-650-finalenglish
For a nice collection of comics about programming see:

Coding Explained in 25 Profound Comics

Posted in Efficacy, Programming | Tagged , | Leave a comment