On Tuesdays, I write about the top voted question on Ask Berkun (see the lovely archive). This week’s question came via email from Pavel Pavia [43 votes]:
Are engineers more creative than designers?
Both answers (“Yes they are!” and “No they are not!”) are naive. It’s foolish to compare massive groups of people against each other especially around a sloppy word like creativity. Assuming you work in the making of products of some kind, we all likely know some engineers who are very creative and some who are not. We also know some designers who are very creative and some who are not. I can’t even imagine trying to average them out into two neat little piles and have the resulting comparison be of much use. But what then? Why can’t we have some fun? ok – FINE. Here we go.
Let’s start by ditching the word creative. It’s a romantic word and the wrong one. When someone hires an engineer or a designer they want a problem to be solved. The creative ability we’re talking about is to develop ideas that solve problems into working solutions. Do good engineers and designers both do this? YES. They might be different kinds of problems, and they may use different tools, but both show up at work with the intent to problem solve, not “problem create’ or “problem multiply” (although such people do seem to exist, unfortunately).
The first argument is usually an anecdote about how “all the designers/engineers I’ve worked with suck” and to that I say you might be right. You’ve probably never worked in a healthy, successful organization that respected both roles and hired talented people to play them. But they’ve always existed – look at the teams that made the best products you admire and I bet there was a team of both excellent engineers and designers working together. Until recently it was only in elite companies that these investments were made, but that’s changing.
The next argument is often someone pointing out that designers are really just planners, since they can’t actually build their plans themselves. They need an engineer to go and built them. But so what? Why is the ability to build something necessarily superior to the ability to conceive the plan? It might be superior, but it might be inferior. I don’t think Beethoven could play the trombone, but he could write the plan for what they (and dozens of other instruments) should do, and that’s why we know his name and not his trombone player.
But I’m not taking sides here. Not really. To succeed at solving problems you need both the plan and the ability to build it. The hard part is that depending on what the problem is, it can be either conceiving the plan or the ability to build it that is more difficult. And people are bad at recognizing when the most important challenge is in a domain that isn’t theirs (“If you have a hammer, everything looks like a nail”). Engineers are notorious for dismissing designers because of their own ignorance of what the customer’s true situation is (and the related potency of the designer’s plans), and designers are notorious for dismissing engineers because of their own ignorance of what the engineering constraints truly are.
The running sardonic joke in all this is designers and engineers tend to share more personality traits than not. Which include:
Passion for aesthetics (debates on visual style mirror debates on code style)
Preference for control (engineers love their control over bits similarly to how designers love control over pixels)
Reverence/Arrogance for idea purity (that there is a right way to do certain things)
A desire to make great things that help people
Which means many of the conflicts between designers and engineers are about bad management, the lack of a leader providing shared goals that unify these traits towards a common cause. Both trades are about problem-solving and when motivated can help each other with their individual tasks. Framed properly, and properly motivated, designers can have insights that help solve engineering problems and vice versa. All that’s required is some respect, shared goals and a curiosity to discover other ways to approach solving problems.
It’s useful to go back to a time when the distinction between designing something and engineering something didn’t exist. For most of the history of invention, people did it all themselves. When Archimedes or Archytas invented the screw (which is a mind-boggling act of genius), was he designing or engineering? Would anyone at the time have cared in the slightest what label was given? John Roebling, the architect of the Brooklyn Bridge, knew that to make something great required both great engineering and great design. He couldn’t build a beautiful, functional, enduring bridge without them both. He and his team would switch between thinking more like designers and more like engineers whenever necessary, as they were unconstrained by the strict delineations we’ve created for ourselves in modern times, and we should all consider doing the same.
[Note: Pavel’s actual question was “What is the reason for which we believe that the people who dedicate to the arts are more creative than the engineers?” but as I wrote an answer it morphed into a simpler question.]
I was a senior at CMU in ’93/’94 and for my computer science classes I spent many long hours in the computer labs, called clusters, working on programming projects or doing other schoolwork. Many of my friends hung out in clusters and it was common to see new software friends had found, or in some cases, made. I worked mostly in the Unix rooms, where all of the DEC and Sun workstations running X-Windows were, including their hockey puck shaped mice.
Late in ’93 or early in 1994 I remember being in Baker Hall, one of my favorite clusters, sitting in the back row (the photo above is from Ween Hall, a similar cluster, via CMU Archives, analysis). I wasn’t enjoying whatever I was doing so I looked around the room. Someone had a window open on their workstation with all sorts of images and text in it, and I asked him what it was. He told me it was Mosaic and he told me how to install it, which I did. I played with it for a few minutes, found it cute, and didn’t touch it again. There were only a few hundred websites and most of them were junk.
There were no search engines. There were no maps or guides. The joke was “There is nothing worthwhile on the web, and you will never find it anyway.”
What I can tell you is NO ONE thought much of the web at the time. I didn’t know a single person anywhere, in school, real life, or online, who thought this would ever become something mainstream, much less dominate the future, as the walled garden of AOL dominated how ordinary people interacted with each other online.
That year I read the first issues of Wired magazine, and even wrote for them, and they barely mentioned the web either. It just felt like yet another odd academic project, with few people using it. The Internet, meaning email, gopher, telnet and newsgroups, was something I’d been using in class for years (including The Andrew Project). I’d worked with Hypercard, Director, and studied different forms of hypertext tools in class. I knew about Project Xanadau. This “web” just seemed like yet another thing. And HTML, wasn’t even a proper “language” with barely any functionality other than crude text, links and images.
I was hired at Microsoft in 1994, and in early 1995 joined the Internet Explorer 1.0 team (where I’d work until version 5.0). Even then the web was far from mainstream. It was progressive for Windows to have a web browser at all, even though the first version shipped only in The Plus pack, along side screensavers and utility programs.
It wasn’t until the browser wars of 1996-1999 that the industry first shifted to focus on the web and the Internet, and only as society shifted from using dial-up modems to broadband, and eventually mobile devices, in the 2000s did it become central to most people’s lives. It wasn’t until 2001 that AOL saw it’s subscribers decline as direct access to the web became commonplace.
Lesson: The future often looks strange in the present. Any idea with the power to transform the world won’t make much sense at first. This is one of the best lessons from the history of innovation: if you want to be part of the future, keep weird stuff around.
When did you first see the web? Leave a comment, or write a blog post about it and I’ll link to it.
[Updated March 12, 2019]
This month I’m posting every day, picking the top voted reader question and answering it. With 50 votes, today’s winner, submitted by Peter Colligan, was:
Software Ethics – When is it acceptable to ship a low quality product?
I develop enterprise software. Sometimes the decision is made to ship when quality is low. I have as a professional software engineer no ethical recourse to such actions. Sometimes the impact is not death but extreme inefficiencies that cause overspending and unstable conditions for customers… Other professions such as medicine, drug research, etc. have professional guilds that extend beyond employment boundaries. Is this really a problem?
The short answer is there are no short answers on ethical questions.
If you sell something as “low quality” and the person buying it wants a cheap low quality product, what’s the problem? If both parties feel they got what they asked for, there is no ethical challenge regardless of quality (for addictive drugs or products producing toxic waste there may be communal ethics, but that’s another discussion). The rub then is what a product promises to do vs. what it actually does which leads to marketing ethics (e.g. are infomercials ethical? What about alpha or beta-software?)
Deciding when something is finished is highly subjective. The Brooklyn bridge was designed by Roebling to have cables 6x stronger than necessary, a very high engineering standard. This level of “quality” is rarely used in modern engineering work. Is this lower standard ethical? Or was Roebling unethical in wasting so much in city resources to build a “wasteful” bridge? Subjective indeed.
Quality, as the book Zen and the Art of Motorcycle Maintenance painfully explores, is hard to define. Creators and consumers often have widely varying standards for what good and bad mean (see Why Software Sucks). McDonald’s, the fast food restaurant, has nearly 2 million employees world wide. Is it unethical to work there because the quality of food is so low? Even if the quality is low, is it ok to sell low quality things if people want them anyway? When is it ethical to publish low quality writing? Could you win a law suit against a musician because you thought the song you bought was poorly sung? Is it wrong to post grammatically incorrect status updates on Facebook every day about your favorite socks? Objectivity in ethics is hard to find.
The simplest place to start is to spend as much time as possible with people who share your ethics. Does anyone else meet your standards? Can you find people who want to pay a premium for your higher quality work? If the answers are yes then your problem is solved. if the answers are no, then your standards might be too high.
The standards for many kinds of products are often set by the market. Progress often happens by companies making superior products rather than a committee decreeing a new higher standard. Sometimes there is a role for government to solve certain market limitations, e.g. automobile seat belts or fuel economy regulation, but that’s more of an exception than the rule.
The birth of medical malpractice and professional negligence as legal concepts are also worthy of study. The ISO had its first standard in 1951 and that standard was for… getting engineers to agree on how to measure things. Certainly an important development, but not a triumph of product quality. Professional associations are slow and even when they create good standards they mostly impact the reduction of the worst malpractices. The ACM does have a software engineering code of ethics but until doing research for this post I’d never seen or heard of it before and I bet most makers and consumers of software haven’t either.
It’s most germaine element for our interests is:
3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public.
The statement ensuring significant tradeoffs are clear is great advice for anyone making anything. In your case the decision to ship a lower quality product might be the best choice to balance out all of the clients tradeoffs. Software, unlike bridges, is easy to upgrade allowing for quality to be improved over time.
And in this notion of tradeoffs is perhaps the real answer you’re looking for. Improve your skills at selling the positive trade-offs of high quality work. Express how much clients will gain in the long term if they’re willing to invest more in quality work upfront. That’s an important skill that has nothing to do with design or engineering.
I read many books about the making of great things. I want to learn everything I can from historic leaders on important projects and how they succeeded and failed. My favorite genre is the project narrative, books that follow the making of something.
At first I read books strictly about software, but I soon found I learned more from broader subjects. McCullogh’s The Great Bridge, about the Brooklyn Bridge, earned one of the first rereads in my entire life as I was spellbound by the leadership, engineering and personal struggles in what had seemed so ordinary a thing (a bridge!). Reading about NASA’s space race, the London underground, and The Hoover Damn all factored deeply in my own thinking about how to lead projects.
My fifth book, The Year Without Pants: WordPress.com & The Future of Work is my attempt at the genre. And unlike most books in this genre I wanted to write it from the first person. The failing of most narratives is they’re written by outsiders. I wanted an insider view of a real project and real team, and to tell the story the way I’d tell it to a smart friend over beers, not flinching away from the tough and uncomfortable parts all real projects endure.
Having read dozens of project narrative books I found the limitations of journalists, people who rarely had insider expertise or who traded honesty for access, frustrating. I recall how deeply disappointed I was by Steven Levy’s coverage of the making of the iPod in the Perfect Thing, portraying a false (to me) world where everything goes perfectly well and everyone is happy about everything. I know real projects are messy and the larger the stakes the more complex and emotional the challenges, and the more careful a writer needs to be about offering lessons.
While writing the new book I returned to my library to see which software project narrative books still had power for me. Here are some of them, with a short review:
Soul of A New Machine, Tracy Kidder. Everyone refers to this book as the classic since it popularized both software and general audience books about it. But many people mistakenly recall the book as a heroic, inspiring tale. It isn’t. If you read it now, which I did, the story is harsh and sad. It’s a poorly managed death march led by a jerk who practices mushroom management. When I read it 20 years ago I found the work environment romantic and inspiring. Now it seems juvenile and exploitive. It’s fascinating how times have changed and if you read this book decades ago I recommend a reread. It will seem like a different book. Wired interviewed the people from the book 20 years later.
Show stopper!, G. Pascal Zachary. I read this in 1994 while working at Microsoft and found it wild. Punching holes in walls over bugs! Dave Cutler, the protagonist of Windows NT, seemed like a mad-man, and like Soul of A New Machine, at the time it released there was something I admired about his intensity and the drama. Now he just seems like an asshole, someone who would fail Sutton’s No Asshole Rule instantly. It also captures one slice of Microsoft in it’s prime, just a couple of years before the company’s pinnacle of public admiration at the Windows 95 launch.
Dreaming in Code, Scott Rosenberg. The most thoughtful book written by a journalist about a software project, Dreaming in Code wraps the tale of a project gone very wrong with big questions about why most software projects fail. The project in the book is code named Chandler, Mitch Kapor’s failed attempt to redesign personal information software. The tragedy of the book is how abysmal the management of Chandler was, with basic leadership mistakes made at every key point along the way. Kudos to Kapor for allowing Rosenberg truly honest access. My deepest criticism of the book is I just wish Rosenberg had been on a more competently managed project as it would have granted him better answers to the questions he asked. I think of The Year Without Pants as my response to Dreaming In Code, taking a first person approach to some of the same questions.
Mythical Man Month, by Fred Brooks. Published in 1975, a few years before Soul Of A New Machine, Brook’s offers insights on leading software projects wrapped around his own experiences at IBM. I was heavily inspired by his style in writing Making Things Happen, about my lessons learned at Microsoft from 1994 to 2003 (inspired even by the fact such a hybrid book were possible). MMM is thin on specific advice, and more of a collection of ways to think about making software. Many of his ideas didn’t catch on, and there are exceptions to Brook’s Law, the most well known advice from the book. But the honesty and humanity in his writing is a hallmark of my favorite kinds of writing about the making of things.
What narrative books about the making of something are your favorites? I’m sure I’m forgetting some good ones.
Next This week I’m moderating a panel on building online communities as part of WordCamp Seattle, at 1pm Saturday June 8th. I have four experts, either with vibrant communities or with wisdom about how to grow and maintain them. I’m looking for questions and challenges for them during the session.
The panelists are:
Michael Cyger, from isixsigma.com a B2B website that provides research and how-to knowledge for businesses
Most blogs struggle to get comments on posts, much less build an active user base that lead their own discussions. What insights would you want to hear from people who have made it work?
Even if you’re not attending WordCamp Seattle, what would questions would you ask? What situations have you experienced as a blogger that you want an expert’s opinion on? Please leave a comment. I’ll make sure there’s a writeup afterwards so you can read the answers even if you couldn’t attend.
Some of you know, in addition to my writing and speaking work, I work as a team lead for WordPress.com, managing a team of developers and designers. It’s an amazing place to work, and I’ve given a few talks about how we make design and engineering decisions.
You can read a popular post I wrote called How WordPress.com is made, which focuses on how our 100 person company works, even though we are distributed around the globe, all the time. You can also read Automattic CEO Toni Schnieder’s post In praise of Continuous Deployment, about how we deploy new features and code.
I gave a short lecture on how wp.com is made at WordCamp Seattle (an informal series of events around the world for people interested in WordPress) which you can watch below. When I gave this talk again in Portugal, someone from Corefactor made a sketchnote, documenting the core points I made.
If you get bored, skip to 18:30, where i talk about how we almost never use email. I talk about Jetpack at 23:00, and Q&A begins at about 31:00. If you have trouble with the embedded version, go here.
Thanks to the New York Times, I got a chance to ask Elliot Schrage, VP of Public Policy at Facebook, about his own settings on FB.
I’d like to ask Elliot, and all the senior staff at Facebook, what are the privacy settings for their own personal Facebook accounts? Can you share the settings (not your personal data, obviously) with the NYT and Facebook users?–Scott Berkun, Seattle
Not surprisingly, Facebook senior staff reflect a broad cross section of preferences for sharing and privacy. Because my role is more public, there’s already lots of information about me on the internet over which I have no control on Wikipedia, in news stories and blogs and in other places. These sources include lots of information I might prefer to have private, such as my e-mail address, but I don’t have the power to prevent that information from being available online or in a search index. Perhaps as a result, I use my Facebook profile for more personal information, and take advantage of our controls to target what I share. I’m open to accepting Friend requests from acquaintances and messages from everyone, but I generally restrict my sharing to Friends and members of the Facebook network at work.
Mark takes a different view. He’s more restrictive about which friend requests he accepts, but he’s more willing to share information about himself and what he’s up to with anyone who visits his profile. You can see how my and Mark’s profile differ by checking them out. The settings of other members of our senior management team generally fall somewhere between Mark’s and mine.
Hmmm. I thought I’d asked a pretty tight question, but somehow I don’t feel I got a solid answer. What should I have asked?
You can see the full NYT article here, with questions for him from others . The comments thread is pretty harsh.
I own an XBOX 360, but only play a handful of games. Most games I’ve tried these last years are so annoying in their UX/gameplay, that despite amazing graphics they are a chore to play. Since I don’t like chores I refuse, no matter what reviews, sales or friends say. That is, except for two: and one of them is Gears of War 2.
Oddly enough, I don’t play the core game – I gave up on the single player campaign halfway through (I was bored, which happens to me often in video games). However I do frequently play a wonderful mode of the game called Horde.
Horde puts you on the same team with friends, and you must work together to fight off wave after wave of bad guys. The teamwork aspect is one of my favorite things (I enjoy deathmatch type games, but I’d rather work with my friends, rather than kill them), as tactics and communication are a big part of the game (which led me to write Management lessons from Gears of War).
I don’t know anyone at Epic (which has a refreshingly simple website), and have no evidence anyone there follows me on RSS. But I hope the wonders of the web might help this little wish list on it’s way towards someone who does.
And in my magic fantasy land those Epic folks don’t get tons of ridiculous wish lists from throngs of fans, and are just sitting around today with no actual work to do waiting for a thoughtful wishlist like mine to arrive.
Primary Wish:
Do not fuck with horde (please?). You made something great here. It’s is one of the few multi-player creations that exists that’s co-operative for a team of up to 5, has excellent gameplay mechanics, and is geared (haha) towards long sustained evenings of playing with the same group of people. If you fundamentally mess with the formula, please always provide a classic version.
Game setup:
Host migration: Call of Duty 4 has the best multi-player setup experience I’ve seen. It’s remarkable for being smooth, fast, predictable, and most of all, reliable. In most games this part of the experience is neglected, as users are forced to deal with it to play, but COD4 is a high watermark. Specifically, they handle host migration fantastically well: In COD4 if the host quits the game or their web connection dies, the host role gets migrated to another player’s machine and the game continues. In GOW2, the game ends. Allowing players to start horde on any level is a nice work around, which I’m grateful for, but doesn’t help much in other modes.
Faster matchmaking – or at least better UI that explains what the hell is taking so long. A basic UI principle is that of awareness. When waiting for matches I have no faith “Searching” actually means anything – I’m left wondering if the problem is no one is online, my net connection is bad, if the epic servers are down, or something else. That spinning animation is etched in my brain, as I’ve stared at it hopefully for many precious minutes of my life.
Allow players to join in to horde games at any time. With GOW2 we have to quit, invite, and restart to bring players in. Horde can go long, and players sometimes need to leave, leaving a hole on the our team.
Multiplayer Gameplay:
Left For Dead is has the high bar for in-game management experience. You can vote to change maps, change difficulty (mid-game!), pause the game, and let the computer play for you so you can go to the bathroom (and not make your teammates wait for you), all done from within the game while it’s playing. They did a fantastic job. They recognized the major annoyances of multi-player games and eliminated them. It’s just a shame Left For Dead isn’t less repetitive to actually play.
Allow for autoplayer in horde, so players can step away from the game to go the bathroom without ruining things for team, or if someone’s net connection drops you aren’t hosed. It doesn’t have to be Stephen Hawking smart, but it does have to do something other than stand around like an idiot waiting to die.
Glitches:
I’m happy to have interesting kinds of difficulty in a game. But if something is frustrating, and goes against the gameplay model as designed, it’s a glitch, or a bug, or a defect. It’s entirely uninteresting to fight with a game’s own design to play it (which is a frequent occurrence). In real life, when I lose at chess, it’s my fault as the user experience is simple and predictable. But if I try to move my knight, and it crumbles in my hand, or explodes, or doesn’t fit in the squares the rules say are available, I blame the game.
Stop making me hide behind thingswhile I’m fleeing for my life. The UX for taking cover has some rough corners. When running away, a common part of the game, sometimes players accidentally collide with objects and “hide” despite the fact the bad guys are behind you, which usually makes you dead. This is bad. The core game design is to hide, I get that, but there are rough edges in panic/flee situations.
Make saving wounded players under fire more predictable. One of the most fun aspects of the game is how you can rescue teammates when they’re wounded, racing across the battlefield, while dodging bullets, your teammates cheering you on, to save them. But there are reproducible situations where when enough bad guys are around, the X button appears (the button to save them), but doesn’t work. In other cases, you can be standing right over them, but there is no X button. If tagging out isn’t allowed in close quarters, that’s fine – then put up a glyph up for that. But don’t make me think it’s my fault my buddy dies if it isn’t.
Make it easier/faster to drop weapons, especially when trying to save a wounded teammate. It’s reasonable how hard it is to move with Mortars and Grinders (machine guns) as they are heavy weapons, but dropping them should be something that can be done instantly. In close quarters it seems the control (switching weapons to indicate dropping the heavy one) can be unresponsive, which means the weapon doesn’t drop, your friend doesn’t get saved, and some cases a cascade of mistakes follows, and everyone dies.
Make mystery time between waves less mysterious. Having weapons and shields disappear between waves is fine and adds resource management to team challenges. But a countdown timer or some indicator of how much time left seems fair, given it’s impossible to know if you have time to drop your shield to grab that grinder gun. In the current design it’s possible to lose both weapons if you try to switch, but overestimate how much time remains. I don’t mind magical disappearing things, provided it’s predictably and transparently magical.
Disappearing shields and invisible weapons. Half the strategy of higher levels is killing bad guys in the right order so you can use their gear. But killing Maulers, who carry shields, sometimes results in their shields mysteriously disappearing. The opposite problem is when a shield is placed in the ground, and an extra weapon lands near it. It’s impossible to get that weapon, as all you get is the option to pick up the shield. So you have to pick up the shield, move it, drop it, and then go back and pick up the weapon.
True Wish List (Things beyond basic UX issues):
Scoring that reflects co-operation. In higher levels a key role is “shield boy” (aka “rodeo clown”). Someone often has to get up in front and hold bad guys back, but they get zero points for this activity. The only points earned for co-operation are tagging out players, but it’s a pittance (50 pts). It’s a team game and like +/- stats in basketball, there should be ways to score points without being great at killing the bad guys. I’d like to avoid the pinball like scoring in Call of Duty, but some reward each round for the player who did the co-operative things most likely to lead to survival deserves acknowledgment.
Fun end of game reporting. No one ever sees the end of game scores – the game ends, and everyone bails. Another great detail of Left For Dead is the end of game info, which tells each player their shooting accuracy, their total points, the bad guys they killed the most, who died the most frequently, etc. Which is lots of fun to watch together. It’s fun, but also feedback on gameplay, suggesting how players need to improve, or what impact our tactics have or don’t have.
Some basic rules for enemy spawning. We’ve spent a lot of time studying spawn points, and have determined there is a heuristic involving where the players are on the map. Our core strategy is to have a safe box (aka “the hidey-hole”), that we inspect and then form a perimeter around. But every now and then enemies spawn behind us, which is impossible given the laws of physics. These surprise attacks can be thrilling, but more often betray my sense of the rules of game. I’m not asking for an easier, or even more realistic game, only for some transparency in the spawning rules. Unless the bad guys have the power of teleportation at will, which could be interesting in limited doses, they shouldn’t magically appear in a room we’ve already swept. Or if that’s the rule, I’d at least like to know what it is.
Variable size/paced waves (“The random attack”). Left for Dead has survival mode, which goes for long stretches without a break. This is interesting, in concept, but gets tiring quickly. It’s too brutal. But working the other way, in Horde there is room for more randomness – once every 5 or ten waves, could be an enemy SWAT team attack that occurs, or an extra weapons drop, or a boss-type enemy, something that doesn’t happen regularly that mixes up the fixed pacing of horde (which runs a similiar sequence of 10 waves again and again).
Bonus wave. A specific idea for the above, is a bonus wave. 80s video arcade games, like Pac Man and Galaga, had bonus waves where the rules were different, every 5 or 10 waves. They did this to break up the rhythm and pace. It could be as simple as having a surplus ammo wave, where there were tons of ammo and weapons. Perhaps there’s a score bonus if all the ammo boxes are collected. Or a series of shields that must all be moved from one part of the map to another. These waves would be optional – no penalty for not participating. And the appearance of a bonus wave could be based on team performance in some way.
Map editor for Horde mode. Every fan boy always wants a map editor for every game they play. But I don’t care about them – I basically only play one game, horde, so I only want a map editor for that. There are so many dimensions to gameplay in horde that could be extended and developed by maps of different size and design. I’m not sure in principle why a game company wouldn’t a community around the game to be able to make maps (but can imagine not wanting to spend money on the resources to make it possible and support it).
Host migration: if someone quits the game, host gets migrated to another player’s machine
Faster matchmaking – or at least better UI that explains what the hell is taking so long.
Allow players to join (be invited in) to horde games at any time
Improve UX for taking cover so players stop accidentally hiding behind objects when trying to run away
Minimize the bugginess in taging out wounded players (x appears but pressing it doesn’t work, or you’re right over the wounded guy, and no X appears)
Make it easier/faster to drop weapons, especially when trying to tag a wounded teammate
Allow for autoplayer in horde, so player can step away from game to go the bathroom without ruining things for team
All data is biased. There is no single count on market share, so never allow yourself to get the final word from one sample. Browsers, like cars, reflect demographic differences. The browser data from slashdot.org will be very different from wsj.com, because of age, income, gender, profession and other differences that are not representative of the total population.
A large percent of browsers users do not choose their browser. One play Microsoft made in IE4/IE5 was to invest heavily in IT deployment of IE (See IEAK). They made it very easy for large companies to rollout IE across 1,000 of desktops, including libraries, university’s and other places that control many desktops. This is likely an anchor of Microsoft’s market share as I don’t think anyone else does as much for them. This user group is notoriously slow to upgrade or change. It is hardest for Chrome, Firefox or Opera to penetrate this usage base. Big shops bet more than just the browser on IE: they bet lots of web apps and internal tools. To switch requires rebuilding that infrastructure, making the choice much larger than just browser installs. The browser is free but there’s much resting on the decision that isn’t.
Firefox’s growth has flattened in part because of the above. Most of the people who care what browser they use and have the choice have already chosen. The next wave of growth has to be fueled at reaching out beyond Firefox’s core base of younger, more tech-savvy people (or people who want to pretend to be young and savvy). Chrome has likely been the Ralph-Nader of browsers, stealing some of Firefox’s thunder. Opera is still the same creative but lonely story , a very inventive product that most people rarely hear about here in the U.S.
We forget most people don’t care much about browsers. If you read this article, and have seen browser stats in the last month, you are a browser geek like me. Few others on this planet care much. If they’re my age or older, and the web isn’t a key part of their social life, they’ll use what they have and unless it explodes or makes them cry, they won’t think about it. At WordCamp SF this weekend, I heard IE referred to as “the browser for old people”. A browser is one of the most passive kinds of software ever invented: it’s a platform for the websites not for itself – the browser UI occupies maybe 10% of the screen at all times making it forgettable by design: if its working well you shouldn’t notice it. In a great post on pingdom, they studied the upgrade rates for each browser, and IE users upgrade the least, or IE does the worst job at convincing its users to upgrade.
HTML5 will not save us. The world is confusing to most people in part because they’ve never attended a standards body meeting. It’s a bloody, messy, clumsy, slow and frustrating process for everyone involved, and although it is necessary and I believe in standards and I’m glad we have the W3C, the process is always problematic and painful. HTML5 will be progress, for sure, but there will always be the same challenges of sorting out what Chrome did, but IE didn’t, and what FF did right but Opera or Safari did wrong, or just differently. Wise standards bodies depend on implementations to validate their standards, and as the different browsers are competitors, it’s never a straightforward process – it’s a huge unavoidable compromise – meaning the results are never as straightforward as we wish either.
Since the killer feature is dead, the battleground is on core (speed, security, reliability) which are not Microsoft’s strengths (certainly in perception, if not reality). Microsoft is still dominated by the annual release cycle, with big marketing pushes around the new features in each release. But Chrome has made a different bet, aimed both at IE’s weaknesses (big, heavy releases) and Google’s strengths (speed, less legacy code, web-app focused). They are pushing an argument, supported by the vibe of the web – catching up on features can be done, but catching up on perf and security is much harder (even if we’re just talking perceptions of perf and security). Firefox is curiously in the middle: with the common bevy of tabs and extensions, it’s not a spry little browser anymore, but instead a happy compromise between Chrome and IE. The rub is they are now being attacked from both sides, above and below, and they’re no longer the lightweight alternative.
Stats I want to see:
What percentage of browser users have at least one plugin? I mean one that they chose to add themselves. I bet this number isn’t as high as we all think it is, but I’ve never even seen an attempt to document this. It might be a useful comparison between browsers: both the number of available plugins, and their frequency of use, per browser.
What percentage of installed browsers could be changed by the user? I’ve never seen this stat either, but it’s key. If there are 50 million web browsers open right now, how many of them are operated by someone who is allowed to change it? And knows how? It would indicate to both Microsoft and Firefox exactly what they need to protect or go after.
Personally I’m still happy with Firefox. I gave Chrome a spin when it was first released, and was pleased, but not enough to switch. The handful of FF plugins I use keep me tied to it, in what is a a kind of meta-killer feature: plugin addiction. I’m locked in to the plugins I have and they’re browser specific, forcing me, post facto, to stay with the browser I have.
My friend Phil Simon published a book in 2008 called Why New Systems Fail. The book explores the many reasons why projects, mainly IT projects, fail and what a wise person can do to prevent and recover from these situations. It’s a hard nosed, low to the ground book, which tend to be my favorites. The book did surprisingly well in its first printing, so the book was reissued recently in an updated and revised edition.
Given failure is one of my favorite topics, I interviewed him about all things failure and his take on why some projects work well, but most don’t.
CONTEST: Phil will send a copy of the book to the person who leaves the best comment or question below.
SB: I’m a fan of failure and its value in teaching us things. But to label a book “Why new systems fail” might seem cynical or depressing to some. Why did you choose such a provocative title?
PS: Some have called me (and others who write routinely about failure) cynical. If you look at the statistics on IT project failures, though, you’ll see that more than three in five fail. So, is that really being pessimistic or realistic? I tried to write the book in a way to maximize success but, to me, it’s irresponsible and misleading to pretend that IT projects tend to go well.
More than just whining about problems, I pepper solutions to implementation and project challenges throughout the book. It’s about avoiding failure, not simply stating that things can go awry.
Consider the analogy of going to the doctor’s office. How can you expect to be cured if you don’t talk about what’s ailing you? How can a doctor prescribe treatment?
There are big differences in culture between projects for profit, and IT or infrastructure projects inside companies. The latter are often more bureaucratic and political. Do you think there is a difference? Are IT projects harder or easier?
I completely agree with you. In short, I believe that generally there is a difference between the two (although there are exceptions).
“For profit” software development projects tend to differ substantially from “implementation” projects. Let’s define the latter as those that involve purchasing a software vendor’s prepackaged product, configuring it, testing it, and implementing it. Those systems never face external customers. They’ll be used exclusively by internal folks in accounting, HR, payroll, etc.
Developing a product to be released to the market can unify a company, particularly if it’s a small outfit. If the product’s people are incentivized (through bonuses, stock options, or recognition), then the development can go (relatively) smoothly. People want to make the product a reality. There can be an “all hands on deck” approach because that product is part and parcel of the company’s identify. Employees want to show off its bells and whistles. Human obstacles to progress are more quickly identified and removed if necessary.
On the other hand, implementations rarely go smoothly for all sorts of reasons covered in the book. At a high level, different people and departments often have vastly different agendas, up to and including killing the implementation itself. I’ve seen it many times. Often, this lack of a singular organizational focus ultimately causes IT projects to fail. Some people don’t want the new system; they like the old one just fine.
As to which is harder, it’s hard for me to unilaterally say. I have worked on relatively simple implementations that have gone fairly smoothly, even though the system was quite complicated. People knew that their jobs would change and they just dealt with that.
It’s one thing for something to fail dramatically (unmitigated disaster), like say the Challenger shuttle disaster, where it’s so bad everyone is forced to confront the causes. But in IT it’s often easy to hide, bury or whitewash projects so they don’t seem as bad as they are. Do you think the ability to hide failure contributes to the frequency of failure? What can a manager do to minimize this?
Absolutely. For obvious reasons, organizations and key people aligned with the success of a project have strong incentives to under-report failures. For example, I have seen people call activating a reporting dashboard “a success” even though it contained only one report and no one ever used it. I have also seen people fudge numbers to make overages less obvious.
As for what managers can do, it’s a very tough question because of all of the constraints. What do you do when the CIO essentially tells you that you have a week to do something that should take a month? What do you do when you recognize that a key person isn’t performing yet have no direct authority over him/her? What if your boss won’t publicly cop to it, but he’s told you privately that he wants the project killed or postponed?
These are all people issues that make up the much of the book.
Why New Systems Fail reads like a handbook and checklist for common mistakes to avoid on IT projects. But in many cases the being aware of problems doesn’t mean you have enough power to prevent them. How do you compare political and organizational problems to project management problems in terms of how often they’re the root cause?
As you know, awareness of an issue and the ability to fix it are two very different things. It’s hard to separate PM issues from cultural/political/organizational ones. For instance, it’s possible to have a great PM and team running up against constant institutional issues that prevent the project from being successful. It’s also possible to have a great culture conducive to success and a poorly planned and executed project within that culture.
I have found in my years as a technology consultant that both of these two extremes are unlikely to be found. Typically, organizations with oodles of politics, an aversion to change, difficult end users, and cultural problems tend to run projects poorly. That includes appropriate staffing levels, comprehensive requirements’ gathering, sufficient data validation and testing, acceptance of new technologies, and all of the things that collectively cause projects to fail.
I have said before that Jack Welch himself could not have rescued some of the unmitigated disasters in the book. Companies with challenging cultures have a tough time managing projects and implementing software on time. Is this a PM issue a cultural one? It’s a chicken-and-egg question.
CONTEST: Phil will send a copy of the book to the person who leaves the best comment (in his opinion 🙂 or question below.
At The Economist Ideas Economy event Matt Mullenweg, founder of WordPress, in an excellent talk about open source software, proclaimed the end of the killer feature. He asked the packed audience of high profile influentials how many people use Firefox, and how many of them have a plugin installed – and a good percentage of them raised their hands.
He has a point. For many kinds of products, it’s the end of the killer feature. Not everywhere, not for all kinds of products. But the trend is definitely the other way. And the trend has been happening for some time.
There was a day and time when software product launches hinged on features (or killer applications) and how the new features compared to the old features competitors had. The browser wars were perhaps a peak of this kind of guns blazing feature rich marketing warfare between two competitors. Back then it was expensive to launch products and press millions of CDs, and ship them in boxes. It took time and money and you needed expensive waves of promotion to propel each release forward.
But today, with websites, iPhone apps, and web browser plugins. new feature additions are cheap(er) and can roll in at any time: the feature set matters, but it matters less. What matters more are the overall user experience and the quality and depth of the plugins/apps available for people to use.
Curiously enough, Apple’s app store is leading the way in 2010, which is an inversion of what happened in the 90s with Microsoft and Apple. The success of Windows 95, in part, was based on the huge platform of applications it had compared to the Macintosh. It didn’t matter than the Macintosh had a better experience, the availability of apps drove the decisions for many people. With the iPhone, perhaps for the first time I can remember, a product has both superior design and a superior 3rd party platform.
But the new plague we have is the annoyance of syncing upgrades and compatibility. To stay secure, we’re compelled to keep everything up to date. But my Firefox install has a half-dozen plugins, and every time Firefox itself updates, it causes a wave of incompatibility across those plugins. I’ve had the same problem with WordPress too. I never know now when I upgrade one thing, how it will impact the others, and the more plugins and apps I have, the more of a problem this becomes. It has happened before that a plugin, or app, is abandoned: , it can’t make the upgrade with me, and suddenly I’m surprised to be without something I’d grown to depend on. I’m dependent on a wider and wider set of people to get the features and things I want, which has its advantages, but its disadvantages too.
At a certain point you hear a name for something so many times it looses any real meaning. It’s just a name. Kleenex, as a word, doesn’t mean anything. Neither does Häagen-Dazs. But over time words just become labels and we forget their origins or initial meanings.
But in the case of Cloud Computing, I’m still stuck on what an awful metaphor it is for anything.
Clouds are fleeting. They don’t last long.
Clouds are vague and open to wide interpretation. No one sees the same thing when they look up at clouds. (“Do you see Darth Vader’s nose?” “No… oh do you mean the leg of the camel sitting under a tree?” “What Camel?” “Nevermind”)
Clouds often bring rain, lightening and cold wind.
You can’t see the sky, or the stars, when the clouds are out.
Found this nice observation on work culture, that could fit in the ever growing asshole driven development list:
HiPPO – Highest Paid Person’s Opinion Wins:
Hi there. I’m now back from my ramble through Scandinavia.
If you were at my seminar in Milwaukee (we had many questions on estimates and schedules), or struggle with bad estimates somewhere else in the world, you’re in luck.
Next week my friend Steve McConnell is doing a free webcast on the ten deadly sins of estimation. As if the regular sins weren’t bad enough, these are the ones that kill. Registration and details here. Tuesday June 23rd, 10am PST.
And here’s more stuff from Steve’s consulting firm, Construx, on estimation:
I’m a huge believer in teams. Team sports. Team players. Team leaders. It’s all about teams. Show me a great project and I’ll show you a good, or not totally sucking team. Show me a project in trouble and the first questions I’ll ask won’t be about methods, schedules or technologies, I’ll ask about the team.
I’m also someone who hates bullshit. Who gets frustrated by phony stories about made up concepts on how good teams are nurtured and how great teams function. I want the real stories from the people who were there. I want the dirt. I want the scars. I want it all.
So I’m thrilled to tell you O’Reilly is finally publishing a book on teams, with chapters from two dozen luminaries from the software world, on what they learned from the teams they worked on. Tim O’Reilly, Cory Doctorow, Grady Booch, Steve McConnell, Barry Boehm, Karl Fogel, Johanna Rothman, the list of kick-ass names who contributed to this book goes on.
I was lucky enough to be asked to make two contributions to the book. A chapter about my experience on IE4 called “Why Ugly Teams Win”, and an extended interview with Steve McConnell about good teams and how they’re made.
As a kicker, profits from the book aren’t going to contributors, they’re going to charity – Playpumps International to be specific.
How did you work with those infamous programmer-jerks? How did you handle rough inner team situations?
The best place to start is empathy. Why is someone acting like a jerk? There are basic psychological reasons for this: Either they are insecure, unhappy, or angry about something.
Ok, there is a fourth reason, that they are psychopathic hell spawn put on the earth to torture all living things in a 10 foot radius, especially you, but lets assume that’s not the case for a moment.
In all three cases it’s possible they have good reasons for behaving like a jerk. Perhaps they are angry at upper management for the same reasons you are, but they see you as part of management (which, if you’re a PM, you are). Or maybe their last project manager was incompetent. Who knows? Not you. You don’t have a clue.
Odds are good it has nothing to do with you – it has to do with how they feel about what’s going on around them. Starting with a little empathy opens the door to finding a solution. If you start with “Fred is a jerk so I will treat him like one” you are likely perpetuating his reasons for behaving like a jerk, and everyone loses.
That said, there are four assets you have: charm, ability, roles and allies.
Charm to connect. Being likable goes a long way in dealing with people. I don’t mean false niceness or being a cheezeball. I mean using your sense of humor, your natural generosity, your shared interests with someone to establish some basis for positive interaction with another person. It could be almost anything, but look for it. Good morale events help make these connections happen. If you happen to like Metallica, or Porsches, and they do, you now have something positive to talk about where it’s safe for everyone to share and connect.
Demonstrate your ability to help . If they love making great software, if that’s really what they want, then you just need to show you can help. Even if it’s just helping meetings run better, or eliminating stupid annoyances in how decisions get made, defusing politics, reducing meetings, etc. There are a thousand easy things a decent PM can do that the programmer will noticeably benefit from. Start by asking “what can I do to make you more effective? more productive?” And listen to their answer. Do some of what they ask, come back and ask if it helped. Even if it’s a small thing, you’ve now built a tiny basis of respect for how you can help them.
Agree on the roles you both play.More than half the time PMs suffer because people do not understand what the PM is doing. What you need to do is sit down with the programmer and make three lists: what I do (write specs), what you do (write code), what we both do together (triage bugs). Invariably there will be disagreements as to who does what work, but by listing them you’ll find all the sore spots in your working relationship. If you strongly disagree on roles, and he thinks you should wash his car, you should be able to go to your respective bosses and ask for clarification.
Get help from your Allies. Which programmers do you get along with best? These are your allies. Ask them for input on working with Fred. Get their perspective on the frustrations on being a programmer in your organization. You may be able to see Fred in a different light. Have other PMs worked with Fred? What insights do they have?
Of course if after investing some of this energy you decide Fred is, in fact, demon spawn hellbent on destroying all positive energy in the universe, talk to your boss. If Fred is as bad as you say, others will complain and it will become your managers job to solve the problem (fire Fred, move him to more isolated work, get him a therapist).
Most of the time the real problem is people not sharing goals, and not listening to each other. Two things that your average project manager should be good at identifying and resolving.
Jurgen Appelo over at Noop.nl put together a list of the top 100 blogs for software developers. My blog, the one you’re reading, slides in at #18, which is surprising given how little I write purely about software development these days.
Happy to be on the list – and if you now realize you hate this blog because of it’s lack of emphasis on making software, you now know where else to go.
Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.
It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.
And they can be useful – but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.
How to run a successful bug bash:
Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (“If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event. A case of beer and few pizzas costs $60. Well worth it.
Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ – give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.
Thanks to Brady Forrest and Jen Pahilka for giving me not one but two slots this week in a high caliber lineup. It was awesome to meet and talk to so many folks in just a few days (talking to people is always where the value is). (Photo credit: James Duncan Davidson).
Its been awhile since I’ve been to a big tech conference around a singular theme (web 2.0) during its rise. To see both the promise and the hype swirling around together made for a fun couple of days. Walking the expo floor, where vendors and companies demo and pitch for your pleasure, gave me flashbacks to Internet World in ’96 and ’97. Back then, there were a zillion “push technology” companies, services and products. Now it’s “social media” or “web 2.0”, with a zillion companies all throwing the same jargon around and mostly failing to distinguish themselves from one another.
There are certainly good ideas in the mix, and I think Tim O’Reilly and Clay Shirky‘s opening keynotes did more than any company I saw to speak for those ideas, or even attempt to describe what substance might surface from all the technology, energy and money bouncing around.
The problem for me is how infrequently people investing their lives making these things can describe how, at the end of the day, all of the potential described gets transfered into value. Or why the value provided is worth the risks and costs of using whatever they are selling (register for this, buy that, use this, etc.) It’s not a complex question, but it is the primary one I’m sure many attendees were asking: how much substance and takeaways can I fish out of the buzz?
I wasn’t surprised, but I didn’t hear anyone mention how many amazing things are made, in 2008, by organizations with little interest in web 2.0 concepts – namely Apple, Toyota, your favorite film director, or your favorite music band. Not to mention all of the great amazing things the world produced before 1994 (the year the web, even in 1.0 form, was born). That’s not to say this alone proves anything – my point is only this: it is possible to achieve amazing things, without -insert name of current trend here-. Thriving communities, tribes, and cultures have existed for ages. If its possible to do well without whatever the new secret sauce is, it suggests there’s an underlying element that’s not being talked about. I’m convinced there is a more refined explanation for what people might gain from buying what the expo vendors are selling, but very few people seemed capable of even suggestion one.
The unspoken nugget / explanation / marketing line that might get me jazzed is this:
We have always been collaborative. Always been social. It’s in our genes and it’s what we have evolved to do well. Good technologies enhance our natural abilities, give us useful artificial ones, and help us to get more of what we want from life. Web 2.0 and social media make the process of collaboration and developing relationships more fun, efficient, powerful and meaningful.
Ok. Now we’re talking. With a statement like this I can walk the halls of the expo, or converse with the greatest web 2.0 pundit, and have a straight conversation. Will this get me more of what I want from life? More of what my customers want from me, or vice-versa? I can make tangible arguments about what I want or my customers need and sort some decisions out. But note that the statement above is devoid of hyperbole like revolution, ground breaking, disruptive or transformative, things that are entirely subjective. If you identify a real problem well enough, you never need those words: the people who have those problems will naturally find what you do revolutionary if you really solve their problems.
Ok, enough industry talk. Here’s some shop talk for anyone that saw me speak: I’d give my performance at my innovation workshop a B and the keynote a C+. The keynote was mostly new material and, surprise, I never found my rhythm. I gave it my best but it wasn’t a great 10 minutes. The other funny thing is that the tech crew warned me the remote doesn’t go backwards – it’s kamikaze style – a warning I shrugged off as I couldn’t imagine in a ten minute talk needing to go backwards. Well, guess what, I did. I could have asked them to go back if I’d wanted but didn’t, it wouldn’t have saved my performance anyway 🙂
Last week I upgraded to the latest version of WordPress. I’m a huge WordPress fan, I love what these guys do, and I was psyched to see what they’d done this time around.
Total time: 9 minutes. This was end to end, from downloading their software, to reading instructions, to the moment I was able to make my first post. And this included an extra 2 minutes where FileZilla imploded and I had to start over.
Summary: Thumbs up. Go get it. Most of the changes are for the positive, the UI is cleaner, my top gripes (text-editor and thumbnails) have been fixed, and there are some new minor features. Top complaints are UI fit and finish, there are some gotchas that should have been caught.
Kudos:
Text editor is much improved: less buggy, fewer perf issues, and better media support. People spend 80% of their time in WP here so happy to see investments to core use here.
Site wide search instead of just blog posts – obvious win.
The UI visuals shows some style love – in many places, like the comments view, the style choices make it easier to scan long lists. Other nice touches include a flag next to the comments tab when there are new unmoderated comments.
Many under the hood improvements that I don’t fully understand or expect to use but feel good about anyway.
Automatic plugin updates. Nice, though this broke for a few plugins I had. Expect the kinks will be fixed by plugin authors from here on out.
The install is just a few steps and takes minutes with no special skills required.
Complaints:
Leap of faith upgrade. Doing hand copying of files is very 1980s. I read the instructions ten times to make sure I had it right, and even then I had the willies while waiting for both the files to be copied, and to see the new dashboard working. The intermediary UI didn’t calm my fears at all. Say what you will about Windows or Mac software, but great relief comes from pushing an “install” button, and watching one little progress bar while the software does all the work. Instead in WP there’s a useless page offering no clue how long it will take, and given my hand-copying of files, no way of knowing if I’d screwed something up. To be fair it did take about 20 seconds, but they were the most stressful I’d had all day.
Admin redesign. This felt not quite finished. It’s definitely improved but has 1 step back for every three forward. It’s a space heavy design, with several levels of hierarchy floating in dreamy soft blues and whites. If it’s really a dashboard it should be more software app like than a webpage, but it feels more like the later. The core problem is 4 levels of UI, with varying left right dominance, creates a visual ping pong (left, right, left). Plus there are mismatches of prioritization: The Write a new post button, the most used button on the page, is off the right, while the text “Right now” gets prime real estate on the left.
Tab confusion. The UI rules for tab are simple, peers share the same tabs so people know what is on the same level as what. But there are three orphaned tabs all the way on the right that turn out to be peers to the stuff on the left. No idea why they’d do this. Similar problems on the top with a dashboard tab all the way left, and three orphans on the right (Help/Logout/Forums)
Settings confusion. Much of the UI in wordpress is config related, but is there really a need for three different hierarchies for Manage, Settings, and Plugins? Some of the UI in each can be compressed (e.g. Privacy has one option and doesn’t deserve it’s own page). Even after a week of use I find it hard to remember which top level category to go to for what.
My everyday tasks are still hard to optimize . This is my top gripe. I’m a very basic, vanilla user. I post 2 or 3 times a week, text and link heavy, with images and thumbnails in most posts. That’s it. No media streaming, no dashboard customization, no multi-users or anything whiz bang at all. Yet I still find it clunky to add images, check links, preview and review, and worse, despite having done it 5000 times there’s no efficiency path. No shortcut keys or tricks to make my routine faster.
Nitpicks:
The Comments listing should default to showing unmoderated comments. That’s the primary view people with moderation on need to see when going to the comments page.
On the home dashboard page, first page people see, the word dashboard appears 3 times, all on the leftmost column. The second one is highlighted to indicate it’s active, so the third one isn’t necessary. If people don’t notice the red highlight means it’s active then change the highlight, don’t add another instance of the word.
Moving the category field to the bottom of the post page is a huge pain. Most people use categories so they hit this set of checkboxes for every post. The current layout forces two scrolls: one to get down there, and a second to scroll the list of categories. This UI should be in the critical path of the UI design for the post page.
The add media UI is overkill. First, clicking on that tiny little image button takes over the whole screen. Blam – I thought I’d broken something. It’s a jarring, horrible transition. Going modal is ok, but don’t hit me over the head. There are other issues with the flow in this UI: not sure what use cases it is designed for, but everything seems to require lots of steps (And what does Crunching mean? Downloading seems more accurate).
.
Even with my complaints, I strongly recommend WordPress. If you want to give it a spin, you can use their free, hosted, blogging service at wordpress.org. If you’re thinking of upgrading or switching check out this handy guide: How to update wordpress with minimal downtime.
Thanks to 
