Thursday, January 1, 2015

Open Office Spaces and Cabal Rooms Suck

Caught this new article in the Washington Post:
Google got it wrong. The open-office trend is destroying the workplace.

In case it wasn't clear: I really dislike large open office spaces. (Not 2-3 person offices, but large industrial scale 20-100 person open office spaces of doom.) Valve's was absolutely the worst expression of the concept I've ever experienced. I can understand doing the open office thing for a while at a startup, where every dollar counts, but at an established company I just won't tolerate this craziness anymore. (See the scientific research below if you think I feel too strongly about this trend.)

As an engineer I can force myself to function in them, but only with large headphones on and a couple huge monitors to block visual noise. I do my best to mentally block out the constant audio/visual (and sometimes olfactory!) interruptions, but it's tough. It's not rocket science people: engineers cannot function at peak efficiency in Romper Room-like environments. 


In case you've never seen or worked in one of these horrible office spaces before, here's a public shot showing a small fraction of the Dota 2 cabal room:


I heard the desks got packed in so tightly that occasionally a person would lower or raise their desks and it would get caught against other nearby desks. One long-time Valve dev would try to make himself a little cubicle of sorts by parking himself into a corner with a bunch of huge monitors on his desk functioning as walls, kind of like this extreme example:


He also had little mirrors on the top of a couple monitors, so he could see what people were doing behind him. At first I thought he was a little eccentric, but I now understand.

