Learning from a Shipwreck

Posted on January 19, 2012 by Hayim Makabee

In the last week we followed the story of the Costa Concordia disaster, the cruise ship that partially sank after hitting a reef off the Italian coast. When I first heard about it, I could not understand how this was possible: We know that this kind of ships has a very well planned route, which should leave no risk for such a disaster. And we also know that with current technology it is very easy to provide alerts in the case a ship deviates from its planned route.

But then we learned that the captain had intentionally modified the ship’s route, apparently just to please some of his friends. And he certainly also ignored the alarms that followed this change in the route:

“Costa Cruises CEO, Pier Luigi Foschi, stated that the company’s ships have computer-programmed routes and alarms, both visual and sound, if the ship deviates by any reason from the stated route as stored in the computer and as controlled by the GPS, but that these alarms can be manually overridden.”

Finally, it was also reported that the evacuation of the passengers was delayed for no clear reason, which is another violation of the defined procedures. Actually, in the beginning the passengers were not even informed that there was a problem, probably to avoid panic.

This sad story makes me think about failures in software projects. As experienced software developers, we know that there are many risks involved when implementing a new system. We try to avoid failures by having:

  • A well-defined execution plan.
  • Mechanisms to measure progress with alerts for potential problems.
  • Recovery plans in the case something goes wrong.

However, what the Costa Concordia disaster teaches us is that these plans and alarms are only effective if the people executing them have discipline. A successful execution cannot be guaranteed by good plans alone; it depends on the ability and skills of the people implementing it. And for this reason, when choosing the right software developers for your team, you should always look for the best.

Posted in Efficacy, Hiring | Tagged , | 6 Comments

Hanukkah and Iterative Software Development

Posted on December 13, 2011 by Hayim Makabee

Hanukkah is a Jewish holiday that is celebrated during eight days. The tradition is to light candles every day, starting with one candle in the first day, then two candles in the second day, and continue adding one candle a day until there are eight candles in the last day. One possible meaning for this tradition is that we should always grow: The fact that a person is constantly growing and making progress becomes more important than the particular level he may be in a specific moment in his life.

Accordingly, in Iterative Software Development we understand that we do not have all the answers in the beginning of the project. We don’t even expect to have all the requirements clearly defined when we are assigned a new task. And we know that even if all the requirements were specified before we started the design, most probably some of them would change during the implementation. It is much easier to declare a code freeze than a “requirements freeze”.

Software as a Baby

In his classic book The Mythical Man-Month, Fred Brooks explains that software development is an incremental process, like pregnancy:

“The bearing of a child takes nine months, no matter how many women are assigned.”

The development of a software system cannot be reduced to the execution of a list of tasks completely known in advance, in which we can minimize the total implementation time by assigning more people to execute these tasks. Our understanding of the system will certainly change during the implementation, and thus these tasks cannot be really executed in parallel.

Now the question is: If we cannot know all requirements in advance, how can we progressively discover the requirements?

Software Prototyping

Some aspects of a software system cannot be completely defined before there is at least a partial implementation. For instance, the User Interface (UI): Without testing it, it is difficult to determine if a particular design of the UI will satisfy the customer needs.

The idea of Software Prototyping is to provide an incremental and progressive way to develop systems with partial functionality, allowing the developers to adapt to missing or changing requirements.

The process starts with the identification of the basic requirements, for which a prototype is built. Then the customers review this prototype and provide feedback on additions and changes. Using this feedback, the initial prototype is enhanced. These steps can be repeated several times: Each new version of the prototype is reviewed and can then be further improved.

Software Gardening

This incremental approach of software development is very different from other more traditional engineering disciplines. For example, we normally expect that the blueprint of a house should include all the details before we start building it.

In contrast, the authors of the book The Pragmatic Programmer say:

“Rather than construction, programming is more like gardening.”

In an interview, they claim that there are two main aspects that make software development so similar to gardening:

• You can never plan all the small details in advance: The plants in your garden will certainly grow.
• You need to invest a lot in maintenance: The plants may grow in unexpected and undesirable ways.

