Do we need more time or do we need more energy?

Busy people in general apply a simple formula: invest extra hours to get more work done. However I think there is a flawed assumption here: that the quantity of work accomplished grows linearly with the amount of time invested. Besides that, I also believe that in general there is a decrease in the quality of work done in these extra hours.

I’ve witnessed several times people forcing themselves to work additional hours when clearly they were not being productive anymore. I also observed tired people making terrible mistakes or making very bad decisions. The time required to fix these mistakes can actually eliminate any benefit obtained from working extra hours.

In my opinion people should focus on Energy instead of Time. We should ask ourselves: do I have the right energy level to produce this work? And if not, how can I obtain more energy, so that I will be able to produce the best possible work in my available time?

I don’t intend to prescribe here any formula on how people can get more energized. I think this is a very personal question, and each individual needs to find his/her own ways to obtain the energy they need to produce their work. I believe that following this approach people can be more productive while avoiding any need to work extra hours.

Energy Level

Posted in Efficacy | Tagged | Leave a comment

The Myth of Innovation and the First-Mover Advantage

Innovation_300x300Lots of people today dream about having their own startup company. These aspiring entrepreneurs are constantly looking for ideas, and in general they believe that a good startup idea must be very innovative, and better yet if they can be the first-mover in a new market. However if we analyze the most successful hi-tech companies today, we can observe that many of them were not so innovative, and most of them were not first-movers. A good example are Instant Messaging platforms.

WhatsApp is the leading Instant Messaging app today. It was created in 2009, and by the end of 2013 it already had 400 million active users. WhatsApp was acquired by Facebook in February 2014 for the amazing value of U$19 billion. By February 2018, WhatsApp already had a user base of over one and a half billion people globally. This is certainly a great success story! But can we say that WhatsApp was really innovative? Did it have any first-mover advantage?

Do you remember ICQ? ICQ was created by the Israeli company Mirabilis in 1996. That’s 22 years ago! It was acquired by AOL on June 1998 for U$400 million, which was the highest price ever paid to purchase an Israeli startup company. At its peak around 2001, ICQ had more than 100 million accounts registered. ICQ provided the same functionality that is provided by WhatsApp today, but of course ICQ ran on a desktop, and not on mobile devices.

So, can we say that WhatsApp’s innovation was providing Instant Messaging (IM) over mobile devices? Certainly not! Actually, I myself worked for two different Israeli startup companies that provided IM on mobile. The first was NomadIQ (latter acquired by OmniSky), and the second was Followap (which was acquired by Neustar).

NomadIQ was founded in Jerusalem in 1999. We developed IM and Location Based services for handheld devices such as the Palm and the PocketPC. These devices, which were also called Personal Digital Assistants (PDAs), were very similar in shape and size to modern smartphones. But they had to be connected to external modems in order to access the Internet. NomadIQ was acquired by OmniSky in January 2001 for U$40 million. Below you can watch a promotional video explaining our services at that time.

Followap was founded in Haifa in 1999. We developed IM services for the first mobile phones, which are also known as “feature phones”. At this time Nokia was the leading mobile phone manufacturer. The screen sizes were very small, and people had to write textual messages using the numeric keyboard. Even so, Followap services reached more than 200 million subscribers. Followap was acquired by Neustar in November 2006 for U$140 million. You can watch below a video explaining Followap’s services.

Now, after you have watched these videos, I ask again: Can we say that WhatsApp was really innovative? Did it have any first-mover advantage?

I think the answer to both questions is “no”. So perhaps what startup companies really need to be successful is the right timing. Companies such as NomadIQ and Followap had the right vision, but they were simply ahead of their time.

Posted in Israel, Startups | Tagged , | Leave a comment

Data Science vs. Software Engineering

Data ScienceThe work of a Software Engineer is to analyze a problem, think about a good solution, design it, implement it and then test it. Software Engineers do problem-solving. The work of the Software Engineer ends when he finishes implementing the solution for the problem.