After a while I realized "Cabal rooms" (Valve's parlance for a project-specific open office space) resembled panopticon prisons:


See that little cell in the back left there? That's your desk. Now concentrate and code!

Here's the list of issues I encountered while working in cabal (open office layout) rooms:

1. North Korea-like atmosphere of self-censorship:


Now at a place like my previous company, pretty much everyone is constantly trying to climb the stack rank ladders to get a good bonus, and everyone is trying to protect their perceived turf. Some particularly nasty devs will do everything they can to lead you down blind alleys, or just give you bad information or bogus feedback, to prevent you from doing something that could make you look good (or make something they claimed previously be perceived by the group as wrong or boneheaded).

Anyhow, in an environment like this, even simple conversations with other coworkers can be difficult, because all conversations are broadcasted into the room and you've got to be careful not to step on the toes of 10-20 other people at all times. Good luck with that.

2. Constant background noise: visual, auditory, olfactory, etc.
As an engineer, I do my best (highest value) work while in the "flow". Background noise raises the mental cost of getting into and staying in this state.

3. Bad physical cabal room placement: Don't put a cabal room next to the barber or day care rooms people (!).

4. Constant random/unstructured interruptions. 

It's can be almost impossible to concentrate on (for example) massive restructurings of the Source1 graphics engine, or debugging the vogl GL debugger with UE4 while the devs next to you are talking about their gym lessons while the other dude is bragging about the new Porsche he just bought with the stock he sold back to the company.

5. Hyper-proximity to sick co-workers.
Walls make good neighbors, especially after they've caught a cold but feel pressured to be seen working so they come in anyway.

6. Noise spike in the afternoon in one cabal room, as everyone all the sudden decides to start chatting (usually about inane crap honestly) for 30-60 minutes. There's a feedback effect at work here, as everyone needs to chat louder to be heard, causing the background noise to go up, causing everyone to speak louder etc. Good luck if you're trying to concentrate on something.

7. Environmental issues: Temperature either too high or too low, lighting either too bright, too dark, or wrong color spectrum. Nobody is ever really happy with this arrangement except the locally optimizing bean counters.

8. Power issues or fire hazards due to extreme desk density.

9. Mixing electrical or mechanical engineers (who operate power tools, solder, destruct shit, etc.) next to developers trying their best to concentrate on code.

Related: Don't put smelly 3D printers etc. right next to where devs are trying to code.

10. Guest developers causing trouble:

Hyper-competitive graphics card vendors would watch the activity on our huge monitors and get pissed off when we emailed or chatted, even about inane crap, with other vendors.

Some guest developers treated coming to Valve like an excuse to party. We learned the hard way to always separate these devs into separate mini-cabal rooms.

11. No (or bad access to) white boards.
At Ensemble Studios (Microsoft), each 2-3 person office had a huge whiteboard on one wall. This was awesome for collaboration, planning, etc. 

More articles on the nuttiness of open office layouts:

Open-plan offices make employees less productive, less happy, and more likely to get sick

Study: Open Offices Are Making Us All Sick

The Open Office Trap


Example of a GOOD office space:


Here's a quick summary of the scientific research (from The Open Office Trap):

"The open office was originally conceived by a team from Hamburg, Germany, in the nineteen-fifties, to facilitate communication and idea flow. But a growing body of evidence suggests that the open office undermines the very things that it was designed to achieve. In June, 1997, a large oil and gas company in western Canada asked a group of psychologists at the University of Calgary to monitor workers as they transitioned from a traditional office arrangement to an open one. The psychologists assessed the employees’ satisfaction with their surroundings, as well as their stress level, job performance, and interpersonal relationships before the transition, four weeks after the transition, and, finally, six months afterward. The employees suffered according to every measure: the new space was disruptive, stressful, and cumbersome, and, instead of feeling closer, coworkers felt distant, dissatisfied, and resentful. Productivity fell."
"In 2011, the organizational psychologist Matthew Davis reviewed more than a hundred studies about office environments. He found that, though open offices often fostered a symbolic sense of organizational mission, making employees feel like part of a more laid-back, innovative enterprise, they were damaging to the workers’ attention spans, productivity, creative thinking, and satisfaction. Compared with standard offices, employees experienced more uncontrolled interactions, higher levels of stress, and lower levels of concentration and motivation. When David Craig surveyed some thirty-eight thousand workers, he found that interruptions by colleagues were detrimental to productivity, and that the more senior the employee, the worse she fared."
"Psychologically, the repercussions of open offices are relatively straightforward. Physical barriers have been closely linked to psychological privacy, and a sense of privacy boosts job performance. Open offices also remove an element of control, which can lead to feelings of helplessness. In a 2005 study that looked at organizations ranging from a Midwest auto supplier to a Southwest telecom firm, researchers found that the ability to control the environment had a significant effect on team cohesion and satisfaction. When workers couldn’t change the way that things looked, adjust the lighting and temperature, or choose how to conduct meetings, spirits plummeted."
Ultimately, I noticed the biggest proponents of open office spaces have no idea how programmers actually work, aren't up to date on the relevant science (if they are aware of it at all), and in many cases do their best to actually avoid working in the very open office spaces they enforce on everyone else.

Sunday, November 9, 2014

State of Linux Gaming

I've got one more blog post before I depart for Dallas. Here's an interesting report showing framerates and loading times of various big titles on Linux vs. Windows:

Slashdot: PCGamingWiki Looks Into Linux Gaming With 'Port Reports'
PC Gaming Wiki: Linux port report

Sadly, it's pretty clear that if you run these games on Linux your experience isn't going to be as good, and you'll be getting less "gaming value" vs. Windows. We're not talking about a bunch of little indy titles, these are big releases: Borderlands: The Pre-Sequel, Borderlands 2, Tropico 5, XCOM: Enemy Unknown, Sid Meier's Civilization V. My take is the devs doing these ports just aren't doing their best to optimize these releases for Linux and/or OpenGL.

A nice little tidbit from this report: "Unfortunately, Aspyr are currently still unable to provide support for non-Nvidia graphics cards, as with Borderlands 2. This doesn't mean the game won't work if you have an AMD or Intel GPU, but just that you're not guaranteed to receive help from the developer - the current driver situation for non-Nvidia cards may lead to degraded performance." Huh? This is not a good situation.

I know it's possible for Linux ports to equal or outperform their Windows counterparts, but it's hard. At Valve we had all the driver devs at our beck and call and it was still very difficult to get the Source engine's perf. and stability to where it needed to be relative to Windows. (And this was with a ~8 year old engine - it must be even harder with more modern engines.) These devs are probably glad to just release anything at all given how alien it can be for Windows/Xbox devs to develop, debug, and ship stuff under Linux+OpenGL.

Hey, this is just a thought, but maybe Valve developers could stop locally optimizing for their bonuses by endlessly tweaking and debugging various half-broken dysfunctional codebases and instead do more to educate developers on how to do this sort of work correctly.

The entire Intel driver situation remains in a ridiculous state. I know Intel means well and all but really, they can do better. (Are they afraid of pissing off MS? Or is this just big corp dysfunctionalism?) Valve is still paying LunarG to find and fix silly perf. bugs in Intel's slow open source driver:

Major Performance Improvement Discovered For Intel's GPU Linux Driver

Surely this can't be a sustainable way of developing a working driver?

Anyhow, onto SteamOS/Steambox. Here's a surprisingly insightful comment I found on Slashdot. I don't agree that SteamOS is done just yet, but you've got to wonder what is really going on. (So where are all those shiny Steam machines they showed earlier this year anyway? Does all this just go into the Valve memory hole now?)

by Qzukk (229616) on Friday October 24, 2014 @11:56AM (#48222551Journal
Let's be honest, SteamOS is done. Steam got exactly what they wanted from Microsoft and dropped it like a hot potato (so sorry, you'll never get to use that cool controller).
Consider that for decades Microsoft has not allowed anyone, anyone to touch the user experience. Even after Netscape's antitrust lawsuit over active desktop, even after BeOS withered and died hoping someone would sell a windows computer with dualboot, or hell just a windows computer with a "Setup BeOS" icon on the desktop. Steam is facing the Microsoft Store and a real threat that the Microsoft Store will become the way to buy programs (see also: iOS). Steam trots out SteamOS, and Microsoft snickers. The hype train builds up, and Microsoft sweats. Games start to port and Microsoft snaps.
Alienware ships a Windows 8 PC that boots to Steam instead of Metro.
Now, let's step back a second and look at the big picture here. At the time, windows 8 adoption is absolute total shit, swirling the drain of a public restroom that hasn't been washed for years. The last windows evangelists are all hanging on imploring people to just try it out, just give it a chance, and oh by the way install Start8 to fix metro. Think about that. PC vendors are on the verge of revolt, their customers refuse to buy their goods, and all for the want of installing a $5 program to fix the metro experience. Best Buy is probably screaming at Microsoft, begging them to allow them to remove the metro experience so they can move their inventory. Hell, they're probably begging them to let them advertise their Geek Squad services to "optimize" the experience and install that $5 program for $100. But no, the Microsoft Experience is inviolate, the holiest of holies, eternally immutable. No matter how much hatred it gets, it Must. Not. Be. Changed .
And then Alienware ships a Windows 8 PC that boots to Steam instead of Metro.
SteamOS's job is done. When no-one was looking, Steam took Microsoft and snapped it like a twig. We'll never know exactly what dark magicks were invoked here, but in the blink of an eye, Valve routed Microsoft in a war that nobody even realized was being fought. When Japan makes an anime out of this event, GabeN will point at Steve Ballmer, say omae wo shindeiru and Ballmer's head will implode, without GabeN throwing a single visible punch.
Steam OS will probably putter along, we'll probably see a few things be trotted out to keep the dream alive, after all the hype train did build up a lot of steam (pun not intended). Eventually a few of these AAA developers will say "it's really just not ready for the prime time" and we'll go back to getting a few wine ports and indie games from hardcore dedicated guys who just really love Linux.
But the masses will probably never get to hold that controller.

Friday, October 10, 2014

Interesting Talks and Articles

What Your Culture Really Says
Talks on the Science Behind Motivation, or why bonuses don't work
Dan Pink: The puzzle of motivation (transcript):
http://www.ted.com/talks/dan_pink_on_motivation?language=en

Kathy Sierra: "The Secrets of the Whisperers" (motivation and gamification)
https://www.youtube.com/watch?v=QNsl5D-V8T0&app=desktop

For Best Results, Forget the Bonus
http://www.alfiekohn.org/managing/fbrftb.htm

Why Bonus Systems Don't Work
http://brodzinski.com/2013/11/bonus-systems-dont-work.html

Joel on Software

Whaddaya Mean, You Can't Find Programmers?

Alex St. John: OpenGL vs Direct3D
http://www.alexstjohn.com/WP/2014/03/25/opengl-vs-direct3d-yawn/

Alex St. John: "Recruiting Giants"
http://www.alexstjohn.com/WP/download/Recruiting%20Giants.pdf

Paying Down Your Technical Debt
http://blog.codinghorror.com/paying-down-your-technical-debt/

Your Most Important Skill: Empathy
http://chadfowler.com/blog/2014/01/19/empathy/

The Unreasonable Effectiveness of C
http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html

Wednesday, October 8, 2014

Moving back to Texas!

My five year, mostly sunless odyssey in the Seattle area is finally coming to an end. I'll be visiting occasionally, but I can't wait to move back to Dallas next month. Thanks to everyone at Valve for making the place such an amazing company to work at. Also, a huge thanks to the truly world class developers at Rad Game Tools for their key help during the Steam Linux launch and helping us kick start vogl's development. Without the devs at Rad a lot of the stuff we did over the past few years just would not have happened. (Umm Gabe, why don't you just buy these guys already and officialize the Valve "satellite office" in Kirkland?)

