Apparently, rural towns have had a population problem of late -- as young people these days don't tend to want to work on the farm, and all the information-worker jobs are found in large cities, people tend to leave small towns for the city or the suburbs.  Many of them want to live in a small town (or to return to one when they have children), but there's not a lot of demand for, say, an Enterprise Architect in a town whose largest employer employs maybe a dozen people.

Telecommuting to jobs in large cities is an obvious benefit to the workers, who get to live where they want -- at substantially lower living cost, plus without the costs of commuting -- while getting a job that's not available in that area.  The benefit to the town is less obvious but no less real: "People who telecommute, live and work here, are the best of both worlds.  They're big earners and they spend the money in town," says Dave Wilson, quoted in the article above.  He recruits for Kansas City and Wichita companies in tiny Sterling, Kansas.  It's a way for companies to bring high-income residents (with the local economic input and tax revenue that that provides) to town without having to lure employers (a task that often requires giving them huge government handouts, in the form of discounted leases, long-term tax breaks, etc.)

Right now, a lot of these employes are probably virtual call center employees, which while not the highest-earning thing out there is at least a "real" job you can do from home (as opposed to the mountains of envelope-stuffing "work from home" scams.)  However, there are definitely some other things out there that are employing virtual workers.

There are, however, some roadblocks.  While towns may be eager to lure telecommuters to reap tax benefits, state governments are fond of reaping tax benefits, too, and the law doesn't always favor telecommuting.  The Telework Coalition is trying to get a law passed to change the situation, but as it stands now, people telecommuting across state lines may end up paying state income tax twice.  The issue is that some states (e.g. New York) require state income tax to be collected on all wage income paid out by employers in the state, even if the worker resides in the other state.  But some states require state income tax to be collected on all income earned in the state -- even if it was from an out-of-state employer!  While this isn't a problem if you live or work in a state with no state income tax (e.g. Washington), or for an employer in the same state, it does discourage companies from organized telework programs.

This said, I'd find an extra 1-2% state income tax a pretty small price to pay to give up commuting -- especially since commuting costs me more than that now.

Geeks have different priorities than most people when it comes to software engineering jobs, and attracting and retaining them at a company can require some different strategies.  And they're worth attracting and maintaining, for two reasons: first, most of the really good developers fall into that category, and while you don't need all your developers to be superstars, it sure helps if some of them are; and two, because they don't care all that much about the money.

What does matter to them?  Several things:

• Autonomy.  Micromanagement drives them crazy.  This is a case where you must follow management-by-results, not management-by-tasks.  Figuring out how to do things is precisely what geeks enjoy about work -- tell them what you want, not how you want them to achieve it.  They'll figure something out, and be willing to go above and beyond what's required, because it's theirs.  Whereas if you give them a checklist, they'll do it haphazardly, because they're not invested in it.
  