Going back to our candles metaphor, our role as software developers is to assure that the system is growing in the right direction, incrementally and progressively.

And of course, if you celebrate Hanukkah, then I wish you Chag Sameach!

Posted in Agile, Jewish Sources, Requirements Specification | Tagged , , | 7 Comments

TDD and the Gamification of Testing

Posted on November 21, 2011 by Hayim Makabee

The Test-Driven Development (TDD) methodology was invented to improve the way we test the code we write, with the final goal of increasing the quality of systems being implemented.  The basic idea is that the tests must be written before the code, and following the same requirements. In practice, adopting the TDD approach really caused an improvement in quality, even if in general the total development time also increased.

But in my opinion TDD is much more than a different way to test a system. I believe that it modifies completely the nature of the testing tasks. Actually, I think that this change is so profound that TDD was able to transform a hated activity in something that programmers can really enjoy.

In the past testing was something boring. Programmers didn’t like to spend much time testing their code; they preferred to delegate this task to the QA team. And it was considered normal if the testers in the QA team did find some bugs. After all, the software developers were too busy coding; they did not have time for all the repetitive actions related to testing. Most programmers felt that testing was an activity that did not require from them much creativity, neither used their special skills.

This reaction of programmers in relation to testing can be explained by concepts of Positive Psychology. According to the Flow theory, a person can only enjoy a task if there is a match between his abilities and the complexity of the task. As depicted in the graph on the right, when the person is skilled but the challenge is low the activity is considered boring. In contrast, when the person is skilled and the challenge is high, this can bring him to a state of arousal. In traditional testing methodologies there was a mismatch between the ability of software developers and the complexity of the testing task. The consequence is that programmers could not enjoy testing.

But TDD changes this picture because it transforms testing in just another type of programming task. When the software developers implement automated tests, they are actually writing code. Therefore, there is a match between their skills and the complexity of the testing task. Suddenly, testing becomes something that programmers can really enjoy doing.

This match between skills and complexity is in the root of any successful game. And TDD actually has some other characteristics that make it similar to games. This reminds me the concept of Gamification:

“Gamification is the use of game design techniques and mechanics to solve problems and engage audiences. Typically gamification applies to non-game applications and processes, in order to encourage people to adopt them. Gamification works by making technology more engaging, by encouraging users to engage in desired behaviors, by showing a path to mastery and autonomy, and by taking advantage of humans’ psychological predisposition to engage in gaming. The technique can encourage people to perform chores that they ordinarily consider boring.”

In TDD, using a framework such as xUnit makes the progress clearly measurable, like earning points. You start with a set of tests that are all “red” and gradually make them become “green”. It’s like a game: When all your tests are green, you win and this level of the game is over. Then you can move to a more advanced level, augmenting your challenge, either by adding new, more complex tests, or by performing some refactoring in the code that can potentially break some of the existing tests.

According to the book Gamification by Design: Implementing Game Mechanics in Web and Mobile Apps, another very important characteristic of games is their immediate feedback:  

“One of the most straightforward and important game mechanics, and one that is increasingly a cornerstone of the gamification movement, is feedback. Broadly defined, feedback is returning information to players and informing them of where they are at the present time, ideally against a continuum of progress.”

Every time you modify the code, you are actually taking the risk of breaking some tests. This generates the suspense of executing the tests after you made several changes in the code, to check the tests are still working. In practice, code refactoring can become an activity full of adrenaline. But the immediate feedback provided by automated tests allows you to take corrective actions in the case there were failures. At this stage, the coding-testing process can progress in fast iterations.

Sometimes you need to modify the tests because some requirement has changed. Of course in this case the right thing to do is to first change the tests and then the code. But I know that some programmers do exactly the opposite, and they first change the code and then check what tests were broken. This may be easier, because sometimes it is difficult to identify all the tests that are related to some specific requirement. Changing the code first is surely not the right thing to do, but it can be more fun.