The work of a Data Scientist is to make good predictions or classifications based on past behavior. The Data Scientist does not create solutions, he creates models that are able to generate such predictions or classifications. The Data Scientist then tries to optimize these models, so that the new models will generate better predictions or classifications than the previous models. The work of the Data Scientist never ends. In particular there is always more work when behavior is changing over time.

It may take lots of time until the Data Scientist is able to generate his/her first good model. The Data Scientist needs to analyze the data, clean the data, generate new features, select the best features, train models, try different Machine Learning algorithms, try different parameters for each Machine Learning algorithm and measure diverse offline metrics. Each one of these steps may require several weeks of work or even months.

Thus, the work of the Data Scientist should not have hard deadlines. It is very difficult for a Data Scientist to provide good estimates of when he/she may have a model that is good enough to be deployed in production.

Implementation vs. Experimentation

ExperimentSoftware Engineering teams are mostly busy implementing new features. Data Science teams are mostly busy running experiments.

A feature has a clear functionality being provided, and in general it is a solution to a problem. By the end of the implementation, the new feature becomes part of the system. The goal of implementing features is to add functionality to the system.

An experiment is a way to check a hypothesis. Depending on the results of the experiment, we may prove that the hypothesis is true or false. If we prove that the hypothesis is false, this does not mean that the experiment has failed. Our goal was to learn and we have learned. Based on what we have learned, we can make a new hypothesis and plan a new experiment.

It is possible that in most experiments we will prove that the hypothesis is false. This does not mean that we are wasting our time. It is natural that when facing new and complex problems we need to try many different approaches until we find one that works.

Data Science teams are like a laboratory. If we measure the progress of a Data Science team in the same way we measure the progress of the Software Engineering teams, we may reach the wrong conclusion that the Data Science team is not productive enough.

Posted in Data Science, Machine Learning, Software Engineering | Tagged , , | Leave a comment

Priorities and Maslow’s hierarchy of needs

Recently, when I was thinking about the priorities of a project I’m working on, I used as a source of inspiration the Maslow’s hierarchy of needs. This hierarchy is usually depicted as a pyramid, as you can see in the image below. According to this theory, human beings have some basic needs that must be addressed before anything else. I believe that this is true also in the case of a project: we must be able to identify which requirements are absolutely necessary, and which ones may wait until the basic needs were satisfied.


Posted in Efficacy, Requirements Specification | Tagged , | Leave a comment

KashKlik Pitch at TheHive Demo Day

DemoDayLast week KashKlik presented at the Demo Day, the event that concludes TheHive accelerator by Gvahim. There were more than a hundred people in the audience, including a panel of investors that judged the startups that participated at TheHive together with us.

KashKlik Team

KashKlik team during the event (from left to right): Ariel, Jacob, Galina and Hayim.

Below is the video of my pitch, followed by questions from the panel (in English):

From TheHive’s site:

TheHive was created in 2011 as the entrepreneurial branch of Gvahim, a nonprofit organization aiming at providing new immigrants with the tools to succeed in the Israeli labour market. Alongside Gvahim’s career programs open to a wide range of sectors, and special channels dedicated to medical professions and software engineers, TheHive responds to a specific tendency among new immigrants, who are more prone to launch into entrepreneurial adventure than the average population.

The accelerator is a multinational entrepreneurial environment where Olim, returning citizens and Israeli entrepreneurs all operate in a shared working space, with a wide mix of talents and ideas, to create a truly international atmosphere.

The 5-month Start-up accelerator program includes:

  • A community of international entrepreneurs who learn from, motivate and support each other.
  • Participation in the Google Launchpad: a one-week bootcamp at the Google Campus in Tel Aviv.
  • Access to capital: Connections to top investment firms, VCs and angels.
  • Top-tier mentors.
  • Office space in a creative co-working space in its two centers: Tel Aviv University and Ashdod.
  • Training, networking and office hours with experts.


Posted in KashKlik, Startups | Tagged , | Leave a comment

Everything is an experiment: on decisions and retrospectives

DecisionsIn decision-making, we try as much as we can to impact future results based on our previous experience. But every decision is also based on the assumption that its positive consequences will be greater than any possible negative outcome. Therefore, we should treat decisions as experiments. We should always preserve the option of reconsidering our decisions in the future, when we will be able to measure their real impact.