• Isolation.  Geeks, all told, are not very social.  They do their best work when left alone.  The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy.  Offices are ideal for most development work, the only exception being the early stages wherein there's a lot more collaboration and brainstorming than actual coding.  Actual coding needs extended, uninterrupted quiet time (well, sometimes it's not quiet at all if you count music, but the sounds are chosen.)  Geeks coding get into the "zone" -- a 5-minute interruption can and will cost you an hour of productivity.
• Technology.  Geeks want to be on the cutting edge.  You're not going to retain one for a project writing Yet Another Database Front-End unless you've got a truly amazing work environment (or seriously overpay them for work that frankly doesn't require superstar developers.)  More interesting projects often mean more than higher-paying projects.  In addition, it's worth investing in the technology they'll use every day.  Sure, they may not really "need" a $4,000 dev workstation with two LCD monitors... but they'll be more productive with one, be happier working on it, and it'll do more to retain them than you would from a comparably-sized raise.  Ever having to wait on substandard technology to keep up with them is irritating.
  

Most importantly of all, though, geeks despise "politics," where by politics I mean any situation in which interpersonal considerations outweigh technical considerations.  They have no patience at all for things like:

• Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because "the boss likes it," "we've always done it that way," or "we're a [insert product here] shop."  They need technical reasons for using a technology, not somebody's feelings.
• Anything perceived as unfair.  While I said they don't care much about money, there is one situation in which they do care -- if they feel they're paid less than market value, or that someone else who's not as good as they are is paid more.  Trying to keep salaries secret helps not at all -- they for the most part don't understand why they should be kept secret, and thus will totally disregard any order to do so.   Of course, the problem is that they're often unwilling or unable to see any non-technical factors in an employee's value, which sometimes do play a part in compensation.
  
• Fiefdoms and silos.  Geeks want to get things done.  And they don't care overmuch who does them -- when engineering solutions, they'll totally ignore interdepartmental boundaries.  This isn't a bad thing; however, managers often think it's a bad thing, since they want their team to get the credit for it.  What these managers fail to take into account is that trying to get the credit for it results in not just an inferior product but also unhappy developers.

Though I'm talking primarily about work here, these characteristics do extend outside of work, too, particularly the intolerance for personal considerations outweighing technical (or whatever they perceive as "rational" or "logical" considerations.)  Geeks don't see the point of playing a game if they can't play to win -- it's not that they care overmuch about winning, it's that the game has a framework of rules, and that framework should be complete.  I think this is one thing that makes geeks thought of as antisocial -- they don't take people's feelings into account when doing things, because those don't fit into the rational, logical, predictable framework they like.  I think that how "normal-seeming" a geek is depends largely on how willing they are to sublimate this impulse in order to relate to other people.

Finally, when it comes to performance management, geeks need to be told, directly and clearly, how they're doing and what needs improvement, if anything.  Not being people-oriented, they probably can't read you.  They don't know if you're happy with them or not unless you tell them.  And they're certainly not going to ask.  While they deal extremely well with technical ambiguity -- they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome -- they don't deal well at all with ambiguity in other contexts.  Clear expectations and consistent feedback turn the job itself into a problem to be solved, which makes it much more satisfying to them.

I can't help but think there's probably some correlation between what I've observed as the "software engineering geek" personality and some MBTI or enneagram types.  It's probably not an exact mapping, but it sure is something that comes up a lot -- I can pretty easily classify most of the developers I've worked with into "geek" and "non-geek" if I try. 

Here in the Seattle area, independent IT and development contractors are everywhere... and so are jobs for them.  If I post a resume on Monster, Dice, or any other job board, I am pretty much immediately inundated with offers for 3- to 12- month development contracts on small- to medium-sized projects.  I don't usually want them, due to the inflexibility (no vacation time, and they're just long enough that I don't usually want to commit to 6+ months without any time off), but they're there.  I must confess their presence doesn't do much for the idea of corporate loyalty -- their fixed length implies they're not interested in any commitment themselves, and their ubiquity means that anyone with the skills to get one isn't really trapped in their current job.  Rather than weeks or months of interviewing to get real employment, a developer can often snag a few months of contract work within a week or two just due to the sheer number of these positions.

Offshoring development work, as much as people complain about it, does get managers used to the idea of employees that they can't see and which don't even work the same hours as they do.  Of course, they have the comfort of knowing that wherever these employees are in the world, they do have some other manager breathing down their neck.  And they're also undoubtedly comforted by the mounds of process these firms tend to use.

I think its the combination of these trends that is starting to produce automated, telecommuting job boards for development and IT workers.  The two major ones right now are Rent-a-Coder and oDesk.

Rent-a-Coder's main flaw to the U.S. telecommuter is that it works too well.  The jobs people tend to post on Rent-a-Coder are straightforward, self-contained dev jobs for one person.  They're usually no more than a week's work.  Rent-a-Coder works as a reverse auction -- people put in proposals for how long the work will take, advertise themselves a bit, and state what hourly rate they're willing to work for.  Rent-a-Coder is a pretty reliable way for a skilled developer to find quick, straightforward, and usually easy work.

However, it's just as easy for developers in India or China.  Rent-a-Coder, being a virtual job market for people who will never meet their employers in person, is truly a global market.  If you're a teenager or college student, the $15-20 an hour that development work usually goes for might sound pretty good, but skilled professionals usually find themselves priced well out of the market.  Overseas developers with 10 years of enterprise Java experience put in bids of $13.50/hr... anyone in the U.S. or U.K. who can compete with their qualifications usually doesn't want to compete with their prices.

oDesk aims to be a different sort of market -- they target companies looking for "homeshoring."  It works more like a traditional job market, in that people post themselves with a rate requirement rather than just bidding on projects.  It's less one-way than Rent-a-Coder.  In addition, being targeted at more serious projects (there are a lot of long-term things on oDesk; it's not so biased at Rent-a-Coder's usually-tiny projects), the providers often command more reasonable (from a U.S. perspective) rates.  Their current home page quotes providers with rates up to $65/hr. for some skillsets... though it quotes some at $14/hr. as well, so obviously there's a lot of variability.

oDesk, however, goes far beyond Rent-a-Coder's simple matching.  Essentially, they aim to be a virtual temp agency, a Volt or ExcellData for the nation.  They provide all their contractors with standard software (SVN and BugZilla for tracking and version control, but also presence and videoconferencing software, timecard software, etc.) and have relatively standardized contracts.

On the bright side, oDesk recognizes that the biggest hurdle companies have to hiring telecommuters is one of trust -- managers, unable to track what people are doing since they're not in the office, need proof that they're actually doing work.  My preferred solution to this problem would be to track work -- that is, integrate with the version-control tools, bug tracking software, etc. to demonstrate tasks actually completed, and use status report deliverables to have employees state their progress and bring up issues so that if someone is falling behind managemnet is informed beforehand (or can fire an employee when he fails to meet a deadline not for failing to meet the deadline, but for failing to track toward it and lying about it in the status reports until that time.)

oDesk, however, does not take my enlightened, employee-friendly approach.  No, they have a different way -- spying!  oDesk's software screenshots the telecommuter's machine every 10 minutes to give remote managers a gallery of activity to browse.  They also generously provide their contractors with a videocamera, so managers can watch you wherever you are.  And the logs show not lines of code, or checkins, or bugs, but rather the number of keystrokes and mouse clicks per minute you've made.  The result is that you can get all the stress, lack of privacy, and constant monitoring of an "open-plan" cube farm right in the comfort of your own home!  Also, oDesk keeps 30% of whatever you're paid.

Obviously, I think oDesk is, to some extent, missing the point.  On the other hand, they're a business, and their customers are not just the employees but also the employers.  That trust gap is one of the most important things for them to bridge in order to get employers comfortable with telecommuting employees.  In the long run, I think it's a good thing for telecommuters -- having hired a few people through oDesk, a manager is likely to be more comfortable with employees he can't see, and less inclined to protest the idea when someone comes along wanting to be a truly independent remote employee (this time without keystrokes-per-minute clocking.)  This said, in the short run, well, I wouldn't work for them.

Most of my development experience came at Microsoft, which has its own software development life cycle (SDLC) and, for all its problems, still has a large number of very smart developers and a management corps consisting almost entirely of former coders.  As a result, I operated under the assumption that this SDLC was more or less typical for the industry, as it sort of vaguely lined up with the traditional waterfall SDLC.

And then I came to my current job.  Yes, I have found the IT shop that performs development on the unmodified waterfall model -- welcome to 1979.  The great majority of our software development work is outsourced to a contracting firm in India, and thus worked on overnight, largely out of contact with our management, and the amount of process involved is staggering.

On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.

The code in question?  Five lines of SQL.

Yes, a 2-hour project took over a month.  Actually, it's not quite done yet, due to the repeated test cycles.  You might think all that documentation would have rendered bugs impossible, but if so, you'd be wrong.

Why on earth is so much process present?  Why does it take three documents and six meetings to write five lines of SQL?  There are twice as many pages of documentation as lines of code!  Well, having worked with the people involved on these documents, plus the development, and the testing, not just on this project but several others, I think I've figured out the purpose: process is being used as a substitute for competence.

The thing that's surprised me, though, is that process actually turns out to be a pretty good substitute for competence.  With enough steps, documents, design reviews, and test plans, I think that the proverbial 1,000 monkeys with typewriters really could produce a functional IT system.  The incredible amount of mutual reinforcement breaks the task down into such minute pieces that each piece is comprehensible and completable by anyone with even the slightest modicum of coding or testing ability.  It turns what is inherently a massively complex endeavor -- software engineering -- into little more than rote following of directions.  Each step is so long and involved as it must be performed in so much detail that the next step follows necessarily, without putting much thought into it.  The waterfall model enforces this level of detailing by making it nigh-impossible to change decisions made early on.  It also helps project management -- after years of this sort of development, the project managers know to a pretty good degree of accuracy how long each minute task will take, and can thus do a pretty good job coming up with a (shockingly long) timeline for a project in any stage of development.

The problem with this model, though, is that anyone who is halfway competent finds himself spending more time on process than on actual, productive development activity.  Everything is drawn out over a huge period of time.  I think this is the main thing that's been driving alternative methodologies like Agile and SCRUM -- the desire by skilled developers to sweep away all that process that's "in their way," and get rid of documentation and meetings.

This has led to the principles of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

This is pretty much the complete opposite of the waterfall model, and developers often enjoy working in such a model quite a bit more.  (This said, it can be done badly, as discussed in Steve Yegge's blog here, though that post eventually turns into Google-worship.)  Good developers, on the whole, hate process, don't like writing documentation, have no concept of or interest in business concerns, and like to code by the seat of their pants anyway.  A methodology that says "what you want to do anyway, that's good!" will naturally get a lot of traction.  Nothing gets developers excited like telling them that they don't need to produce documentation, the code is the documentation.

However, I can see that as much as I hate the process-bound development process I work with here, an Agile methodology would be a total failure with these developers.  They are simply paralyzed by the slightest bit of uncertainty, entirely unwilling to just figure out for themselves what will work.  They entirely lack both the ability and the desire to experiment.  In short, while they're programmers, they're not geeks, and that idea still seems somewhat foreign to me -- when I think about developers, I still think about people who program for fun.  But these developers approach programming like it's on an assembly line, and they need to be told the right way to do everything before they're willing to touch it.

So if you're faced with a very involved, complicated process to do something, stop and consider why that process is there -- it's possible, likely even, that it's there to remove the responsibility of making decisions from some set of people.  Sometimes that's because someone higher up is (or was) a petty tyrant and doesn't care for decisions being made by anyone but himself -- in that case, the process may be ripe for a change.  But sometimes it's there because the people involved are unwilling or unable to act without it, and in that case you change it at your peril.  While a more agile process would be better for me, and is better for the development teams at Microsoft and Google, it's not necessarily better for everyone -- not everyone is a self-motivated geek.

Unfortunately for me, I don't think this is a process I can change here.  It turns out that outsourcing development to India is so much cheaper that even if it takes four times as long, it's still a net savings. 

• 31 gallons of gasoline per month = $79/mo., $953/yr.
• 672 miles driven per month; assuming a 100,000 mile vehicle lifespan, this depreciates my vehicle by $168/mo., $2,016/yr.
  
• Parking a few blocks from my building = $100/mo, $1,200/yr.
• Bumping my driving miles per year above 8,000 raises my insurance rates slightly.
• I waste a substantial period of time every day sitting in traffic.  Assuming I value my time by about what I'm compensated for it at work, this costs me $1,127/mo., $13,524/yr.

Good lord, that's a lot.  My commute costs me $4,169/yr. in actual costs, or $17,693 if you count lost time!  (On one hand, counting lost time is cheating a bit since I wouldn't really spend all that commuting time working, and I'm not paid by the hour anyway.  But since if I were offered the option to take a $13,524 pay cut to drop a day off my workweek, I'd take it in a heartbeat, I don't think it's an entirely unfair valuation of my time, either.)

And in many ways I'm getting off easy -- my car gets 22 mpg average (though honestly it may well be lower during Seattle's rush hour), it's a Honda that didn't cost all that much (keeping the depreciation cost down and meaning it really will last for at least 100,000 miles), and $4.75/day for downtown parking is cheap as hell.  With a Mercedes and a better parking spot, I could easily have $7,500 in actual monetary cost from the daily commute.