If you still have any doubt that TDD is like a game, take a look in the TDGotchi application. I think it is a very original idea (but I must also say that I did not install it myself to check if it works).

So go on and have fun testing. It’s possible!

Posted in Agile, Gamification, Psychology of Programming, Refactoring, TDD | Tagged , , , , | 27 Comments

Yahoo! Cocktails: When the client is in the cloud

Posted on November 16, 2011 by Hayim Makabee

One of the reasons I’m proud to work at Yahoo! is that we have some very nice products that reach hundreds of millions of people worldwide. Another reason is that Yahoo! is behind the development of several advanced technologies and platforms, such as Hadoop. This is no coincidence, since sophisticated solutions are required to serve efficiently so many users and to handle effectively the huge quantities of data they consume and generate.

But the engineers inside the company are not the only ones to benefit from these innovations. Very often Yahoo! makes its technologies available to the broader development community. The latest such contribution is called Cocktails, a solution for the implementation of Web applications that addresses both the client and the server-side. Cocktails is based on a mix of standard Web technologies such as HTML5, Node.JS, CSS3 and JavaScript.

Yahoo! Cocktails is composed of Mojito, an environment-agnostic JavaScript web application framework, and Manhattan, a hosted platform (PaaS) for Mojito-based applications.

Mojito

Mojito is a JavaScript web application framework that can run both on the client and on the server-side. This allows developers to maintain the same codebase for the browser frontend and the server backend. During execution, if JavaScript is enabled in the device, the Mojito module will be deployed from the server runtime to the browser runtime. Otherwise, if JavaScript is not enabled, the same application will simply run on the server side.

Manhattan

Manhattan is a server-side JavaScript hosting environment for Mojito-based applications running on Yahoo!’s Cloud. It is a platform that provides essential capabilities such as security, scalability, high availability and monitoring. Manhattan is an extension of Node.JS that has a very simple interface for the deployment of Mojito-based applications. The fact that it runs on Yahoo!’s Cloud makes it possible for these applications to easily access services such as the Yahoo! Content Distribution Network.

Write once, run anywhere

One of the main promises of Cocktails is that the client code, based on JavaScript, can run on any connected device: Web browsers on the desktop, smartphones and tablets. The possibility of maintaining a single code base for all devices is a real advantage for developers. The benefits are in the form of reduced development time, easier maintenance and, in the bottom line, lower costs:

“Going forward, Mojito and Yahoo! Manhattan will allow you to develop ONE app and deploy it on several devices to lower cost, increase agility and keep a uniform design across platforms (web, mobile, tablet). With the power of Yahoo! Cocktails, you’ll be able to build that app – deployable on several platforms –in the same time it currently takes to build each app individually.”

When the client becomes part of the cloud

I think that the most innovative concept of Cocktails is that it transforms the client device in an additional machine running in the cloud. Since the client and server sides execute the same language, all code that runs in the client side may also run in the server side.

When the client starts, the server offloads its code to the device. If the client device is not able to run JavaScript, the client business logic simply runs on the server side. Moreover, if for some reason the client functionality becomes too heavy for execution on the device, it can migrate back to the server side and be executed there, improving the perceived performance.

In other words, the functionality associated with the client may run on the server, and this may be changed dynamically, following a decision based on performance issues. This in practice blurs the boundaries between client and server machines, and transforms the client device in an integral part of the cloud.

Present and Future of Cocktails

Cocktails is the technology behind one of Yahoo!’s most recent products: Livestand, a personalized magazine for tablets.

In the future, Yahoo! plans to make the Mojito framework available as open source and the Manhattan platform accessible to the community of developers of Mojito applications.

Check the video below for more information about Yahoo! Cocktails:

Enjoy your cocktails!

Posted in Cloud Computing, Software Architecture, Web Development, Yahoo! | Tagged , , , | Leave a comment

Super-Productivity

Posted on November 1, 2011 by Hayim Makabee

In a previous post I discussed the reasons some programmers are much more productive than others. But the fact is that every programmer experiences periods of time when he is much more productive than average, and I think there are several reasons for that.

