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.


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










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“:


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):

For a nice collection of comics about programming see:

Coding Explained in 25 Profound Comics

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

Let’s Stop Having Insane Arguments About Software Development

stethoscopeMr. Smith had a serious headache, so he went to see a doctor. The doctor told him: “I think you should get some insulin.”

Mr. Smith replied: “Are you crazy? Insulin for a headache? Why do you say that?”

The doctor answered: “I’m an endocrinologist. I treat people with diabetes; all my patients get insulin and feel much better.”

Then Mr. Smith went to another doctor, complained about his headache and the doctor told him: “I think you should try radiotherapy.”

Mr. Smith replied: “Are you crazy? Radiotherapy for a headache? Why do you say that?”

The doctor answered: “I’m an oncologist. I treat people with cancer; all my patients get radiotherapy and feel much better.”

Well, I think you get the idea. Now let’s talk about software development…

The Insane Arguments About Software Development

I’ve been working as a professional software developer for more than 20 years now. This field is only getting more complex and diversified with time. Today we have dozens of different programming languages in use. We have people building Web sites and mobile apps, and software projects that may be classified as front-end, back-end, server-side, real-time or embedded. All the people working on these different kinds of systems call themselves software developers. And they are constantly arguing with each other.

Our personal opinion is based in our experiences. Why should a C++ programmer writing a server-side system have a similar experience to a JavaScript programmer using frameworks to build the UI of a Web site? Why should they agree on the relevance of Design Patterns? Why should they have similar opinions about Agile software development? How much these two guys have in common regarding the importance they give to non-functional requirements?

It is perfectly normal that for one software developer Design Patterns are extremely important, while another programmer has absolutely no idea about the difference between a Facade and a Decorator. I can also understand why some software developers are enthusiastic about Object-Oriented Programming while others think that Functional Programming is awsome. These are different opinions based on different experiences.

legoI think that most discussions about software development look like this:

“The best way to build things is using a hammer.”

“Wrong, if you want to build good things you must use a screwdriver.”

“Nobody needs such complex tools, I can build anything using chewing gum!”

“You are so primitive, I only build things using Lego blocks!”

Worse than the discussions about tools, are the arguments about methodologies. For example, it is easy to find software developers fighting each other because of their opinions about Agile methods. Some people will tell you that Scrum is wonderful, others will say that there is nothing better than Kanban, but many programmers are sure that Agile is not useful and in some cases may even cause real damage.

The Solution

In my opinion we need to stop talking about “Software Development”. It is too abstract, too generic, and as such not useful to have proper discussions. We may have a discussion about implementing “a server-side system handling thousands of requests per second with less than 100ms average latency”. Or perhaps we may discuss building a “highly responsive Web site that adapts to different browsers running on all kinds of screen size”.

The same is true about software development methodologies: we cannot ignore the factors that may influence the success or failure of an approach. What is the importance of the company culture, the team size, the developers’ skills and the system complexity? Have these developers built a similar system in the past? Were they using existing frameworks? Did the final system have 100,000 lines of code or a million lines of code?

It is very easy to observe our past projects and classify them into successes or failures. It is a bit more difficult to try to understand the many factors that may have influenced their outcome. It is even more difficult to imagine the impact of different conditions. We should be very careful to understand the reasons people may have different opinions before we start arguing with them.

Posted in Agile, Programming | Tagged , | 5 Comments