Separation of Concerns

Posted on February 5, 2012 by Hayim Makabee

The most important principle in Software Engineering is the Separation of Concerns (SoC): The idea that a software system must be decomposed into parts that overlap in functionality as little as possible. It is so central that it appears in many different forms in the evolution of all methodologies, programming languages and best practices.

Dijkstra mentions it in 1974: “separation of concerns … even if not perfectly possible is yet the only available technique for effective ordering of one’s thoughts”. Information Hiding, defined by Parnas in 1972, focuses on reducing the dependency between modules through the definition of clear interfaces. A further improvement was Abstract Data Types (ADT), by Liskov in 1974, which integrated data and functions in a single definition.

In the case of Object Oriented Programming (OOP), encapsulation and inheritance proved to be essential mechanisms to support new levels of modularity. Design-by-Contract, proposed by Meyer in 1986, provides guidelines of how to improve interfaces using pre-conditions and post-conditions. Finally, the separation of cross-cutting concerns is the most important motivation for the proponents of Aspect Oriented Programming (AOP).

Since the first software systems were implemented, it was understood that it was important for them to be modular. It is necessary to follow a methodology when decomposing a system into modules and this is generally done by focusing on the software quality metrics of coupling and cohesion, originally defined by Constantine:

Coupling: The degree of dependency between two modules. We always want low coupling.

Cohesion: The measure of how strongly-related is the set of functions performed by a module. We always want high cohesion.

All methodologies try to reduce coupling and increase cohesion. Information Hiding reduces coupling by isolating the details of the implementation of state. ADTs reduce coupling by defining clear and abstract interfaces. An ADT that specifies in a single definition the set of functions that can be executed on a type is certainly more cohesive than a global data structure that is modified by external functions.

OOP adds another step in the reduction of coupling with the enforcement of encapsulation and the introduction of dynamic binding and polymorphism. Inheritance allows us to increase cohesion by defining hierarchies based on generalization and specialization, in which we can separate the functionality that belongs to the superclass from its subclasses. AOP provides a solution for the problem of cross-cutting concerns, so that both the aspects and the affected methods may become more cohesive.

There are many benefits that software developers expect to obtain when making a system more modular, reducing coupling and increasing cohesion:

Maintainability: A measure of how easy it is to maintain the system. As a consequence of low coupling, there is a reduced probability that a change in one module will be propagated to other modules. As a consequence of high cohesion, there is an increased probability that a change in the system requirements will affect only a small number of modules.

Extensibility: A measure of how easily the system can be extended with new functionality. As a consequence of low coupling, it should be easier to introduce new modules, for example a new implementation for an existing interface. As a consequence of high cohesion, it should be easier to implement new modules without being concerned with aspects that are not directly related to their functionality.

Reusability: A measure of how easy it is to reuse a module in a different system. As a consequence of low coupling, it should be easier to reuse a module that was implemented in the past for a previous system, because that module should be less dependent on the rest of the system. Accordingly, it should be easier to reuse the modules of the current system in new future systems. As a consequence of high cohesion, the functionality provided by a module should be well-defined and complete, making it more useful as a reusable component.

As software developers, after we recognize the importance of SoC, we need to apply this principle in at least two ways: Understanding the power of our programming language tools and patterns, and learning how to evaluate and compare different designs in terms of coupling and cohesion.

Tools: For each mechanism in the programming languages we use, we should understand how it can be applied to reduce coupling and increase cohesion. For example: How encapsulation, dynamic binding, polymorphism and generic types can be used to separate concerns? Similarly, for each Design Pattern, we can analyze how it helps to make a system more modular.

Designs: When evaluating and comparing our own design alternatives, it is always useful to think in terms of coupling and cohesion. Sometimes a design seems to be more complex than others, but this may be a consequence of a better separation of concerns, with fewer dependencies between modules through the definition of additional layers. Another design may at first appear to have too many classes, but this may be an advantage if each class becomes more cohesive.

Producing effective software designs requires lots of experience, but principles such as the Separation of Concerns are essential to perform a great work. So reduce coupling, increase cohesion and good luck!

Posted in AOP, Design Patterns, OOD, OOP, Software Reuse | Tagged , , , , | 52 Comments

Events for Software Developers in Israel

Posted on January 25, 2012 by Hayim Makabee

Something very nice is happening in the Software Development Community in Israel: People are organizing meetings to share their knowledge, but not only with their colleagues in the workplace – these are meetings open to the public, including engineers from “competing” companies. I personally think that this strong sense of community and this desire to share knowledge and experience is a wonderful characteristic of the Israeli hi-tech industry, well described in the book “Start-up Nation“.

I am myself one of the co-founders of the International Association of Software Architects in Israel (IASA IL). We are organizing an event next week, focused on TRIZ – the Theory of Inventive Problem Solving. The meeting will include an introductory talk about TRIZ, followed by a panel to discuss its applications in the industry. Our speakers are Ido Lapidot and Shadi Saba, from Intel Haifa, and Vladimir Petrov, president of the Israeli TRIZ association. You can register in the event. You can also join our LinkedIn group.

Another very active group is the Software Craftsmanship in Israel (SCISR), leaded by Uri Lavi. They are having their 10th meeting this week, with the special participation of Corey Haines. The meetings organized by SCISR are extremely popular, and if you don’t register fast you will surely find yourself in the waiting list.

The ILTechTalks initiative, organized by Ori Lahav, has as its goal to “facilitate knowledge and experience exchange between Israeli tech professionals”. They have a rich list of very interesting talks, with highly qualified speakers that volunteer to present these subjects in your own company.

The Agile community in Israel also became very active in the last couple of years. They have several groups on LinkedIn, in which you can always find interesting blog posts. They are organizing a great two-day event next week, the Agile Practitioners 2012 Conference, with the participation of Gojko Adzic, David Evans and Corey Haines. There will also be talks by several of the leading members of the Agile movement in Israel.

Besides the opportunity to exchange knowledge and experience, these meetings are the best places to socialize and increase your network. In a recent article at the Fast Company, Kevin Purdy talks about the importance of the Third Place:

“The First Place is your home, and the Second Place is your office. You have assigned roles and tasks at each place, and you know nearly all the people in each. The Third Place is where you meet with people you don’t know that well, or maybe at all, and you exchange ideas, learn about other people, and enrich society and yourself.”

 So don’t miss these events! Hope to see you there!

Posted in Agile, IASA Israel, Israel | Tagged , , | 1 Comment

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