We've known this for 50 years: open-plan offices do nothing good for companies except reduce rent costs, but they do a whole lot of bad. They are not "fun;" they are not "collaborative;" they are not "start-uppy." They just suck:
Over the decades, a lot of really stupid management fads have come and gone, including:
- Six Sigma, where employees wear different colored belts (like in karate) to show they've been trained in the methodology.
- Stack Ranking, where employees are encouraged to rat each other out in order to secure their own advancement and budget.
- Consensus Management, where all decisions must pass through multiple committees before being implemented.
It need hardly be said that these fads were and are (at best) a waste of time and (at worst) a set of expensive distractions. But open plan offices are worse. Much worse. Why? Because they decrease rather than increase employee collaboration.
Previous studies of open plan offices have shown that they make people less productive, but most of those studies gave lip service to the notion that open plan offices would increase collaboration, thereby offsetting the damage.
The Harvard study, by contrast, undercuts the entire premise that justifies the fad. And that leaves companies with only one justification for moving to an open plan office: less floor space, and therefore a lower rent.
As an introvert in a field that requires concentration, minimal distractions, and time to reflect and think about what I'm doing—not to mention, a field predominantly comprising introverts—it's even worse.
I wish I had at least a cubicle.
I started reading Jessica Powell's online novel The Big Disruption last week. It's hilarious. And it has a lot to say about the archetypes of software development.
The premise is that the monarch of a fictional country has been exiled to California, where he found work first as a janitor at Stanford and then at a hot startup. He applies to a Google-like company and gets hired—but by accident, as a product manager.
Arsyen washed his hands and returned to the cubicle, armed with his new vocabulary.
When Roni asked Arsyen about prioritization, Arsyen asked, “Is this on the roadmap?”
When Sven suggested adding images of attractive women to the car dashboard, Arsyen rubbed his chin.
“Does this align with our strategy?”
When all three looked to him for an opinion in how best to implement Symmetry Enhancement, Arsyen stood and put his hands on his hips.
“Does this align with the strategy on our roadmap?”
No one seemed to notice anything was amiss. If anything, it seemed like product managers just asked questions that other people had to answer.
“Good brainstorm, everyone. Let’s break for lunch,” Roni said. “Oh, and Arsyen, this is still very confidential, so let’s get this whiteboard cleaned off.”
Arsyen jumped up and began to wipe the whiteboard clean as Sven and Jonas scooted their chairs back to their desks. Arsyen was pleased that product managers seemed to have some janitorial tasks in their role. Maybe this wouldn’t be such a stretch after all.
I can't read it at work because I would have to explain why I'm laughing so hard.
Via Raymond Chen, Eric Shlaepfer built a 6502 emulator out of full-size components:
The MOnSter 6502
A dis-integrated circuit project to make a complete, working transistor-scale replica of the classic MOS 6502 microprocessor.
How big is it?
It's a four layer circuit board, 12 × 15 inches, 0.1 inches thick, with surface mount components on both sides.
Can you hook it up inside an Apple ][ and run Oregon Trail?
No, not directly. It's neat to think of plugging the MOnSter 6502's in-circuit emulator (ICE) in-circuit replica (ICR) cable directly into a socket inside an Apple ][, but that wouldn't actually work. The Apple ][ design relies on a number of clever tricks that derive timing for video generation and peripheral control from the main clock signal — all of which will fail if you need to run at a slower speed.
Are you going to make one out of vacuum tubes next?
Make sure you watch the 2-minute video.
Before diving back into one of the most abominable wrecks of a software application I've seen in years, I've lined up some stuff to read when I need to take a break:
OK. Firing up Visual Studio, reaching for the Valium...
While trying to debug an ancient application that has been the undoing of just about everyone on my team, I've put these articles aside for later:
Back to the mouldering pile of fetid dingo kidneys that is this application...
Uncle Bob riffs on Martin Fowler's speech at Agile Australia this week. He is saddened:
It was programmers who started the Agile movement as a way to say: “Hey look! Teams matter. Code should be clean. We want to collaborate with the customer. And we want to deliver early and often.”
The Agile movement was started by programmers, and software professionals, who held the ideals of Craftsmanship dear. But then the project managers rushed in and said: “Wow! Agile is a cool new variation on how to manage projects.”
There’s an old song, by Alan Sherman, called J. C. Cohen. It’s about a subway conductor who did such a great job at pushing people into the train cars, that he pushed the engineer out. This is what happened to the Agile movement. They pushed so many project managers in, they pushed the programmers out.
The programmers continued to pursue Agile as it was originally conceived. Read the opening line of the Agile Manifesto: “We are uncovering better ways of developing software by doing it and helping others do it.” It is Software Crafts-men and -women who are continuing that work. It’s not the project managers in the Agile movement. They’re off pursuing something else?
He has hit on the sadness all us old craftsmen feel when we encounter Management.
I'm re-reading DeMarco & Lister's Peopleware, first published in 1987, to sort out a nagging problem in my own office. Sometimes it's good to review the classics. It turns out, even though technology has changed the world since then, people haven't changed all that much.
I might have to review Christopher Alexander next.
The Nielsen-Norman Group has released recent research on user interactions with intelligent assistants like Alexa and Google Home. The results are not great:
Usability testing finds that both voice-only and screen-based intelligent assistants work well only for very limited, simple queries that have fairly simple, short answers. Users have difficulty with anything else.
Our user research found that current intelligent assistants fail on all 6 questions (5 technologies plus integration), resulting in an overall usability level that’s close to useless for even slightly complex interactions. For simple interactions, the devices do meet the bare minimum usability requirements. Even though it goes against the basic premise of human-centered design, users have to train themselves to understand when an intelligent assistant will be useful and when it’s better to avoid using it.
Our ideology has always been that computers should adapt to humans, not the other way around. The promise of AI is exactly one of high adaptability, but we didn’t see that that when observing actual use. In contrast, observing users struggle with the AI interfaces felt like a return to the dark ages of the 1970s: the need to memorize cryptic commands, oppressive modes, confusing content, inflexible interactions — basically an unpleasant user experience.
Are we being unreasonable? Isn’t it true that AI-based user interfaces have made huge progress in recent years? Yes, current AI products are better than many of the AI research systems of past decades. But the requirements for everyday use by average people are dramatically higher than the requirements for a graduate student demo. The demos we saw at academic conferences 20 years ago were impressive and held great promise for AI-based interactions. The current products are better, and yet don’t fulfill the promise.
We're not up to HAL or Her yet, in other words, but we're making progress.
The whole article is worth a read.
I've finally gotten around to extending the historical weather feature in Weather Now. Now, you can get any archival report that the system has, back to 2013. (I have many more archival reports from before then but they're not online.)
For example, here's the last time I arrived in London, or the time I took an amazing photo in Hermosa Beach, Calif.
I don't know why it took me so long to code this feature. It only took about 4 hours, including testing. And it also led me to fix a bug that has been in the feature since 2008.
I didn't have a chance to read these yesterday:
Now I'm off to work. The heat wave of the last few days has finally broken!