Focus

It is clear that to be productive you must be focused. This means that, even if you have several things to do, and even if all of them appear to be important, you must be able to concentrate on a single task. This requires the ability to define your priorities and your posteriorities. Better yet, decide that there are things you do not really need to do.

Peter Drucker dedicates an entire chapter of his classical book, “The Effective Executive”, to this issue. In the chapter entitled “First Things First”, he says: “Most of us find it hard enough to do well even one thing at a time, let alone two”.  Thus, multi-tasking is something that should clearly be avoided.  

I believe that Agile Software Development improves focus because it reduces the granularity of programming tasks. Developers participating in a Scrum project normally have relatively small features to implement at each Sprint, and extensions are done iteratively. Agile methods also help the team to prioritize the tasks and focus first on the most important features, using artifacts such as backlogs.  

Problem Solving Mindset

Programming is an exercise in Problem Solving and as such it is natural that programmers dedicate a considerable amount of time to think about the problem, analyzing its several aspects. In general a problem will have diverse possible solutions, and in this case the programmer needs to compare these solutions and understand their advantages and disadvantages.

During this time spent thinking the programmer will not write any line of code, so it may appear he is not producing anything. But when he has completed his analysis and found a good solution, he can suddenly implement all the functionality very fast and with few errors, becoming Super-Productive. I believe that this ability to dedicate enough time to analysis before jumping to a solution is a key for real productivity, but unfortunately it seems that not all programmers have this habit.

This is similar to a chess game. Watching a chess game may be very boring, because most of the time nothing is happening on the board: The players are thinking. But after they have decided what to do and chosen a strategy, they can move very fast. Good chess players can plan many steps in advance, and thus avoid making mistakes.

Inspiration

Many programmers claim that software development is a form of art. I believe that this is partially true, because, like painters or musicians, programmers need inspiration to produce really great software.

Everyone has at least once faced a problem that at first appeared impossible to be solved. No matter how hard you examined it, you could not imagine a way to overcome its difficulties. And then, suddenly, you saw the solution. You were inspired by something or someone that allowed your brain to follow a different reasoning path.

There are also these days when you just wake up inspired. Everything will appear easier, you will just sit in front of the keyboard and let the code flow directly from your brain to your fingertips, typing new instructions as fast as possible. In these days you are Super-Productive, even if you will never be able to explain why. Unfortunately, there is no general recipe of how to become inspired.

Pressure

It is not easy to admit it, but the truth is that most people work better under pressure. It is very easy to postpone some action or decision if you know that you still have lots of time to implement it. Most programmers work much harder when they get closer to the deadline. They often regret being complacent in the beginning of the project, when it appeared to them that the allocated time was more than sufficient. But it rarely is.

I believe that Agile methods improve this situation by defining short development cycles. For a team working with Scrum, each Sprint has a well-defined set of tasks that must be completed in a few weeks. The end of each Sprint is a deadline, and it is always close enough to make the developers feel they need to work intensively, since the beginning. They programmers in a Scrum team cannot postpone their work, because their progress is being measured on a daily basis and exhibited clearly in a burn down chart.

In Summary

There are several factors that may help you become Super-Productive:

  • Focus: Defining your priorities and concentrating on a single task.
  • Problem Solving Mindset: Thoroughly analyzing the problem and comparing possible solutions before implementing.
  • Inspiration: That state of mind in which all your thoughts flow with amazing clarity.
  • Pressure: Having a well-defined deadline, ideally in less than a month.

Notice that three of these factors may result of using the right methodology: You can systematically become more focused, adopt a Problem Solving Mindset and follow a Software Development Life Cycle (SDLC) with short iterations. But you also need to learn what inspires you. For me, personally, inspiration only happens when I face a challenging task.

Of course each programmer may have his own personal reasons that help him dramatically increase his productivity. For some people it may be compensation for improved performance in the form of bonuses or prizes. For others it may be the feeling of full ownership of a project, like “this is my baby”. Please feel free to use the comments below to share your experience. Thanks!