Think about that -- your company's requirement that you sit in a cubicle at work every day, even when it's not actually necessary for what you accomplish, is costing you $4,000 or more per year.  And that's cost, not wages, which means that not commuting would be the equivalent of a $5,700 raise in terms of how much money you would actually end up with in your pocket.

Of course, your company doesn't care overmuch, since you are paying that cost, and they are not.  However, I think if more people were aware of the true cost, they'd be more inclined to view telecommuting as the benefit it is, and making use of remote workers would be a more accepted cost-saving measure for corporations.  A $4,000 pay cut to work from home would actually increase my take-home pay, and that would be saving my employer money.

What he finds odd is that this is one area where, of all things, the government is ahead of private industry.  It turns out that Public Law 106-346 "requires each Executive agency to establish a policy under which eligible employees may participate in telecommuting to the maximum extent possible without diminished employee performance."  There's a very interesting report on the GSA Telework site that has a lot of data in it about how telework has worked out for the Federal government:

• 85% of executive agencies have telework policies.   65% of them even have telework coupled with alternative work schedules.
  
• 46% of agencies reported that over 25% of their employees participated in telework at least once during the year.
• 50% of teleworkers in executive agencies are "core" teleworkers -- that is, "Telework that occurs on a routine, regular, and recurring basis away from an employee's principal place of duty (e.g., at home, at a telework center, at an alternate location) one or more days per week."
• For agencies with a low percentage of teleworkers, the barriers cited were:
• Office coverage challenges, 54.6% (I'm not even sure what this means.)
• Nature of agency work, 51.1%
• Data security, 44.1%
• Management resistance, 38.3%
• IT issues, 31.4%
• Funding for equipment/IT support, 25.5%
• Employee resistance, 15.1%
• None, just not doing it, 10.4%
• Training, 6.9%

Take a look at those barriers.  Some are quite legitimate -- "nature of agency work" could easily make telecommuting impossible for large numbers of employees (it's hard to work from home if you're, say, the clerk at the DMV or otherwise in a customer-facing, in-person job), and "employee resistance" reflects the fact that some people just aren't able to be productive at home due to distractions.  For that matter, some people see going to the office as a form of socializing and would be lonely without it.

But the fact that Data Security and IT Issues are on there is kind of sad, as those issues are quite resolvable.  On the bright side, they're actually a good bit easier to solve than, say, management resistance.  We have technologies like VPNs and laptop encryption that can take care of the data security needs, though to implement them securely requires there be some company-provided equipment (it doesn't do much good if I make a perfectly secure connection to someone's spyware-ridden home machine that hasn't had a virus scan in four years.)

The conclusion of the report, though, is something the private sector really needs to hear: "The positive impact telework can have on an employee's reduced commuting time, effort, and costs; increased productivity; and increased control over the delicate act of balancing work and personal responsibilities is tremendous. Benefits to the organization, including the increased ability to recruit and retain valuable employees, gain higher productivity, and experience boosted morale, are clearly documented. Reduced commuting serves to benefit the environment by fewer pollutants being dispersed into the air, and less wear and tear to roads and vehicles."

Despite the numbers given in the report, Dvorak concludes that the primary barrier to telework is simple irrational management resistance -- as he puts it, "the current management model is hovering around 1921."  I've certainly run into this, when my current manager was hired into this IT group, his first actions were to establish more fixed working hours, get a schedule drawn up for people, and spout manager aphorisms like "Everyone is valued in the office."  I wonder, however, if this is the case everywhere or if Dvorak and I are just drawing conclusions from our own anecdotal bad experiences.  Somehow, I doubt that federal government agencies are hotbeds of enlightened, forward-looking management -- if anything, I'd expect the bureaucratic culture to encourage even more order-for-order's-sake.

While telecommuting, groupware, presence technology, and alternative working arrangements will remain my primary focus, after as many years as I've spent in the IT and software development world, I can confidently say there are a lot more things making IT and development workers unhappy than just having to sit in a stifling, sterile cubicle farm.  I have a lot of commentary to make on these things, but have refrained from doing so since they seemed at least somewhat off-topic.  However, even if not necessarily directly related to the blog's original mission statement, they're certainly related to its title and overall focus.  Specifically, I'm thinking of software engineering practices and features of the corporate workplace that make employees unhappy but don't actually do much for productivity.

Thus, in reactivating this forum, I'll also be broadening its focus somewhat.  I hope you'll find it interesting. 

The general consensus is that in a pandemic situation, there would likely be a state of emergency declared and "nonessential" workers would be asked by the government to stay home (where "asked," as is customary for government, means "forced.") So what does a company do to continue operating when all of its workers have been declared "nonessential" and can't come to work?  Why, they just have everyone telecommute, of course!

Or so they believe.  There's nothing like a disaster recovery exercise to show how technically unprepared companies are for a large number of remote workers.  The technology is available, but companies don't have the infrastructure to handle everyone using it at once, and for the most part, they've never considered this.

Here's an example: a company has 3,200 people set up to work remotely.  A VPN infrastructure is in place, and these people routinely connect via a secure tunnel, using a secure authentication method, and work from home or other locations.  Sounds like they're well-prepared for a pandemic situation at corporate headquarters.

But... how many of those people can connect at one time?  Supporting 3,200 total users is very different from supporting 3,200 concurrent users -- a userbase that size may require a VPN concentrator that supports only 100-500 people at a time.  In addition to the concentrator, though, there are a lot of other parts of a remote-access infrastructure that need to be considered.  Is the network backbone able to handle the full number of remote users connected at once using relatively high-bandwidth technologies like Remote Desktop?  Are terminal servers used for remote access, and if so, can they handle that many simultaneous users?  How many sessions are licensed for these terminal servers?  Often, companies have only paid Microsoft for so many terminal server users, even if they have the technological capability to handle more.  Can the help desk support all the calls that would come in from people who haven't used remote access in two years and are suddenly expected to do all their work that way?  Can help desk support them when the help desk employees are also stuck at home for the same pandemic situation?

Part of being prepared for a situation like this for a company involves not just verifying the infrastructure, but also verifying that everyone who in theory can remote in has actually tried it.  When the help desk is closed and people can't come in to work is not the time to discover that half the support staff has no idea how to use the VPN client, and another 15% of them have expired passwords or smart cards or tokens.

Any large increase in telecommuting could require upgrades and preparation work of this type, but a pandemic could force companies to do so in a rather sudden manner -- and pandemic preparation may cause companies to do such work in advance (indeed, as a secuirity architect involvement in such preparation is part of my job.)

While I certainly hope that a disease pandemic doesn't actually come to pass, I can't help but be curious as to what the effect it would have on the work environment would be.  I can see two likely outcomes (both of which would likely happen to varying degrees):

• Some employees, after telecommuting for a week or two, would discover that they are every bit as capable of performing their jobs from home as at work.  This could greatly increase the demand for alternative working arrangements, as some people discover that they like such an arrangement.  Of course, it wouldn't be for everyone -- many people would be eager to get back to the office, foreign as that concept is to me.
• Managers faced with the sudden absence of many of their employees might find out that far from needing all of them at the office, they don't need all of them at all.  I wouldn't be surprised to see several employees being quietly let go in the months after a disaster scenario as the company discovered that they can do without them.  (This, by the way, is one reason why some people advise against taking any vacation longer than a week.)

Of course, the problem they always run into is that people love to live in suburbs, and Americans by and large still want a house with a yard.  This Newsweek article shows that people are starting to accept this.  City planners have been fighting a losing battle -- instead of trying to get people to live in dense areas they don't want to, perhaps they should instead embrace the medium-density cities people want (i.e. suburbs) and make that environment better.  The article comments thatEuropeans  -- whose cities are held out by these "smart-growth" anti-sprawl city planners as the ideal -- who come to America are delighted by suburbs, and often aspire to own their own home, which is impossible back home.  (By way of comparison, more than half the apartments in Paris are under 46 square meters -- about 550 square feet for we Americans -- and sell for over 6,000 Euro per square meter.  Here, college students have more space than that.)  Of course, in a sense, much of Europe is low-density suburb, they just explain it away by not considering it part of the small, dense cities at all.

The article considers accepting suburbs to mean bringing the arts and businesses to those suburbs, thus making more of what people want available without coming into the city.  However, there's one thing missing from this calculus -- most of the jobs are still in the city, and suburban living involves increasingly long commutes.

This other article -- from the same issue of Newsweek, no less --  is a great example of the fact that accepting suburbs has only come so far.  The "fastest-growing group of commuters" (whatever that means) is now those who commute more than 90 minutes each way.  Americans order a quarter of their restaurant meals from their cars, and eat 32 meals a year while driving.  McDonald's is selling food that fits in your cupholder now, and car manufacturers are giving you more of them (three for the driver alone in some vehicles.)  The Dodge Caliber includes a refrigerator in the glove box and a passenger seat that folds down into a dining table.

On one hand, this may seem like accepting people's preferred living arrangements by making the commute less painful.  But it's not really --  truly accepting where people want to live would mean not making everyone drive into the city.  It's strange that at the same time as people are talking about "work/life balance" and rebeling against 60+ hour workweeks, they're adding 15 hours to their workweek by spending it in their cars.  Consider how much unproductive time is wasted.

Telecommuting is one way to eliminate this, but it's not the only way.  Another would be reducing the emphasis on downtown prestige offices.  Why does a company need to put all its employees in a monolithic office in a skyscraper?  How often to they need to communicate to each other in person, rather than by email and phone?  The answer of course varies by company and type of employee.  However, at my current employer, all the IT people are in four floors of one building, with a very small support staff (two HR folks, a couple receptionists, and some purchasing reps), while other corporate functions are in entirely different buildings.  There's no reason that any of those buildings need to be located downtown.  There's the occasional meeting from those of us in one building with those of us in another... but they're only occasional.

Many companies are like that, having semi-isolated "silos" that are located together either because "they always have been" or just to give the company a desirable downtown address.  My question is, what's so desirable about a downtown address?

Living in the suburbs of Seattle, I've seen what a livable suburb can be.  When I didn't work downtown, I could go for months without making the 25-minute drive into the city -- there are enough businesses and employers in the suburbs as to make it unnecessary.  Despite this, the Seattle area truly lives up to its name as the "Emerald City" when you get out of the city proper -- there are so many trees and green spaces as to make a beautiful living environment.  Of course, just as the cities try to "fight sprawl" and make themselves more dense and urban, the suburbs have their own form of inanity -- regulations to limit the height of buildings and to drive out businesses so as to retain their "rural character."  Still, a balanced, medium-density community can work, and seems to be what most people want to live in.  Anything that reduces how many people have to spend 90 minutes on a highway every morning is a step in the right direction.

Surprisingly, the Office application getting the greatest overhaul this version seems to be Word, which is a large change from Office 2003 (in which Word was practically unchanged from the previous version, while Outlook got the deluxe treatment.)  The UI is substantially changed, and in my opinion for the better.  Styles are more accessible (though not accessible enough); it's too bad that styles, one of Word's most powerful features, are so drastically underused since they're not presented in a very understandable way and thus people end up with "style pollution" in any documents that get shared among multiple people.

Outlook has gotten some improvements, though.  They've enabled side-by-side viewing and editing of multiple calendars (as well as the options of either viewing them entirely separately, or merging an arbitrary number of them onto one color-coded view,) which should be useful for anyone who needs to track more than one schedule (either other people's schedules, or their own for different jobs or projects.)  The task list and inbox are finally integrated (flagging a message for followup adds a task to complete,) making it a more functional organizational tool.  A "to-do" bar integrates appointments, tasks, and emails into one "Franklin planner" type view.  I wonder how much of this is a reaction to the new Google calendar -- looking at all of this, I can't help but think "now what would be really useful is putting all of this stuff on a web-site so that non-location-dependent workers could get at a full planner interface without carrying one around."  Google's new calendar, of course, is precisely that; I haven't looked at it enough to know how it is on organization and integration, but its actual calendaring/scheduling features look very nice.  Also, Outlook12 supports RSS feeds in the same way as mailboxes, newsgroups, or public folders -- it's not very compelling as an overall RSS aggregation strategy for Microsoft, but it does move Outlook closer to being "one-stop shopping" for daily information flows.

They've also put InfoPath into Outlook -- in other words, you can make a form with defined fields, email it to a bunch of people, and get back the tabulated responses to your survey instead of a bunch of emails.   And Project is integrated, too; a project manager can create a project, delegate tasks to various people in the enterprise, and have those tasks show up on their Outlook Tasks list.  There will be some sort of two-way feedback mechanism in this, though I haven't been able to try this out (most of Microsoft's groupware features require an Exchange or SharePoint server to work; great for the enterprise, not great for a blogger trying to check out beta software.)  Imagine being able to give project status updates within your tasks list instead of having to have constant "status update" meetings for every project -- that's the promise of this.  Time spent and tasks completed can be input directly, so the project manager can tell you're doing something without having to have you sit down at a table with him.  (Of course, the project manager should be able to tell by looking at the results of work, but we've all had project managers who don't have development knowledge.  Besides, project managers have managers, too -- and sometimes they won't take "I know my team, I can tell they're progressing according to schedule" for an answer.  They want numerical results, tasks completed, hours per day.  If nothing else, Outlook to Project integration will help feed the numbers machine.)

The big groupware project addition for Office12 is Office SharePoint Server.  SharePoint has been integrated into Office as a full member of the productivity suite.  It allows for resource libraries -- you could create a PowerPoint slide template, for instance, and put it into the library, where other people can make presentations based on it.  If you update the template, it automatically updates presentations based on it.  Workflow management can be defined and documents automatically routed through it.  They finally have real version control (as opposed to current versions of SharePoint, which have the utterly ludicrous feature of optional version control, in which each uploader can choose whether to add a new version or just clobber all old ones) and centrally managed policy.  

For the enterprise, at least (the market segment the Office division really cares about, whatever MS may say), it looks like they've actually produced a version of Office worth upgrading to.  It has its downsides (the radically new UI is less efficient for power users, and will require a total retraining of employees, retooling of training courses, rewriting of Office books, etc.), but the new features actually can improve productivity and project tracking in a way that a thousand Gantt charts full of wild-ass guesses can't touch.

It'll be interesting to see, in the coming months or years, how much of this functionality Google absorbs into their Calendar and Mail applications.  Most of Office's really good collaboration features depend on an enterprise environment (i.e. site-based & behind a firewall) that can host an Exchange or SharePoint server.  Google has the advantage that it is the server, so it can offer these features as part of its base offerings, rather than charging an extra few thousand dollars for serverware.  Of course, its disadvantage (lack of control; corportations don't like having their private information -- which usually means all their information -- on servers they don't own) may prevent real enterprise adoption, but I could see it being used by small companies.

Or maybe that's their real plan... package their collaboration software as an application service provider.  Pay to get mycompany.google.com as a server controlled by your company, and offering all the Google mail and calendar products.  The "Google Office" concept has been mostly dismissed, as Google is in no position to offer direct competitors to products like Word and Excel.  But what if those aren't the office products they intend to compete with?  It fits in well with the whole "Web 2.0" concept to have Google try to be the office suite for the distributed office. 

Honestly, there wasn't much of anything in the book I found surprising.  Her primary insight is that people respond to incentives, and thus management is less selected than evolved.  Managers are people who are good at being promoted to management -- in other words, what should be rewarded and what actually is are sometimes different, and the system is self-reinforcing.  Management tends to promote people who they see as being like them -- they know their recipe for success and look for others in the same mold.

As a result, appearance matters more than reality in the workplace.  This plays out in a wide variety of ways:

• Dress and personal appearance still matter.  Most IT folk work in "casual" workplaces where there is no official dress code.  However, we younger workers forget that when the previous generation came up with the idea of "casual dress" at work, they meant khakis and polo shirts, not unthinkable clothing like jeans and T-shirts with pithy sayings on them.   It doesn't matter that the policy says there's no dress code, there is.  I work in a "casual" workplace, make only modest concessions to businesswear (i.e. wearing polo or button-down shirts rather than T-shirts, and forgoing jeans), and have been complimented by older managers on my "professional appearance" at least three times in the last year.  Managers only promote people who look "manager-y" to them, and they have very distinct attitudes on what this is.  Of course, it can be taken too far (someone in a suit and tie at Microsoft would just look flat out weird), but Shapiro's advice is to dress like people at the level you want to be at, not the level you are at.
• Projecting optimism and a positive outlook are vital.  Employees are evaluated based on this more than any other single factor -- they project an aura of sucess.  Cynicism and pessimism -- which are very popular in the IT workplace -- project an aura of failure.  If you expect things to fail, they will; no one ever achieved victory by conceding defeat.  Managers also know that cynicism is contagious -- cynical employees "infect" others with the same attitude.  Appearances are so important that Shapiro suggests visibly disassociating yourself from the more cynical elements in an office, to avoid guilt by association or a perception that you've been "infected."
  
• No matter what your job description is, your job is to make your boss's life easier and to make him or her look good.  If you don't do those things, you'll never be promoted, because your boss acts as a gatekeeper -- without his endorsement, other managers will be unwilling to promote you.  Your manager's opinion of you becomes your reputation among other managers who don't work directly with you.  Thus, an adversarial relationship with your manager, even when he really deserves it, does not benefit you. 
  
• What the company says it values and what it really values may be different.  They may have a "work-life balance" campaign with posters around the office, but look around -- do all the managers work long hours?  If so, the company doesn't really value this at all, because it promoted the people who don't show that value.  If the managers go home at 5:00 and use all their vacation time, then the company really does value that.  Likewise, they may say they value a cooperative style, but if the managers are all really competitive, then they don't.  And no company values openness and honesty to the point of liking or even tolerating complaints or negativity, no matter how much they champion it.  If you don't "toe the party line" and demonstrate the company's actual values, they'll never promote you.
  
• Many workplaces are divided into "camps" -- management and employees have a largely opposed relationship.  If this is the case, and you want to get promoted, management has to see you as "one of us," and not "one of them."  However, cultivating this perception may make office friendships impossible.
  

Overall, the book tells you that you need to manage your perception in the workplace, and that political skills like making your boss look good, appearing professional, being positive, being a "cheerleader" for the company and demonstrating love and loyalty for it (regardless of if you actually have any) are much more important than how well you do your job.  Of course, you have to do your job at a base level of competency -- all the perception-management in the world won't do you any good if you really, really suck at your job -- but excellence in your actual responsibilities will probably not yield as great a reward as excellence in politics.