To the Linux and GL community, I feel bad about quitting Valve before completing vogl. (Not that something like vogl could ever really be completed!) In the couple months before I quit I did everything I could think of (wrote the wiki, got UE 4 compatibility, built the regression suite, wrote up a 6+ month itemized task roadmap, etc.) to ensure vogl's development would continue moving forward without me. From studying the changes made on vogl's github repo after I quit it certainly looks like the devs at Valve and LunarG have done a good job moving it forward.

I think it'll be 3 years or more before OpenGL-Next is usable and relevant to shipping products. So even though vogl's has little chance of scaling beyond GL v4.x, it should remain a useful tool for a long time. I may fork it one day if I have to do any hardcore GL development again.


Tuesday, June 17, 2014

More apitest related links and notes

More apitest related links:

OpenGL Stop Breaking my Heart

apitest results on AMD comparing various OpenGL and D3D11 approaches

Some important things about apitest and the results worth pointing out:

1. apitest results should not be compared vendor vs. vendor.
The test was not originally designed to be used in this way. Accurate benchmarking is surprisingly hard, and it's possible apitest's results are flawed or misleading in some way when compared vendor vs. vendor.

2. In many cases AMD's GL driver is within the same ballpark, or faster, compared to their D3D11 driver.

3. The relative sorted order of techniques is approximately the same on both vendors. 
This is good, because apps tend to use the slowest techniques and the authors are encouraging developers to use the faster approaches.