Posted in Agile, Efficacy | Tagged , | 4 Comments

An Inspiring Jobs

Posted on October 11, 2011 by Hayim Makabee

With the recent death of Steve Jobs, I decided to learn more about his life and his many contributions to the world of personal computers. During my searches, I found a very inspiring speech he gave in a graduation ceremony at Stanford University.

In this speech to thousands of students that had just finished College, Steve Jobs said:

“Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle.”

I think this is a very important message for software developers, for two reasons:

The first reason is that programmers normally work long and exhaustive hours. The software development process can be very demanding and stressing. The only possibility of tolerating this heavy work load is to really enjoy what you do. I discuss the problem of the programmers’ hard work on a previous blog post: “How Decision Fatigue Affects the Efficacy of Programmers”

Besides that, I believe that programmers are fully productive only when they work with enthusiasm. Several studies have shown that there is a big difference in the quantity and quality of code produced by different developers, and in my opinion the main cause for this difference is that some programmers work with greater passion. I talk about that in a previous post: “Nothing is More Effective than Enthusiasm”

In another part of his speech, Jobs said:

“I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?” And whenever the answer has been “No” for too many days in a row, I know I need to change something.”

I think that this need to change is essential for software developers. Of course any human being needs to feel that he is evolving and making some kind of progress. But I believe that programmers in particular need to invest a lot in self-improvement, probably more than most other professions. I discuss this issue in my blog post: “The Effective Workplace”

Finally, Jobs makes these important conclusive remarks:

“Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.”

The death of Steve Jobs was certainly a great loss for the world. By studying his biography we learn that he was an example of vision, perseverance, creativity and innovation. I feel sad about his death, and greatly inspired by his work.

Posted in Efficacy | Tagged | Leave a comment

Research at Yahoo! Labs

Posted on October 9, 2011 by Hayim Makabee

My friends frequently ask me about the kind of research I do at Yahoo! Labs. Usually I cannot give them many details, because our work is confidential. But after a project is completed we frequently publish a paper describing it. This is a great opportunity for others, inside and outside the company, to learn more about our efforts.

The first project I participated at Yahoo! Labs Haifa was called FAME – a Framework for Agile Media Experiences. We recently published a paper about it:

Title: “Hierarchical Composable Optimization of Web Pages”

Abstract: “The process of creating modern Web media experiences is challenged by the need to adapt the content and presentation choices to dynamic real-time fluctuations of user interest across multiple audiences. We introduce FAME – a Framework for Agile Media Experiences – which addresses this scalability problem. FAME allows media creators to define abstract page models that are subsequently transformed into real experiences through algorithmic experimentation. FAME’s page models are hierarchically composed of simple building blocks, mirroring the structure of most Web pages. They are resolved into concrete page instances by pluggable algorithms which optimize the pages for specific business goals. Our framework allows retrieving dynamic content from multiple sources, defining the experimentation’s degrees of freedom, and
constraining the algorithmic choices. It offers an effective separation of concerns in the media creation process, enabling multiple stakeholders with profoundly different skills to apply their crafts and perform their duties independently, composing and reusing each other’s work in modular ways.”

You can freely download the full PDF version of the paper.

Here is a presentation about this project:

Hierarchical Composable Optimization of Web Pages

There are many other very interesting projects going on at Yahoo! Labs worldwide. To learn more about them, you can check these two sites:

Yahoo! Labs

Yahoo! Research

You can also search the publications repository, looking for papers about a specific subject. A few papers are more theoretic in nature, but most of them are very practical.

For example, a recent publication that became very popular makes an analysis of user behavior at Twitter, and surprisingly concludes that “roughly 50% of tweets consumed are generated by just 20K elite users”. Of course this conclusion has some important implications for companies that want to advertise on Twitter.

So good luck learning more about our research activities at Yahoo! Labs. I’m sure you will find some inspiring ideas. Enjoy!

Posted in Research, Yahoo! | Tagged , | Leave a comment

The Effective Workplace

Posted on September 27, 2011 by Hayim Makabee

