It’s late in the year 2000. While I haven’t heard the term yet, the dot-com crash has just begun. The first wave of ill-advised internet ventures are going out of business. At this point people generally seem to think of this as a mild hiccup. This is a perfectly normal part of the New Economy. Sure, a few Bad Ideas are flaming out, but that just leaves more room for our Good Ideas, right? Everything is fine.
I’m still working on making a virtual mall. After the uncomfortable meeting, I’ve been shy about challenging the design. I’ve washed my hands of the whole thing and resigned myself to spending months building this sad, doomed thing. It’s soul-crushing to put all this effort into something that’s just going to make people miserable, but I don’t know what else I can do.
I’m dreading launch day.
Knowing What You Don’t Know
Back in the mid 90’s when the company was really young, I handled our technical support for a few months. It’s a miserable job, although it’s also strangely educational. Among developers, there’s often a bit of disdain for “stupid end users”. When users don’t utilize the product the way you expect, it’s easy to shrug your shoulders and conclude they’re morons. But if you spend some time reading their feedback and following their complaints, they seem less stupid and more like people making mistakes because they’re already familiar with some other complex system and they’re dragging assumptions of similarity into their attempts to use your software. Trading a few emails with that “moron” might reveal that he’s actually a respected PhD in a challenging field. Maybe the problem isn’t the user. Maybe the software is bad at explaining itselfAlthough they could also be a moron. It’s not unheard of..
Reading questions from users can give you some kind of framework for understanding what sorts of assumptions people favor and how they approach your product. This can help you to anticipate and avoid misunderstandings. You can sneer at people for being “dumb”, but that’s not going to solve the problem. Often you can head off a great deal of confusion by simply re-coloring a button, changing the default behavior, re-wording a tooltip, or moving some controls around.
I’m dreading launch day for the virtual mall, because I’m anticipating a disaster. I don’t know how many people will show up, but I can’t imagine what it will be like when all of those internet newbies try to use our software. If experienced webmasters get befuddled when they drag their webserver assumptions into our 3D world, then how much worse is it going to be when John and Jane Newbie show up and try to learn all about online shopping, 3D navigation, their computer, and the internet, all at the same time? What sorts of mistakes will they make if they drag their suburban mall assumptions into this “shopping videogame”?
What will be the most common pitfall? People showing up with 4 year old computers that can’t run the software? People who have literally no experience with games and don’t know how to navigate in 3D? Griefers? People paranoid about credit card security? People who are too cavalier about credit card security?
We’ve never had users like this before, and we have no idea what kinds of problems they’ll run into. Which means that we’re going to learn that the hard way when it launches.
Worse, a lot of my design concerns were deflected by saying “We’ll cross that bridge when we come to it.” When I pointed out that the submitted design is likely to cause confusion, it was decided that we’d stick with the design and change it later if it turned out to be a problem. That’s fine if you’re just talking about one or two little things, but when you’re talking about dozens of large things that cut to the core of the design you can’t just casually change them later.
What I’m anticipating is that it will be chaos and confusion on day one. New users will show up, get confused, and in a storm of frustration they’ll bury us in support tickets. Then we’ll need to change the environment to match what I originally suggested. Only instead of doing this carefully over time during development, these changes will need to be slapped in at the last minute, in a panic, while the software is in use. I’ll end up working some death-march crunch time after release, working to fix things that could easily have been built properly in the first place.
Worse, I won’t even get to enjoy an “I Told You So”, since I’ll be the one bearing the burden of the bad decisions I advised against. The management types at fault aren’t even in the loop enough to understand the cause of the problem. Just like tech support people like to blame “those dumb users”, management will probably blame “those incompetent developers” for any problems that pop up. The only way they could understand is if my boss went to them and explicitly dumped the blame in their lap. I know human nature well enough to know he’s not going to do that without a spectacularly good reason, and giving Shamus Young an “I Told You So” is not a spectacularly good reason.
It might be nice to fantasize about sitting down in front of management and explaining that this particular fire is the result of their policies, but that’s just not how people behave in the corporate world. That’s far too confrontational, and that’s not how you change people’s minds anyway. Instead these problems will be used as leverage in future meetings.
“Remember the fire we had last month? [That I had to put out.] It turns out that was a result of the policy [that you came up with] to save money by building our offices entirely out of straw and using candles instead of lightbuilbs. Well, I’m advising [just like I did last time] that we should use drywall instead of the wood you’re suggesting, and that lightbulbs would be better than the oil lamps you’re advocating.”
Over time, you can gradually teach management to trust you and instruct them how the business works so they don’t make as many bad decisions in the first place. The problem is that your business needs to survive long enough for this to happen. If management is too far behind the curve and their trust in you is too low, then you’ll go out of business before they learn enough to do their job properly.
You can daydream about explaining to management how everything is their fault, but that’s a Hollywood fantasy. There’s not going to be a musical swell that ends with the president suddenly transforming into a whole new person. The worse things get, the more people want to avoid the avalanche of blame for all the hardship everyone is about to endure. This will magnify management’s faults instead of correcting them. In the real world, changes to management style are rare, incremental, and hard-fought.
The virtual mall is not the only project we’re working on. In the downtime between major milestones there are more day-to-day concerns we need to worry about. Sometimes I step away from the mall for a few days to fix things for an existing client or make assets for a pitch to a new one. These are quick jobs that usually take a day or two at most, and we squeeze them in whenever the mall is held up waiting for feedback or paperwork.
One of the problems afflicting our company for the past few years is that everyone has a different vision for what we should be doing.
One person wants us to be kind of like “the web, but in 3D”. They named our client the “3D Browser” so people think of it as analogous to a “web browser”. Their long-term goal is to make the software as distributed and ubiquitous as possible. (This vision is undercut by the fact that both our client and server are proprietary and use closed protocols, and that’s never going to change.)
Another person thinks that since we started out as a “3D chat” program, chat is our core feature and we should continue to add things to enhance the social end of the experience.
Another person thinks that we should focus on e-commerce and distance learning. There are a lot of companies out there looking for ways to hold meetings or train employees without needing to spend hundreds of thousands of dollars flying people all over the world and putting them up in hotels.
For my part, I’m a big believer in making the software a tool for creativity and expression. I see a lot of our users are aspiring game designers. They create their own little world for people to visit and usually try to create some sort of Everquest-ish type experience. The tools aren’t quite there and it takes a lot of ugly hacks to make something playable, but it does kind of work. I’d like to see us expand the number of game-focused features. My direct boss – let’s call him Roger – is a gamer like me, and so he’s often on my side when our financials are good.
To be honest, I have no idea if it would have been a good fit for our software. I don’t know if it would have worked for us, but I feel sort of vindicated that it worked for somebody.
Some of these ideas come from one manager, and some from another manager, and some from our programmers who actually have a lot of power in the company. Meetings about future features – which I am only occasionally invited to attendAlthough Roger will sometimes champion an idea for me. – are often a tug-of-war between these different visions. Over the years, there’s been a lot of compromise. We see a lot of “I’ll support your feature if you support mine,” kind of deals. I think this is generally healthy, although it’s prevented us from embracing a single coherent vision. In the end, we’re sort of trying to be all things to all users. Our feature set is a mile wide but an inch deep.
Here is how we choose new features:
- We spend a couple of weeks having meetings to work out what our next set of features will be. Generally the early meetings are inclusive, but shrink down to just include the programmers and management as the feature list – called “The List™” – takes shape. These meetings will generally take place during the shake-out period for the previous release.
- A really big release can take the better part of a year to complete. (This happened last year when we FINALLY added support for hardware acceleration.) A smaller one can be completed in just six weeks. We generally stagger things between incremental and major releases. The more ambitious the planned version, the longer the meetings will go on.
- Once The List™ is finalized, the coders begin work on the next version.
- About halfway through, the coders will send out internal builds to people like me to get feedback.
- Around this time, a few unplanned features sneak onto The List. The coders might slip in an extra thing or two that they just really had their heart set on, or the bosses might force through something that they think will help them sell to a prospective client.
- Once most of the features are complete, we have an opt-in public beta.
- There are a couple of weeks of energetic bug-fixing and adjustments.
- As the beta stabilizes, the next round of meetings are held to decide on the next version of The List™.
Personally, I HATE the e-commerce / distance learning stuff. It’s dumb and boring and lame. One afternoon I’m standing in the aisle complaining about this when Roger takes me aside and explains that while the e-commerce stuff isn’t sexy, it’s actually an important revenue stream. Those business people might be boring and tedious to work with, but they have tons of money they’re willing to spend on this stuff. If it wasn’t for them, we wouldn’t be able to serve those aspiring game designers I love so much. The game designers are interesting people, but they’re broke as hell.
I slowly begin to realize why so few of my feature suggestions make it into The List™. I always argue for things in terms of how “cool” it will look and how intensely people want it, but I rarely make a business case for my ideas.
 Although they could also be a moron. It’s not unheard of.
 Although Roger will sometimes champion an idea for me.
What is Vulkan?
What is this Vulkan stuff? A graphics engine? A game engine? A new flavor of breakfast cereal? And how is it supposed to make PC games better?
Crysis 2 has basically the same plot as Half-Life 2. So why is one a classic and the other simply obnoxious and tiresome?
The Best of 2016
My picks for what was important, awesome, or worth talking about in 2016.
Punishing The Internet for Sharing
Why make millions on your video game when you could be making HUNDREDS on frivolous copyright claims?
Resident Evil 4
Who is this imbecile and why is he wandering around Europe unsupervised?