After reading the book... well, I didn't really find it cynical, just true.  Microsoft has actually hired Shapiro as a consultant, and I can see why, as her book describes their management culture very well.  Whether they hired her to find out how to change this culture remains to be seen.

Alternative working arrangements, where you're not in daily contact with your manager and coworkers, go a long way toward alleviating these concerns.  The only office that really has no dress code is the one in your house.   You also have a great deal more control over your perception -- you don't directly fraternize with coworkers, and most communication is written (email), so it's easier to "fake" positivity if you need to do so.  (Personally, I'm preposterously optimistic, so this is not a problem for me.  I'd look on the bright side of a train wreck.)  And finally, since less of you is seen save for the actual output of your work efforts, you're less able to be judged by things other than the actual output of your work efforts.

In a way, Shapiro describes exactly what I hate about the office environment -- the subordination of productivity to largely irrelevant matters.  On the other hand, much of what she says applies regardless of work environment -- you can still look unprofessional in an email (hint: "u" and "ur" are not words), and your attitude and outlook shine through in things beyond just in-person communication.  Remembering that your job is to make your boss's life easier and improve his standing and appearance is useful no matter what your actual office environment is.

On the surface, this doesn't seem like a bad thing.  After all, what's wrong with making people aware of the work you're doing?  If you work hard and accomplish a lot, shouldn't your managers know about it and reward you for it?  Besides, how can you be rewarded for things they don't know?

However, visibility can actually turn out to be quite a big problem in a software development organization, impacting both productivity and morale to a great degree.  And there are two fundamental reasons:

1.)  You may have heard the phrase "It is amazing what you can accomplish if you don't care who gets the credit."  This is by and large true.  So is its inverse.
2.)  The usefulness of a task and its visibility are not necessarily related.  In fact, it is often true that fake work is more visible than real work.

These are both a serious problem because people respond to incentives.  The attempt by various employees to achieve objectives in a maximally visible fashion means that they care very much who gets the credit.  From a purely self-interested perspective, it is important for you to get the credit for a task being completed well, no matter who does the most important work.  The initial result of this is that it encourages dishonesty and backstabbing -- people will emphasize their own role in a project while downplaying others.  After all, decreasing others' visibility increases your own.  But the worse impact this has is that it is better, in a purely self-interested sense, for a project to not be completed than for it to be completed without your visible effort.  After all, you can only work on so many things at a time.  If you don't have time to work on project B because you're busy with project A, you can do whatever you need to to delay project B until it can command your attention.  In addition, it strongly encourages fiefdom-building: ensure that you are responsible for everything whether you should be or not.  Managers try to get every project under the sun placed in their organization, not because of any logical synergy but so they can take the credit for the project when it's finally completed.  Often this results in overburdened organizations, unrealistic schedules, and delayed projects that could have been already completed by another team.

Fiefdoms are poisonous to any large organization.  When managers actively encourage their organizations not to cooperate with others, and to hoard tasks and responsibilities on their team, cross-group collaboration becomes largely impossible.  The product suffers as a result -- valuable integration opportunities are lost, and investigating bugs that cross team boundaries becomes very difficult.  A fiefdom environment cultivates the idea that another team's priorities are not your priorities at all; incentive to help others within the organization drops to zero.  Often this happens without the managers realizing what they've created -- they wonder why the members of their team are so slow to help out other teams without being directly ordered to, not realizing that it's their own priorities that have this result.

Thus, an environment in which everyone cares about visibiltiy creates an incentive to build fiefdoms and interact in a competitive fashion.  In addition, it creates an incentive to prioritize tasks based on their visibility, not their priority to the organization.

The most visible work is not always the most useful.  Indeed, a person's most useful work in a development environment is generally their day-to-day tasks -- writing code on features they own, finding or fixing bugs, maintaining the build system or IT environment, etc.  Maintaining the status quo is often a person's primary responsibility.  Of course, maintaining the status quo is entirely invisible; visibility requires being an agent for change.  Change, good or bad, is noticed.  Now, it's definitely preferable to be visible for good changes rather than bad ones, but there's some truth to the idea that all press is good press (unless it's really bad.)

Prioritizing based on visibility leads to make-work.  People invent their own projects and tasks that impact multiple groups and then pursue them because they know that impact will be noticed.  If this leads to neglecting their day-to-day tasks, so be it; no one notices those anyway.  The most vital work then coasts by with minimum attention (just enough to avoid appearing less productive than other employees), while the real work goes into "special projects."

This may seem mostly theoretical -- atfer all, most people are basically good.  They do not intentionally look for ways to abuse the system, to exploit their employer to get as much as possible out of them for as little effort, no matter what dishonesty or abusive behavior that requires.   Good employees do not want to engage in this sort of behavior -- we went into development and high-tech fields because we genuinely like the technology, and we want to see it work properly and succeed.  Surely we're not all out there neglecting the product and the organization in order to show off, are we?

Well, some people are.  People respond to incentives.  The degree varies -- the good people are harder to corrupt than the bad ones.  But if you reward bad behavior, and punish good behavior, you must expect to get some degree of bad behavior.  What's more, in the evaluation and performance review cycle is the worst place to do this, because it results in the worst people rising to the top.  Organizational hierarchies operate under Darwinian principles -- those with the best survival characteristics (visibility) will survive and advance.  The problem is that these people are the ones least likely to break the cycle -- they're the ones who profit from a culture emphasizing visibility over substance, why would they want to alter it?  I think most people who have been in an office environment for a few years have seen someone who moves up not by skill or ability in their field but by skill in politics.

Those of us who aren't manipulated by such incentives, on the other hand, face another problem -- morale suffers.  We're stuck with a choice of "do what you know is best, and be punished for it, or do what you recognize as worthless make-work, and reap the rewards."  Either choice leads to dissatisfaction -- either the feeling of injustice from not being rewarded for the contribution you know you've made, or the feeling of futility from spending time and effort on minutiae.  And where does this dissatisfaction emerge?  In the best employees, the ones an organization as a whole most wants to retain.  I feel like I'm wasting my time, but the politicians are satisfied.

So how does an organization fight the culture of visibility?  A few ways come to mind:

1.)  For God's sake, don't outright encourage it.  I don't think organizations that do this realize the ultimate conclusions that their policies lead to, or the incentives they're creating.  On the other hand, are the organizations consciously encouraging it... or are managers, recognizing the implications of the culture, just trying to warn their employees of the sort of system-gaming required to get ahead?

2.)   Use objective measures when possible.  In the development world this often isn't possible, since metrics like tests run or lines of code written are often meaningless absent some context.  However, some objective measures can be used -- such as on-time deliveries, deadlines met, budgets met or exceeded.  Any measure is better than "did the other managers like you."

