Best Practices, Part 2

Put an actual best practice in the comment thread. Doesn’t have to be gaming related. And if you can find it in a fortune cookie, I swear I’ll delete you. In other words, no “plan time to plan.” Just once, I want to see an actual list of best practices.

I’ll start. If a regular status meeting (not a planning meeting, not a design meeting, just your weekly touch base meeting) takes more than sixty minutes, you are doing it wrong. Possible causes:

– Too many people are invited. Managers of other people should be taking notes and passing on the information, and if they are not and you find yourself including someone’s minion just to be sure the team is informed, make the minion into the manager. It can be that simple, if you’re willing to use your balls instead of playing with them.

– The attendees feel that this meeting is their only chance to be heard. If people feel like their ideas don’t count unless they are spoken aloud in a roomful of people, you have a leadership problem, and/or your people are not using the CC function on email correctly. Provide faster written, public feedback throughout the week.

– It is straying off topic. Write down an agenda and stick with it.

– It is being hijacked by someone who is showing off. Do not reward this behavior with your attention. Disinvite extreme cases from the meeting.



  1. June 30, 2008 at 9:54 pm

    Here’s an easy one, that I have still seen a lot of people not do: eat your own dog food. If you’re making games, play games. Not just any game, either: play your game. If you don’t enjoy it, something’s wrong. Fix it, and keep playing.

    There are times when this is difficult, especially in other parts of the tech industry. However, if you make a product for end users in any way, then you should also use it. It’s not a great way to know that you’re making a quality product, but it’s a very effective path to finding out what sucks for your users.

  2. Dragoness Eclectic said,

    July 1, 2008 at 12:23 am

    If you’re programming ANYTHING–games, DOD projects, consumer electronics firmware, these things will help keep the gremlins at bay:

    – A company/project programming standard or style guide that is actually used. This should include a documentation/commenting standard, so that code is documented AS IT IS WRITTEN. … because no one ever goes back to document stuff later unless forced at gunpoint.

    – A well-understood procedure for making and testing builds, merging new code into the working code-base, and confirming that it’s ready for release.

    – Version control/configuration management. You’re sunk without this. Even if management doesn’t want to pay for it, you can still install Subversion for free.

    – An evil harpy of a Configuration Manager who refuses to let developers check untested code or known-buggy code into the Release branch.

    – Automated testing. The time spent in the beginning to set up automated test harnesses for your integration and regression testing will more than pay for itself in ‘surprises’ caught by tests that wouldn’t otherwise have been run because everyone is too busy to do (seemingly) low-priority, tedious manual testing.

    – An automatic documentation generator, e.g. javadoc or doxygen. If your standard (mentioned above) includes comment tags for the automatic documenter thingy, you can generate much useful documentation with one simple command. You’re much more likely to have up-to-date (or any at all) documentation if someone can generate it at the push of a button vs. typing it up manually.

  3. Dragoness Eclectic said,

    July 1, 2008 at 12:25 am

    Forgot one other important thing:

    – some kind of bug tracking system that is easy enough to use that your developers and customers will actually use it.

  4. Brask Mumei said,

    July 1, 2008 at 12:34 am

    Dragoness grabbed the best practices I was thinking of.

    I will underline and circle version control.

    Version control is not just for code. It is for everything.

    The best time to fix a bug is when it is written. This is why automated testing is so powerful – but note that it requires that things that fail the automated testing are fixed immediately. It is too easy to let them slide for a month or two at which point you might as well not have the automated testing system.

    If an employee needs more than eight hours a day to get their work done, one of two things are true. Either they are incompetent or their manager is. Crunch time is a myth generated by macho men seeking to prove how tough they are. Whenever I here stories of crunch time, what is the problem usually keeping people in late working bleary eyed at the last minute? Fixing bugs. Why are there so many bugs? Because code was written by people working late and bleary eyed. If excessive work makes people unreliable to screw in bolts on an assembly line, why would we think for a second that it could work when juggling hundreds of thousands of lines of code?

    The biggest threat to software projects is that it is really easy to write code, but the long term goal must be to have as little code as possible. Every line of code is another bug and another dead weight on maintenance and flexibility. Systems that slow down code writing are thus useful – such as automated tests that must be passed and written, etc.

  5. Kevin Klinemeier said,

    July 1, 2008 at 1:43 am

    Have ONE list of things that need to be done by your team and do things in this order.

    On a list item, describe what needs doing, and WHY it needs doing.

    Listen to your team when they tell you the “what” doesn’t match the “why”.

  6. Servitor said,

    July 1, 2008 at 3:32 am

    Listen to the naysayers on your team and don’t automatically dismiss them as having a negative attitude. Yes, there are people who shoot ideas down willy nilly for dumb reasons. However, if you write off those who will tell you when they think something is off the mark, you’ll eventually surround yourself with yes men, which is something managers and leaders always claim they would never do. It tends to end up like this (although this is fictional):

  7. Trevel said,

    July 1, 2008 at 3:39 am

    “Requirements” is NOT an entry-level position. If you have bad requirements, your entire project is doomed to failure. If you treat requirements as a bothersome step that has to be done before the ‘real work’ begins, your entire project is doomed to failure. Get good requirements. Get good requirement people. Don’t start coding until you know what you’re building and who you’re building it for.

    (This is especially important in Waterfall design, which has no provisions to handle bad requirements, and should not be used anyways. Iterative methodologies that maximize communication with the customer have much better coping skills.)

  8. Joe Ludwig said,

    July 1, 2008 at 4:25 am

    * Have a one-button build process and run it every single day.
    * Require a code review of every code checkin.
    * Give your users at least 24 hours of notice before any downtime (and preferably 72 hours of notice.)
    * Don’t push patches on a Friday.
    * Don’t make humans write serialization code.
    * Don’t schedule the programmers for anything in the month after launch.

  9. Brandon said,

    July 1, 2008 at 4:31 am

    ““Requirements” is NOT an entry-level position”

    At my shop, Requirements Analysts are required to have an engineering bachelor’s degree…

    “* Require a code review of every code checkin.”

    … and, along with the QA folks and at least several other programmers, are required to be present at code reviews.

    Helps a lot in reducing the error rate, and they’ve tracked this stuff for years.

  10. UnSub said,

    July 1, 2008 at 5:41 am

    Some best practises that can be generally applied to organisations, not just MMOs –

    * Management should take everyone out for nothing more than coffee and cake / lunch every so often. Not team building exercises, not strategic planning sesssions, just feed them as a group. It helps build up some sense that you are working as part of a group and that management isn’t completely uncaring. If it costs the company a $1 000 bar tab, but stops people from burning out, it is worth the money.

    * Only critical events should stop people from attending internal meetings – this applies double to management. If people get into the habit of blowing off internal meetings (which shouldn’t be frivolous events, obviously) just because they are busy, you end up with people not knowing what is going on in a complex environment.

    * Underpromise and overdeliver. That’s almost a fortune cookie saying, but it’s better to say you’ll be delivering X and Y by a set date and then deliver X, Y and Z than promising Z only to have to cut it. This applies internally and externally. Say ‘no’ when you know it is the right thing to do.

    * Launching the product is only the start of the relationship between you and your customer. You need to be ready to deal with them, hopefully over a long period of time. Hire the right people to deal with them.

  11. Alexis said,

    July 1, 2008 at 8:09 am

    I’m sure some of these will seem naive or cookie-obvious. Maybe a different few to each reader.

    Read books. The Pragmatic Programmer, Mythical Man Month, Refactoring. Learn a new language, methodology or framework every quarter.

    Cycle people, don’t let them overspecialise or silo. You’ll get broader more useful employees. Their CVs will look nice, which should compensate for the extra challenge. Maintainability will be closer to the hearts of every developer. Consider how resilient your schedule is to a double-decker (“bus impedance”).

    Overtime takes a toll. After eight hours you are not doing your best work. An overtime culture will cause employee throughput, fragmented design and many bugs reaching production. I bet Tseric put a lot of hours in. Having said that, a release push won’t kill you. Just not constantly.

    Users are great at describing problems, not always so great at picking solutions (not that you should ignore those). Listen, bring in requirements, write usecases, iterate, run the tests, release, reexamine. Anyone should envy Blizzard the Elitist Jerks forum.

    Admit mistakes. Confirmation bias is the root of evil. Identify the drivers and facts, don’t allow elegance as a driver but do allow maintainability and flexibiliity.
    Tackle risk early, do design carefully but don’t gold plate. Identify the most likely causes of change and allow for those, instead of making the most general solution possible.

    Keep people motivate through attention and constructive feedback. Bored/frustrated people cause problems, responsibility can transform them.
    Keep visibility through the management chain, ensure those you lead understand your drivers clearly.
    When appropriate, praise employees cc your manager. Help overcome challenges privately.
    Ask employees to mail you about their successes or those who especially helped them and keep a record.

    Don’t use stack ranking for more than two years.

  12. Heather M said,

    July 1, 2008 at 1:05 pm

    Colocate your teams. Nothing sucks worse than having 2 team members over in one set of cubicles, 2 more in another set on the other side of the floor, and the team lead in his own office one floor up. Make the team lead sit in a cube with his team, and put everybody clustered together. If you have the space, make “war rooms” where everybody has their desks clustered together in a large office.

    Every single time I’ve gone to my manager and asked him to do this for my team, our communication has increased tenfold. Better communication = better quality. Also you get more knowledge share so that if the guy who knows everything about system A suddenly gets hit by a bus, the rest of the team isn’t SOL.

  13. Michael said,

    July 1, 2008 at 2:16 pm

    – Humans have to have some sort of contextual input to make rational decisions. IE: Don’t make important decisions over text/IM. If you think something is important, it’s worth schlepping to another dude’s office/cube to have a 2-minute chat. Alternatively, call them on the phone. That 2-minute chat could save you weeks of misunderstandings, bad feelings, and frustrated emails.

    – Conversely, it doesn’t matter how minor the block of text is: if an enduser is going to see something written by the project team, it needs to be edited. One poorly written help document or (in the case of MMOs) incomprehensible quest text can trash your reputation with a certain kind of user.

  14. pharniel said,

    July 1, 2008 at 3:03 pm

    Mine are mostly from a support standpoint (maintenence and development of continously in use products):

    i’ll modify no pathes on friday to ‘no patches when the full support team will not be available that and the next day’
    mostly because i’ve been one of three people on duty after the ‘insignificant’ patch broke *everything* and of course no one was on standby

    The only metric that counts for the bug / support group is how many cases they are incoming and how long it takes to fix them. Determine a turn around time and staff accordingly, do not allow staff to dictate turn around time.
    this is how you get urgent issues open for two months and pissed off customers.

    if you have a cyclic call cycle (more during certian periods less during others) plan ahead and train a consistant level of staff that can be ported over to QA or other duties. There is nothing worse that bobbing head count, by the time you train up all those new heads for the next influx of calls you’ll already on the downturn.

  15. Stupid said,

    July 1, 2008 at 4:06 pm

    Invest time to develop standards. Spend a day up front to get everyone on the project working on the same page. As the project develops and runs its course, fewer people will waste time on moving in a direction that may not be productive (or, even worse, in a direction that is counter-productive).

    Follow the standards that have been developed. Even if you think they don’t make sense. Those standards were not implemented to make your life a living hell, they were put in place to make it easier for others to work with you. (Exception: if the standards are making your life a living hell, do something about it! Standards are not immutable.)

  16. ReptileHouse said,

    July 1, 2008 at 4:36 pm


    Hire smart people. Really smart. Not “got good grades” or “got good test scores” type smart, but “holy crap, this person is fucking brilliant” type smart. The ones that when you interview them, impress the hell out of you with a sense of really grokking what’s going on. That said, apply some common sense. Brilliant with the personality of a wet paper bag when the paper bag is having a good day is not usually the sort you’re looking for.

    Involve the team in the interview process. As important as raw talent is the ability to get along with the rest of the team. The best way to understand what it means for your team is also the easiest. Get the candidates involved with the team. Let them talk to each another one on one. Even just half an hour or 45 minutes does wonders. Your team will be involved and vested in the process, and therefore the outcome, and you’ll be more confident that the person you hire will fit in and be able to contribute.

    Be patient when looking for those people. Do NOT hire someone just because you’ve had the open position for a while and your boss is breathing down your neck to stop interviewing and just hire someone already. It is almost always far worse to hire the wrong person than it is to not hire anyone.

    Have managers who know how to deal with very smart people. They’re different. Idiosyncratic. Sometimes downright odd. It takes a lot of skill to recognize which quirks are harmless and which ones should result in some coaching to help smooth out.

  17. Rawrasaur said,

    July 1, 2008 at 6:49 pm

    Prototype early and prototype often. You usually do not need production-level art assets to figure out if something is fun or not. If it requires that level of commitment and resource to make something worthwhile, it should be the main focus of the game. Building early prototypes to model gameplay with placeholder assets should be a must-do. If you can make it fun with basic code, geometry and assets, it will carry over to the finished product. You should not expect to ‘find fun’ along the way, it should be there to start with.

    Finalize core game systems before production. There’s nothing worse than having to hack/redesign a level or make it inconsistent with the others because you did not finalize core game systems (moving, attacking, etc.) before building the level. This ties in directly with the above point about prototyping.


  18. Inhibitor said,

    July 1, 2008 at 10:29 pm

    Here’s one taught to me by my dear old dad…it’s basic, and it’s incredible just how often it’s NOT followed.

    If you are in a leadership position, never ask those below you to do anything you’re not willing to do, and prove it by showing them at every opportunity.

    Let’s face it…if you have people working under you, they’re going to gripe about you; that’s just part of being human. However, if you walk in and say “Okay, we have to pull an extra eight hours today to get this right; go team!” and then disappear for seven hours, the grumbling will have an entirely different tone, which will be symptomatic of a problem; when you do this, the people you’re leading will start to question every call you make, at least subconsciously. They’ll ask themselves “If it’s so damn important that we do this, why aren’t YOU here?”

    Ask your team to work, and then work right along with them. Let them know that it’s not just a whim passed from above…it’s important, it has to be done, and you’re willing to work just as hard as you’re asking them to.

    (I could have just said “Lead from the front,” but Sanya would have deleted me, and I just got this shirt cleaned.)

    By way of example; my aforementioned father. He’s a career law enforcement officer. He retired as the chief of our state patrol (“state police” for some of you), and has been the Chief of Police of our town for 14 years. When he sends his guys on a drug raid at 3 in the morning, he’s the second person to enter the building (behind the guy with the battering ram). His officers have remarked to me more than once that they would “crawl through hell for that man”.

    He’ll be 70 in March, so the rest of us have no excuse.

    I try to manage using that philosophy every day, as many do. But it still amazes me how many don’t “get it”.

  19. Kirel Redhand said,

    July 1, 2008 at 10:59 pm

    As a Software Configuration Management guy (ClearCase/UCM/ClearQuest) who’se been doing this for the past 10 years… Here are some best practices that we enforce.

    *) Developers will be responsible for merging code from the Project branches into the Integration branch and any other active Project branch.
    Assurance: This will ensure that the creators of the code resolve any merge conflicts.
    Enforcement: The developer(s) working on a Project branch will be responsible for ensuring that all code has been merged to the Integration branch prior to release integration.

    *) There will be only one Integration branch per release.
    Assurance: This policy will ensure that the project work is integrated into only one release.
    Enforcement: This policy will be enforced through the cspec. A project branch will be created off of its corresponding integration branch.

    *) Lagging project work based on one release baseline and scheduled for a future release will be merged into the appropriate Integration branch.
    Assurance: This will enable project work to start regardless of what release integration branch is currently active,
    Enforcement: Named Integrator(s) is responsible for ensuring that all Project branches scheduled to be included into a release have been merged to the Integration branch prior to a release.

    *) Releases into QA/PreProd/Prod will be done off of the Integration branch.
    Assurance: This policy will ensure that the main line reflects the Production version history.
    Enforcement: This policy will be enforced onto the integration branch upon Dev Checkout.

    *) Patches and Fixes will be done on a Project branch.
    Assurance: If patches/fixes are necessary the work will be done off of the integration branch. This policy ensures that the patch/fix work is done separately from project work.
    Enforcement:This policy will be enforced through the cspec. A project branch will automatically be created off of the integration branch.

    Always use good version control. Note: VSS is not good version control!
    Implement a well thought out bug tracking system that identifies not only the specific verison of the release that the bug was found in but also allows you to identify the specific versions between the last known good version and the offending version.
    Label each milestone so that you can “go back in time” should you really screw something up.

    Waterfall development is for amatuers.

  20. Calaruis said,

    July 1, 2008 at 11:45 pm

    Provide the materials used in the classic RTFM. No, really, document. Document everything, even if it seems unimportant. Someone someday is going to ask a question about it, and it will look good to already have the answer in hand.

  21. Kelryck said,

    July 2, 2008 at 2:37 am


    Don’t allow team members or reviewers to be able to get off with an “It sucks” or “It’s bad” comment without explaining how or why they feel that way.

    Even better is a process I used with my project teams in the commercial environment – No bitching, moaning, or complaining about something UNLESS you also provide a potential solution or fix for said problem. It forces people to dig into the problems a bit more and sometimes you get elegant or incredible solutions out of the blue the original designer/concept person didn’t think of.

    If you reward good comments/constructive criticism, then you tend to get batter, more thoughtful comments and suggestions as well. (and the reward could be some added time off, a coupon for lunch at a local restaurant, etc.)

  22. TPRJones said,

    July 2, 2008 at 7:22 am

    When the third set of consultants tell you the same thing – specifically that the entire upper management of the company must be replaced – don’t just put out bids for a fourth set of consultants.

  23. pharniel said,

    July 2, 2008 at 7:06 pm

    @ 22 – but that would mean that the people writing the checks are the problem, not the minions who are secretly sabatogeing the investers in the back, no really, arn’t?

    we can’t have that. (i see you’ve been on the same cruise i have)

  24. goemagog said,

    July 2, 2008 at 11:14 pm

    best practices?

    don’t take milton’s stapler or he might set the building on fire.

    Goe, reminding you that it’s the red one.

  25. Merlyn said,

    July 3, 2008 at 12:01 am

    Geez…programming best practices, gaming best practices…

    How about the most basic one?

    Take care of the customer. They’re the ones paying your checks (in the end) and they’re the ones you have to make happy.

    If they have a problem, resolve it as quickly, and as accurately as you can.

    Be polite, be concise, and don’t patronize your customers. Treat them how you want to be treated, and don’t ever, ever lie to them. They will find out.

    If you make a mistake, admit it, correct it, and explain as best you can. Cover ups will be detected, and will blow up in your face.

    Finally, don’t be scared of telling a customer “no.” Sometimes, you just can’t accommodate them, and if you don’t pussy-foot around, and just tell them up front, they’ll understand and respect you.

    (Yes, I work in support…and I’ve yet to have a customer get mad at me…mad at the product I’m supporting or the company I work for, but not at me.)

  26. goemagog said,

    July 4, 2008 at 3:59 pm

    “realistic expectations”.

    and fire.

    and boobies.

    and our lovely hostess, Sanya.

    Goe, going to see fireworks tonight.

  27. Echo said,

    July 6, 2008 at 6:45 am

    Everyone is smart, everyone is stupid.

    Never assume that anyone is the same kind of smart that you are, and NEVER assume that they are the same kind of stupid.

    No matter how efficient, how brilliant or how driven to produce your guy is…NEVER make him the only person in the development loop.

    She might be producing 60% of your code, but one set of assumptions not common to the user base and BOOM!

  28. fsanch said,

    July 6, 2008 at 12:49 pm

    I have three:

    -The worst thing you can say to your team after receiving management direction is “I know it sucks, but…”.
    Congratulations, you’ve just screwed up your company unity, because your team will now have an attitude of rebellion you’ve indirectly endorsed. What you should say is, “If you disagree with this, pass me your concerns and I will take them up the chain”.

    -Manage expectations about a project up front.
    Projects can get fucked because people didn’t know how to handle an issue or what they were supposed to be doing. Go through an exercise to establish your purpose, vision, and brainstorm some ideas to get there. Organize them, and your team, and come up with some action items. This essentially manages expectations and puts everyone on the same page.

    -Flex your approach.
    Got a worker who values organization? Be overly organized for your meeting with them. Got someone who is easily emotionally affected by their work? Give them praise when they do well. Got a boss who is all about the bottom line? Limit your meetings to no more than 15 minutes. Flex your approach to the people you are dealing with, and you will have a much easier time than trying to ram the way you do things down people’s throats.

  29. Matennon said,

    July 6, 2008 at 10:09 pm

    – Praise in pubic, criticize in private. Nothing will turn a subordinate against you faster than chastising him/her in front of others, most especially if they are HIS subordinates! This is also true if you feel the need to take issue with someone higher up in your chain of command.

  30. Chris said,

    July 8, 2008 at 10:19 pm

    Every single day shaved off initial design/coding is one more day added to QA. Reduce scope before reducing time in your schedule.

  31. Kennedy said,

    July 12, 2008 at 4:32 am

    My best practice is to remind my P&L owners and my sales guys that our people and our product are valuable, so in negotiations, value our concessions. Don’t give anything away for free; there must be quid pro quo, even if it is small.

  32. Brian said,

    July 18, 2008 at 6:16 pm

    Here’s a network related concept that I’ve had to suffer through.

    If you can reduce your expenses by 50% by changing to a newer network, but it doesn’t actually perform all the tasks your employees need, you didn’t actually save money.

    More simply: “Newer isn’t always better”.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: