I found this slideshow interesting. It focuses on happiness and business. The four aspects of happiness are quoted as:

Autonomy: The feeling that your activities are self chosen and self endorsed.

Competence: The feeling that you are effective in your chosen activities.

Relatedness: The feeling of closeness to others.

Self-esteem: An individuals natural propensity to happiness.

Happiness studies have been panned for not being empirical in nature and more feely than science. However, happiness is a major component of an individual's well being so it would be silly to ignore it as a driving factor in the work place. Most business structures are hierarchical and the culture of the 'customer is always right' and extending customer relationships inside a company often means that those in a hierarchy are treated too deferentially.

Software Engineering has particular issues in this area as often management is not technical and the issues with a codebase that make it impervious to change are not understood, or even not known by management. The other issue is that even when it is, then disruption to the business flow and allocation of capital is so high that the investment in time and effort is avoided.

In these situations the first three are heavily impacted. Working on a system you know sucks, is impossible to work with, and within impossible constraints destroys the autonomy part, makes it very difficult to display competence - usually QA produces bug after bug that is a symptom of the system and not the work of the engineers - and in those situations rifts develop between management and the developers.

The labor market for tech is highly mobile, the developers usually coalesce as a social group and invariably move on to other opportunities. It is a brutal world and will remain so while software engineers are in demand.

The barriers to happiness are tabulated as:

Fear: Anxiety of failure, mistrust, or ignorance.

Confusion: Noise, paradox of choice, or lack of good information.

Loneliness: Isolation or disconnection from others.

Lack of control: Feeling loss of control over ones life and surroundings, secrecy, loss of agency.

Struggle for survival: Basic needs not met.

Again in modern companies, the hierarchical nature of the system leads to fear, confusion and developers feeling they have a lack of control over the environment they work in. It doesn't have to be that way, but it usually is, often merely because there are several layers of management between the software teams and technology decision makers it is how it plays out.

Again, the labor market is excessively mobile for software engineers and any indication of unhappiness from a developer and they usually have their resume out on the many websites that exist to support labor mobility; dice, monster, careerbuilder, etc.

So how do you empower software engineers and make the happy? I think cheap tricks like ping pong tables and wii are more gimmick than worth. I suspect the best mechanism is to lay down wider strategies that you expect the software teams to work within and then give them enough - but not too much - time to deliver quality software products within that strategy.

Too often the coding part of the project is the crappy part. This can be because timelines are squeezed and business and QA have divided the largest chunk of the time between them and left the software engineers with a tiny period to come up with something that can stumble through QA and into production.

Software engineering is fun and the coding part of the project should be the time when the software developers are the most joyous. Too often we structure projects such that the fun part has all the glee, enjoyment and happiness sucked from it.