When making decisions, we should also prepare the tools and mechanisms that will allow us to collect feedback and evaluate the obtained results. In the methodology of Agile software development there are several such tools, including Burndown charts and Velocity charts. These charts help us measure the progress in the delivery of new features, providing immediate feedback that indicates if the execution is according to our plans.

Another fundamental concept in Agile methodologies are the Retrospectives. They are a planned opportunity for teams to analyze their own performance and discuss if there is any need to change the current processes. Thus we never assume that we are already following the most effective process and nothing needs to be changed. An integral part of the Agile mindset is the focus on continuous improvement, always looking for opportunities to deliver better results.

For example, a software development team may decide to adopt Test-Driven Development (TDD). The expected results may include improved quality and better design. But this decision should be considered an experiment. After some period of time, the team should verify if indeed TDD is having the intended consequences, and if there is no drastic negative impact such as a big increase on the time required to develop and deploy new features.

By treating decisions as experiments, and by having the tools to measure their results, we can be sure we are making progress in the right direction.

Posted in Agile, Efficacy, Software Quality | Tagged , , | 1 Comment

To Increase Productivity, Avoid Multitasking

Most people look for ways to increase their productivity. Many of them believe that they will be more productive by handling several tasks simultaneously, what is known as “multitasking”. But this is actually a trap! By trying to perform many tasks in parallel we just lose our focus and reduce the quality of our work. To be more productive we should actually avoid multitasking!


Posted in Efficacy | Tagged | 1 Comment

Digital Nomads: The Upside of Being Always Connected and Working from Anywhere

Today lots of people complain about being always connected to work. A recent study shows that:

  • 45 percent of workers feel obligated to respond to emails after hours.
  • 42 percent of employees feel obligated to check in with work while on vacation.
  • 47 percent feel guilty if they don’t work when sick, either on site or from home.

This situation certainly has many disadvantages, including the increase in work-related stress and the reduction of leisure time people spend with their family and friends. However I think each person has also the opportunity to enjoy the advantages of being always connected and able to work from anywhere.

The extreme example are the Digital Nomads, people who travel while they continue to work with clients or employers. They are able to visit new places and learn about other cultures and lifestyles, as if they were tourists, while at the same time they continue working remotely an making money.

But it is also possible to be a Digital Nomad part of our time. In the same way that we can travel for a business-related conference and enjoy our free time for tourism, we can travel mostly for tourism and enjoy some of our time to do work, without feeling guilty.

It may be very nice also to work near our home instead of working from home. We can work from places that inspire us, such as a beach, a park, a restaurant with a nice view or even a beautiful library. Such changes in environment probably have a positive impact in our creativity.

So I suggest this as a new-year-resolution for 2018: instead of complaining about being always connected to work, let’s find new ways to feel better while working remotely.

Happy New Year!


Posted in Efficacy | Tagged | Leave a comment

Temporary Solutions: Technical Debt in Pictures

Software developers are constantly told that they should avoid Technical Debt. But very frequently it is difficult to resist the temptation. Why not implement a good-enough temporary solution that satisfies all the functional requirements? The main problem is that very often this solution ignores completely the non-functional requirements. It is not efficient, nor robust, nor maintainable, nor scalable. I think this problem may be very nicely illustrated with the pictures below.

Car Dashboard1) Functional requirement:

The dashboard must have a knob to control the air-conditioning.




car window cleaner2) Functional requirement:

The back-window must have a wiper.




lock3) Functional requirement:

The door must have a lock.




mirror4) Functional requirement:

The car must have a side-mirror.





tire5) Functional requirement:

The car must have four tires.

Posted in Requirements Specification, Software Quality, Technical Debt | Tagged , , | 1 Comment

Sharing Some Bits of Wisdom

Sometimes I find some amazing content on the Web which I want to share with all the readers of my blog. The picture below was created by Anna Vital, and I think it presents in a very concise form some amazing bits of wisdom. It reminds us the importance of our attitude when dealing with challenges. Enjoy!


Posted in Efficacy | Tagged | Leave a comment