In a recent article at the Harvard Business Review, entitled “The Twelve Attributes of a Truly Great Place to Work”, Tony Schwartz provides a list of characteristics of an effective workplace that makes the employees more “engaged”, and thus more productive. These are the attributes, in summary:

  1. Commit to paying every employee a living wage.
  2. Give all employees a stake in the company’s success.
  3. Design working environments that are safe, comfortable and appealing to work in.
  4. Provide healthy, high quality food, at the lowest possible prices.
  5. Create places for employees to rest and renew during the course of the working day.
  6. Offer a well equipped gym and other facilities that encourage employees to move physically and stay fit.
  7. Define clear and specific expectations for what success looks like in any given job.
  8. Institute two-way performance reviews.
  9. Hold leaders and managers accountable for treating all employees with respect and care.
  10. Create policies that encourage employees to set aside time to focus without interruption on their most important priorities.
  11. Provide employees with ongoing opportunities and incentives to learn, develop and grow.
  12. Stand for something beyond simply increasing profits.

I personally agree with the importance of all items in this list, and I think that a wise manager should try to provide them in order to increase the productivity of his employees.

Now the question is: If you are an employee, how do you convince your manager to improve your workplace?

If you observe the list above, it is obvious that most items have some cost, and some of them have a significant cost. For some items it may be easy to compute the Return On Investment (ROI), but for others it may be very difficult. Therefore, as an employee, to convince your manager to really invest in improving the workplace may be a hard task.

Hence, I suggest a different approach: Convince your manager to allow you to invest more time on self-improvement. Convince him to invest on you!

For software developers, self-improvement may include:

  • Participating in professional courses.
  • Going to group meetings and conferences.
  • Being a listener in advanced courses in the CS Faculty.
  • Self-study from technical books and articles.
  • Learning a new programming language or technology.
  • Using and contributing to Open-Source projects and libraries.
  • Visiting frequently Q&A sites such as StackOverflow.
  • Reading professional blogs.
  • Writing your own professional blog.
  • Giving talks about your field of expertise.
  • Developing prototypes for new products or features.
  • Dedicating a fixed amount of time to your own innovation initiatives.

Of course you must also convince your manager that your investment in self-improvement will not reduce your productivity. Perhaps you will even need to work some additional hours to perform these self-improvement activities, but the benefit will come in the form of clear personal growth and development. Good luck!

Posted in Efficacy | Tagged | 1 Comment

Programming Without an Internet Connection

Posted on August 29, 2011 by Hayim Makabee

Are you able to program without an internet connection?

In my case the answer is definitely “No.” In most of my programming tasks I need to get some help from the internet, generally in the form of documentation and examples. I’m currently programming in Java, and frequently using new libraries, frameworks and APIs. Even in the Java standard libraries there are so many classes that it is very hard to know how to use them correctly. This situation reminds me a quote:

“Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it.” – Samuel Johnson

A few months ago I was working on a Web-based demo, which included the use of HTML, CSS and JavaScript. I’m not an expert on these technologies, but still I wanted to be sure I was implementing things correctly. So, for each problem I had, I asked myself: “Is it possible that none had this problem before?” Then I looked for solutions and with enough patience and a bit of luck I was always able to find an example similar enough to what I needed to do. I never came back of a search with empty hands.

When I program in Java I’m always concerned about not reinventing the wheel. If I need some specific function not yet provided by the classes I know, first of all I search if there is some well-known public library that can be useful. Then I download it and write some short program to test it. Sometimes I find several such libraries that appear to be potentially adequate for my needs. In this case I will spend enough time comparing them, and perhaps even testing all of them.

Therefore, the internet is much more than a source of information in the form of documentation and examples. It is the ultimate reusable code repository, from which millions of developers worldwide are frequently downloading the latest libraries. This level of global reuse certainly saves us a huge amount of development effort, making our work as programmers much more productive and even more pleasurable.

If possible, I would like to hear about your personal experience. Please leave a comment answering these questions:

  1. How frequently do you access the internet when you code?
  2. For what purposes do you access the internet when you code?
  3. Do you feel you are less productive when there is no internet connection?

