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

Defining Your Focus: Control and Consequences

I am constantly looking for new strategies to make more effective usage of my limited time. One of the approaches I use is to try to classify any issue according to two dimensions:

  • The level of control I have over this issue.
  • The importance of this issue’s consequences.

So there are issues for which I have lots of control over their possible outcomes, but for others not. Accordingly, there are issues that may have critical impact on my life, but others may be much less relevant. The combinations in these two dimensions create the four quadrants depicted below:

control and consequences

Let’s examine and discuss each one of them.

Low Control and Minor Consequences

These are the issues we should not be interested in wasting any time with. From one side we have very low control over their outcome, and from the other side they have a negligible influence on our life. For example, this category includes all kinds of events happening on distant countries. It also includes all kinds of gossip, sports, reality shows and stories about celebrities. As a consequence, I stopped completely to watch news on TV and to read newspapers. Since the media is always focused on tragedies, by not spending my time consuming this kind of information I also became a happier person.

High Control and Minor Consequences

This category sounds a bit weird: why would we have lots of control on issues that have minor consequences? But it actually includes many things we don’t really care about the result, even if we could influence the result. For example, this frequently happens when we are making decisions as part of a relationship with other individuals or in a team. So your wife wants to paint the walls beige, but you prefer white? Let her decide. Your colleagues at work want to eat Chinese food but you prefer fish-and-chips? Go eat Chinese with them, you can have your fish another day. Don’t waste your time with issues that have minor impact on your life.

Low Control and Major Consequences

In this case, the best thing we may do is to get prepared for the potential outcomes of events that may have a major impact on our life. This is the reason people make all kinds of insurances: life insurance, health insurance, home insurance. We have low control over accidents or sickness. This is also the reason people save money, have pension funds and invest their time making courses to acquire new professional skills. Even a person who is absolutely happy in his current job should consider the possibility that he/she may need to look for a new position in the future. I personally invest lots of time trying to be ready for the many “possible futures”.

High Control and Major Consequences

This is the category of issues that should get most of our focus and deserve our best efforts: the things for which we can actually control their outcome and that have a great impact on our life. The most obvious example is our work: our professional success depends on our dedication, and our career growth path can be planned and executed. It also includes the investments in relationships with the people who are closer to us: our family and our best friends. But unfortunately most people are not giving enough attention to issues that have important consequences for their lives because they are being constantly distracted by many things that should be totally irrelevant.

Posted in Efficacy | Tagged | 2 Comments

When Machines Learn: Predictive Analytics

CP 500In 1983, when I was 13, I got my first personal computer. It was a Brazilian CP-500 (in the picture on the right). I was one of the first kids in my class to have a computer at home, and so many of my friends wanted to come to my house to play with it. It was really a big attraction for boys my age at that time.

Once I invited a friend and started showing him all kinds of commands in BASIC. He was impressed by how the computer executed all my orders. Then he said:

“Ask the computer who is going to win the Brazilian soccer championship.”

I found that idea extremely funny. Trying not to laugh, I explained to him that computers were not able to make such predictions. At most they could execute some very simple instructions…

Well, 33 years have passed since then. And now I’m not a young boy programming in BASIC, I’m a data scientist applying machine learning algorithms to build predictive models. Yes, I’m developing systems that predict what will happen in the future.

More specifically, my goal at Pontis is to analyse the history of how subscribers reacted to marketing offers in the past, and then build models that predict how subscribers will react to marketing offers in the future. These models are built using very sophisticated machine learning algorithms.

Based on these predictions, the system automatically decides which marketing offer is most appropriate for each subscriber. This allows a new level of personalization, and accordingly increases the success rate of our marketing campaigns.

Thus my young friend was right after all. Computers may predict the future. Give them enough data and some smart algorithms, and they will learn how the world behaves.

Posted in Data Mining, Machine Learning, Programming | Tagged , , | 1 Comment

Copy-and-Paste Programming

I’m recently seeing lots of funny O’Reilly book covers being created by inspired programmers, but below is my favorite one. I like it because it depicts a big change in software development since the beginning of my career. In the past you could be an expert in some programming language and know very well all its standard libraries. But today, with the fast proliferation of new languages, libraries, frameworks and platforms, it became simply impossible to remember all the necessary details. As a consequence, programmers are always looking for coding examples, and copy-and-pasting them. What would we do without Stack Overflow?


Posted in Programming | Tagged | Leave a comment

Agile and Wrong: The Problems with Emergent Design in Pictures

Many idealistic Agile practitioners propose the idea of Emergent Design:

“With emergent design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile release cycle, development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance.”

Based on my 20+ years of experience with Software Development, I’m convinced that Emergent Design does not work. Below I discuss its main problems, illustrated with some nice pictures.

1st Problem: Software Systems Change

emergent1Emergent Design may be enough to create an initial design that will be right until it is changed. If a software design is not planned to support change, it will deteriorate very fast. As illustrated on the picture on the right, it may be challenging to keep the design coherent even for very simple systems. Since software systems always change, a design that does not support change is simply wrong.


emergent62nd Problem: Software Systems Grow

Emergent Design may be enough to create an initial design that will be right until the system grows. If a software design is not planned to support growth, its complexity will increase very fast. As illustrated on the picture on the right, the initial design may become a disaster when one of the components grows. Since software systems always grow, a design that does not support growth is simply wrong.


emergent33rd Problem: Dependencies are Important

Emergent Design is based on ignoring the big picture and designing only for the lower-level tasks (user stories). This may work well when these tasks are completely independent from each other, but in most software systems the dependencies are very important. If individual tasks are designed and implemented in the wrong order, ignoring their dependencies, the result may be a total mess, as illustrated on the picture on the right.


emergent24th Problem: Coordination is Essential

Emergent Design is based on the individual work of software developers, ignoring the need of a higher-level shared architecture and team-level cooperation. Each programmer is responsible for his own low-level tasks, which he tries to implement with minimal coordination with other team members. As illustrated on the picture on the right, this lack of coordination may cause a total deadlock.


The Solution: Define Clear Interfaces

screwdriver-setThe only solution to all the problems above is to define very clear interfaces among the modules in a software system. Of course, this definition of the interfaces must be done much before the developers start the implementation of the individual components. At the component level the low-level design may emerge, but at the system level there must be a pre-defined shared architecture. I give more information about my proposed approach for software design in my posts about Adaptable Design Up Front.

What do you think? Please share your experience in the comments below.

Posted in Adaptable Design, Agile, Software Architecture, Software Evolution | Tagged , , , | 13 Comments