3.)  Managers need to actually understand what their employees do.  This cuts down on fake work.  If your manager does not really know what you do, it becomes quite irrelevant how well you do it so long as you can spin it well.  While managers specialized in managing makes sense in most industries, it does not make sense in IT and development -- managers need to have actually done the sort of work their employees do.  This is a strong plus to promoting from within -- something that organizations seem increasingly reluctant to do, preferring to hire someone from without with "management experience" than take a chance on a bright internal.  It is extremely easy to pull the wool over the eyes of a development manager who doesn't do any development.

4.)  Keep people who don't understand what the employee does out of the performance review process.  Having other managers give their input may sound like a good idea -- after all, what better way to reward cross-group collaboration? -- but those people are even easier to fool.

This is all irrelevant.  The problem is one of simple supply and demand.  The supply of oil has not increased much, because OPEC controls most of the cheap (relatively speaking) oil, and oil prices are still too low to warrant the use of the world's largest oil reserve, Canada's tar sands.  (Canada contains more oil than the Middle East, but it's not profitable to extract it unless you know oil prices are going to reach levels like today's, and -- here's the kicker -- stay there.)  Demand, on the other hand, has skyrocketed outside the United States.  Fifteen years ago, China's streets were choked with bicycles -- now they're choked with cars, and China is really big.

People don't realize how much China is growing.  Take a look at this.   How much construction does it take for a country to need that much cement?  Think about that -- ten times the construction as is going on in the United States.  A lot of that cement goes to laying roads for cars, too.

There's no "price gouging" -- prices are high because supply and demand makes this current high price the profit-maximizing point.  And if we tax "windfall profits" when things go well for the oil companies, are we going to give them "downturn subsidies" and hand them billions of dollars when things go badly for them?  Why punish them when profits are "too high" but not pay them when profits are "too low"?  It's the profit from the upswings that enables companies to endure the downswings.  Business isn't always a smooth line going up and to the right.

Supply will go up on its own eventually, but it won't help prices -- because it's the high prices, per se, that cause the supply to go up.  Higher energy prices are here to stay.  Environmentalists should be cheering -- this is the one thing that can actually get people to conserve energy.  Of course, most of them aren't cheering, because they have to put gas in their cars, too.

There are two ways to lower how much gasoline you need.  (Note that doing so does not necessarily reduce demand for oil -- after all, oil is needed for other things, like making plastic, and different uses require different compounds from the oil.  In other words, we might need just as much oil to make the plastic we use even if we just threw away all the compounds that make gasoline.  But I'm not talking about "energy dependence" and money flowing to the Middle East -- I'm talking about the expense we as individuals incur to pay for gas.)  One is to use alternative fuels, and the other is to require less energy.

Alternative fuels sound like a great idea, but they're just not ready.  And by "not ready," I mean "still more expensive than gasoline."  As the price of gasoline increases, of course, "alternative" fuels will become mainstream.  But until then...

Ethanol: it comes from corn, so it's "renewable."  But... it burns cooler, so you get only about half as many miles per gallon.  This means that you need to refill the tank twice as often.  And while $2.41/gal ethanol is cheaper than $3.00/gal gasoline, it's not when you need twice as much of it.  Also, it's corrosive, so you need a new car that's designed so that the ethanol doesn't eat the fuel lines.

Methanol: it comes from natural gas, which is also a limited resource.  And it takes a lot of it -- the fuel economy is even worse than ethanol's.  $2.89/gal looks decent until you notice you're getting 14 MPG in a subcompact.  And it's just as corrosive as ethanol.  Also, though it burns quite cleanly, the process of producing it releases carbon dioxide, so environmentalists only like methanol if we can somehow conjure it ex nihilo instead of actually producing it.

Compressed Natural Gas (CNG): this is actually a reasonably viable fuel.  You get decent fuel economy, and it only costs about $1.20 for an amount with equivalent energy to gasoline.  The problems here are relatively simple: you need a car designed for it (that has a huge fuel tank that can contain 50 gallons of 3,600 PSI vapor) and an infrastructure where you can refuel.  Currently these are lacking (though Honda does make a mass-produced CNG Civic, and there are a few CNG refueling station.)  The problem is that natural gas is just as limited as oil (in principle; we have more of it right now) and is also in demand for other purposes.  If everyone used CNG as fuel, it might well stop being so cheap.  Also, the government would probably slap a big tax on it like they do on gasoline and double the price.

Biodiesel: burning vegetable oil in a diesel engine.  You can get cars that do this today (mainly from Volkswagen), and they get 45 MPG.  The fuel's not cheap ($3.40/gal), but if gas prices go up much more, it'll start being cheap by comparison.  Also, the fuel is primarily a waste product from other processes, so there's not much demand for it.  Problems?  Well, at freezing temperatures it has the consistency of wax -- and thus is only suitable for warm climates unless you want to leave your car plugged into an electric heating system all the time when it's not running. Still, like CNG, this at least is a viable fuel, even if it's not for everyone.

Electric: this looks great on paper.  Electric cars have good acceleration, and can go 200 miles on the amount of energy in a gallon of gasoline.  Coal-fired electricity is so cheap you could drive from New York to Los Angeles on $60 of it.  What's the catch?  Umm... you have to stop and recharge for at least an hour every 80 miles.  Ouch.  Batteries are extremely heavy, so putting in bigger batteries doesn't help much (what you gain in available power you lose in weight, so the range still doesn't go over 100 miles total -- or 50 miles round-trip.)

Hydrogen: It has promise.  Hydrogen fuel cells are like superior batteries; they produce no emissions.  And hydrogen can be produced from seawater.  It takes about $11 worth of coal-fired electricity to make enough hydrogen to have the energy of a gallon of gasoline, but you can go 41 miles on that.  This really is a case of technological immaturity -- the theoretical capacity is much greater.  Of course, you still have to figure out how to store tens of thousands of cubic feet of hydrogen in your car.  Someday this may actually be useful (unlike ethanol and methanol, which will never be), but that day is a long way off.

So alternative fuels are, for now, out.  What's the other option?  Reduce demand for gasoline by driving less.  The environmentalists tell us, "Fight urban sprawl!  Live in the city where you can walk to work!  Ride a bike!  Carpool!  Use public transportation!"  And we, consistently, respond with, "No, I don't want to."

When it comes to getting to work, driving individually seems to be the national preference.  Despite the expense, people still prefer it over these alternatives.  We don't want to live in the city, we want to live in the suburbs.  If we're going to be in a car for an hour, we want to be there by ourselves, not with some yahoo from work.  And if we wanted to walk or ride a bike, America wouldn't have the health problems it does.

The problem here is that we're thinking in overly limited parameters.  The way to reduce the energy cost of the commute is not to provide new, less-pleasant ways to commute -- it's to reduce the need for commuting.  Corporate America's attachment to the centralized, monolithic office, where people can be watched, produces this need.  Support for alternative working arrangements could be championed as a way to reduce the need for energy.  If everyone (obviously an unreasonable goal) telecommuted only one day a week, we'd reduce gasoline requirements by 15%.  While we won't reach that in the near term (so far progress seems slow, and more importantly, a substantial number -- probably a substantial majority, actually -- of jobs are unsuitable for remote work), even a few percentage points could make a big difference in U.S. demand for gasoline.

It's one thing to try to get people to change their habits to something less appealing (e.g. riding a train or a bicycle) in order to serve some greater good.  It's quite another to encourage people to do what they wanted to do anyway.  People are much more receptive in such a case.

How much good would this do, from an environmental, world-peace, global warming perspective?  Oh, not much, probably.  But who cares?  If I can enlist the awesome lobbying and cheerleading power of the environmentalist, world-peace, hippie folks to achieve my objectives, it sounds good to me.  They're much better than I at getting corporations and politicians to kneel to their will.

The primary message a cubicle sends is "you are being watched."  Walls that block no sound and wide openings instead of doors mean that you can't have phone conversations (and are forced to listen to everyone else's), and that you must be constantly aware that anyone walking down the hallway can see precisely what you're doing.  The book Workplaces of the Future called them "bright satanic offices."  We've created a panopticon workplace, and seem surprised that people feel like they're in a prison.

It's an open secret that almost no one in IT actually spends every moment of their workday working.  People (especially people with ubiquitous Internet access, which in IT is almost everybody) take impromptu breaks, check news sites, read blogs, look up sports scores, etc.  The openness of the cubicle environment seems to aim to eliminate all that, by making it obvious when people are not productive.

But this underestimates people's desire to get away from work for a moment.  People still do the same things they'd do in a private, enclosed office -- only now they do it with an eye over their shoulder (or stick a convex mirror on their monitor.)  Instant messenger clients include a "boss key" to quickly hide conversations.  How much stress is introduced into the workplace this way?  After all, now instead of just being unproductive, people get to be unproductive and worried as well.

The unfortunate fact is that the apperance of productivity is generally valued a lot more than actual productivity.  Actual productivity is sometimes difficult to measure -- but whether or not someone's surfing the web when the boss walks by is obvious and memorable.  The office workers know this, so they try to maintain the appearance of productivity all the time, regardless of if they're actually productive or not.

The problem here is that the managers designing offices are trying to figure out a way to make people work harder and more consistently.  After this much time in the IT industry, I've come to a different conclusion -- everyone has an individual level of productivity, and only they can change it.  What's more, everyone has an individual working style, and "an 8-hour block with a 30-minute lunch break" is not the preferred style for all (or even most) workers.  Anything done to attempt to force people into greater productivity instead forces them into greater attempts to disguise how their working style differs from the "norm."  And the time and effort used in this disguising doesn't come out of slack -- it comes out of work.  This isn't to say that people's productivity can't be improved -- it most certainly can.  But this has to be done by providing incentives to be more productive, and those incentives only work on people who want to be more productive.

Instead of spending 6 hours working and 2 surfing the web, if you make that employee feel he has to maintain the illusion of productivity all the time, he'll spend 5 hours working, 2 surfing the web, and 1 hiding the fact that he spent 2 surfing the web.  But he's rewarded for the illusion of productivity he creates, in a way he'd likely never be rewarded for actual productivity.

The biggest problem, from a my perspective, is that unproductive time spent at work is wasted.  It's not that people want to spend 2 hours surfing the web -- it's that they want to spend 2 hours doing something other than work, and the requirement of appearing productive means that they can't use that time on something useful.  They'd rather read a novel, or play a video game, or go shopping, or sit down with their families... but none of those activities have a "boss key."  In requiring people to work for a fixed number of hours under observation, we don't get more productivity -- we get the same amount of productivity for the company while destroying the worker's ability to produce for himself.

Indeed, some of my most productive time at one of my jobs was when I was sharing an office with a friend.  Using breaks to talk to someone I actually enjoyed talking to (as opposed to most coworkers -- while I've always liked my coworkers and gotten along well with them, in general I feel no desire to socialize with them about non-work matters) rather than pointlessly surf the web seemed to make the time "count for more" and make me better able to go back to productive work quickly.  And for me, the truly ideal person to talk to during such breaks would be my wife -- hence some of telecommuting's appeal.

People who work outside of the office environment (whether that's from a home office, from Starbucks, or wherever) are freed from having to maintain the illusion.  They can work, and not work, as their own preferences dictate.  Sure, there are some people who would never get anything done working from home -- but they usually know this.  They know that there are too many distractions for them at home and they wouldn't be productive, so if they were choosing a workspace "on their own" they would probably choose to go to some other environment to get work done (one of my friends uses the local library.)  They can work whatever hours they choose, subject only to the relatively lax requirement of being reachable via phone or email during some approximation of business hours.  And if those hours happen to be "30 minutes of each hour for 10 hours"... so be it.

"But, then they're not working an 8-hour day!" is of course the objection.  Here's the thing, though -- I bet that worker isn't working an 8-hour day in his cubicle, either.  Managers need to measure, not the amount of work time, but the amount of output a worker produces.  What does it matter if Mary only works 5 hours if she accomplishes as much as Bob does in 8?  Why should Jim get a raise for working 12-hour days if he only accomplishes what Fred does in 6?

Unfortunately, measuring output is hard.  You can't measure a programmer based on lines of code he writes -- some lines of code are harder to write than others.  You can't measure a tester based on bugs found -- when I was working on stress and performance at a software company, I would sometimes take a week or more to find, isolate, and identify a fix for a single bug (usually some hairy multithreaded race condition), during which time someone testing, say, UI components might identify dozens of bugs.   We'd both be doing a good job, just at different tasks that require different metrics.

This said, I am not delighted to waste an hour or two of my day because a manager can't tell if I do good work or not.  If a manager doesn't know who is and is not productive on his team he is failing to manage, just as a college professor who has to grade based on attendance is failing to teach.  If you can pass the class without showing up, then either the teacher isn't very good or the bureaurcracy put you in a class you never should have been in.  Likewise, if you can not do your job, routinely, without your manager noticing then either your manager isn't very good or your job is unnecessary.

It seems at least some people are noticing (from Fortune magazine):
If working at home is now part of the zeitgeist, one very large employer that seems increasingly tapped in is the U.S. government. Congressman Frank Wolf, a Republican whose Virginia district is home to many federal worker bees, has made telecommuting his pet project. "There is nothing magic in strapping ourselves into a metal box every day only to drive to an office where we sit behind a desk working on a computer," he told a congressional committee.

Wolf sees telecommuting as a way to decrease traffic, reduce air pollution, increase productivity, and frustrate terrorists. In 2004 he launched a campaign to penalize government agencies by docking funds if they fail to support telecommuting. Now the SEC, the State Department, the Department of Justice, and four other big agencies are required to offer every eligible worker the opportunity to telecommute.  [...]

Coming to the office for meetings and in-person collaboration is still important, of course, but as Brand points out, "People are realizing they don't need face-to-face time all the time."

It's a start.  Who'd have thought change would begin in the government?