Thanks!

Posted in Efficacy, Software Reuse | Tagged , | 7 Comments

How Decision Fatigue Affects the Efficacy of Programmers

Posted on August 23, 2011 by Hayim Makabee

In the past, programming was an activity based on assembling low-level instructions using a small numbers of structures: there were loops, conditional statements and function calls. Systems were built through the application of relatively few patterns at different scales. Even the design was very simple: Dataflow Diagrams (DFDs) consisted of only processes, data flows and data stores; Entity-Relationship Diagrams (ERDs) had only entities and relationships.

Today, programmers work on a much higher level of abstraction, applying the mechanisms of Object-Oriented Programming, adopting Design Patterns, reusing sophisticated class libraries and extending powerful frameworks. Besides writing new code, developers are also expected to perform parallel tasks such as Refactoring and writing Unit Tests. The design phase requires a great diversity of complex diagrams, like the ones defined in UML.

The consequence is that today developers are making very important decisions at each step of their work. They must choose between composition and inheritance. They must decide if a class in a library is appropriate for their needs. They must analyze the trade-offs involved in the adoption of different Design Patterns. They must plan how to Refactor their code and how to assure good coverage through Unit Tests. Many of these decisions are not really programming issues in the traditional sense; they are in fact design decisions.

Then, if programming today can be defined as a series of high-level decisions, the question is: How can we assure that the developers are making these decisions effectively?

Decision Fatigue

A recent article at the New York Times addresses the issue of Decision Fatigue. The article mentions several researches that prove that people who are required to make many decisions become mentally exhausted, until they reach the point in which they are no longer able to make effective decisions. In its words:

“No matter how rational and high-minded you try to be, you can’t make decision after decision without paying a biological price. It’s different from ordinary physical fatigue — you’re not consciously aware of being tired — but you’re low on mental energy. The more choices you make throughout the day, the harder each one becomes for your brain, and eventually it looks for shortcuts, usually in either of two very different ways. One shortcut is to become reckless: to act impulsively instead of expending the energy to first think through the consequences. The other shortcut is the ultimate energy saver: do nothing. Instead of agonizing over decisions, avoid any choice.”

One concrete example is Copy-and-Paste programming. It is very common for a programmer to need a piece of code that is very similar to something he has already written in the past. The best way to reuse this code would be to Refactor it so that it can be shared, but this involves many decisions about how to do it correctly without breaking existing code. Thus, if the programmer is tired, he will probably just copy-and-paste it, because it is the most impulsive action and requires minimal mental effort.

The problem of Decision Fatigue is particularly important when the person needs to make trade-offs. As we know, most design decisions require evaluating different options and analyzing their advantages and disadvantages. In the words of the article:

“Part of the resistance against making decisions comes from our fear of giving up options. Once you’re mentally depleted, you become reluctant to make trade-offs, which involve a particularly advanced and taxing form of decision making. To compromise is a complex human ability and therefore one of the first to decline when willpower is depleted. If you’re shopping, you’re liable to look at only one dimension, like price: just give me the cheapest. Or you indulge yourself by looking at quality: I want the very best.”

I believe that every developer has experienced this single-dimension reasoning, making decisions that appeared to be good at the moment, but then proved to have some very serious negative consequences. For example when a programmer implements a new data structure and forgets about the need to keep it synchronized in a multi-threaded environment. Sometimes these bad decisions are just discovered when the system starts exhibiting some very strange bugs and unexpected behavior.

So, to assure that developers are making decisions effectively, we must either avoid Decision Fatigue or provide ways to recover from it. The article recommends consuming sugar, for example in the form of soft drinks. I would recommend making a short break whenever you feel tired, and spend a few minutes in some activity that does not require much mental effort. And have a Coke.

The most important conclusion is that, if a developer is making important decisions, he should not be required to work long hours. It is absolutely impossible for a human being to continue making effective decisions after many hours of work, no matter how smart or experienced he is.

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