4. We're taking possible performance gains of 15x-20x, on drivers from both vendors.
5x-10x would be fantastic, 15x+ is amazing. 

Now all that's needed are drivers from all vendors that not only support these techniques, but handle them reliably and with reasonably consistent performance.

Monday, June 16, 2014

State of GL 4.x revealed via "apitest" benchmark

This excellent GL 4.x micro-benchmark that has been making waves recently is really interesting. Now that it's on Phoronix it's about as mainstream as it's going to get: NVIDIA Slaughters AMD Catalyst On Linux In OpenGL 4.x Micro-Benchmarks

At first glance the results sound great for NV: "The AMD Catalyst driver gets absolutely annihilated for these GL4 micro-benchmarks". But unfortunately it's bad news for everyone working in GL because it clearly demonstrates just how fractured and inconsistent the GL driver landscape actually is when the rubber hits the road.

Monday, June 9, 2014

Article: "DirectX Creator Says Apple’s Metal Heralds the End of OpenGL"

Links:

Alex. St John: "Direct3D, OpenGL, Metal, Full Circle"
Time: "DirectX Creator Says Apple’s Metal Heralds the End of OpenGL"

According to St. John: "Nearly twenty years later OpenGL still sucks for games, OpenGL drivers are STILL consistently broken across devices, OpenGL is still driven by CAD applications".

BTW - I'm no longer at Valve or working on vogl. And no, I'm not being paid by, nor do I know anyone still at Apple, lol.