Lessons Learned

Lessons Learned at Netdevil

Reasons Jumpgate is Failing

Netdevil's employees and "corporate culture" are grossly unprofessional.
There is no coherent design or even consistency in feature choices for the game.
There have been essentially no recent marketing efforts.
There is no real willingness to listen to, or even interest in, the players' needs and wants.
The organizations responsible for support and development are unable to work together or even communicate effectively.
The code is very messy and non-OO, making any changes extremely bug-prone.

Corollaries to #1:

There is no commitment of resources from Netdevil to promote the game's success.
There is no project management.
The "team lead" responsible has zero professional maturity.

Corollary to #5:

There is actual animosity between Netdevil and the support organizations. The feeling is somewhat mutual.

Corollaries to #6:

All changes to the code take more time than expected, due to unexpected duplications and redundancies.
There is no central database for game info - much of the data is scattered in actual code files, often redundantly, with different copies used by different processes.
The game's appearance and features have become dated because evolution of the code takes too long.

I'm watching a train wreck in slow motion. I think I boarded far too late to do much about it, though I'm trying. The engineer's uniform I wear is something of a farce.

I'm working intensely with the other two organizations (the support org for US, and the owners/supporters/maintainers in EU) to build bridges and foster better communication. That's working, except as the juniormost person at Netdevil, I can't actually make binding decisions or make many real commitments to the other organizations. However, their supervisors have expressed appreciation that I talk to and listen to them.

I have limited code access. Supposedly we're in a great hurry to finish Episode 2. I understand, given that we are under such time pressure, that having the new guy muck about in the code might cause problems for the real coder who's getting work done. However, it's been three months, Episode 2 is now nine months late, and the real coder probably codes four hours a day - mostly at night from home after playing games and watching videos in the office.

The code really is a mess. It's a laundry list of everything I was told never to do in my C++ classes. Global variables, structs instead of classes, code in header files, and #defines all over the place instead of const. I don't think there's a single const in the code, actually. Obviously a garage project grown completely out of control. Suggesting revisions gets laughed at on two grounds: (1) Disciplined OO code is considered to "cause trouble when writing more code because you can't manipulate anything you want" (no shit, that's the freaking point). (2) Rewriting anything takes time away from producing features visible to the users. The second point is halfway to a valid argument. Too bad the users have seen no new features for nine months and counting... because coding anything takes too long and creates tons of unexpected bugs....

The two senior members of the team are, not to put too fine a point on it, kids. Both under 24. No prior professional experience to speak of. Neither have much enthusiasm for the game, and appear to look upon it as a boring chore. The artist is less than half-time, and getting him to do anything for Jumpgate is very difficult and results in anger reactions. He spends most of his time working on the company's newer project. The coder is effectively responsible for the game. He's been instructed by the person who should be managing that he's in charge, because the supposed real manager is completely engrossed in the company's new project (for which Netdevil is actually getting paid, and represents the only reason the company is afloat - not unreasonable logic). This person had been running things solo for nearly a year. I was hired to assist him, and apparently in the hope that my 'enthusiasm' would help. Well, enthusiasm alone, without power to change things or make decisions - and I'm talking about the game, not about the business - is pretty useless. The team desperately needs a manager. Looking about myself, I feel competent to do it. Unfortunately, I seriously doubt even if I were magically put in charge, that the kids would follow instructions. I've already watched the lead coder ignore the "real boss" for a week and a half - when the boss has simply been asking for a test build (which we produce anyway every other day) to be sent to the EU team. EU has asked him for one three times in the last two weeks - I know, because they blind-copy me their emails (because I WRITE BACK). They are making business decisions (imagine!) on the basis of when this thing is going to release, so they want an evaluation copy to see what we've been doing.

I see an employee ignoring instructions from his manager. Will there be a reaction? Nope. The "boss" is a nice guy, and doesn't want his company to be like working for a big company.

I'm hoping that this "History of a Game that Failed" (to paraphrase Twain) is of use to the Spooky Distance team in two ways: a friendly reminder to never let a project get this bad, and encouragement - a little planning and professionalism can succeed. Remember, Jumpgate had a very successful initial release. Imagine if the game had been marketed, and supported in a professional manner, after release. It might be turning a small profit, with several more FTEs working on it. Frankly, it still could be a success, with a little will, and a little real work.

Food for thought, I hope. I've kept some of this general, though no doubt folks familiar with Jumpgate could quickly recognize the key parties mentioned. Please do not repeat this. It's here largely as therapy for me - I'm going to ride this one all the way, no matter how insanely frustrated I get, because it's good experience.

DWM Terribly sorry to hear most of this, Istvan. Sadly, in small companies, it seems that things can either be great or terrible, but rarely anything in between, and few alternatives for getting things done when a key person or two poses a stumbling block. It must be frustrating as all hell. Stick to your guns and I don't doubt that eventually you'll be in a position to set the kids straight -- or jettison them. That's if a better opportunity doesn't happen along -- keep those eyes peeled.

DJH "keep those eyes peeled" - Definitely. There will likely come a point in time where the benefits of learning from the team's errors will no longer outweigh the drawbacks of staying in the environment (not getting the coding experience you need, going beyond the frustration threshold such that you implode, etc.). Temper your detection of having reached the final destination (having "ridden it all the way") so that you're not caught in the carnage when the train hits the wall. Continue to nurture your relationships with the other organizations; they may provide escape routes when the time is right, or serve as references that can vouch for your professional attitude and work ethic.

JDH Fascinating reading - thank you for sharing. Perhaps you could lobby for a position on the new project - and have more of a chance of making some positive changes there? BTW, sometimes the pieces of code in the worst shape offer the best opportunity for a developer to shine (I have some experience with this scenario! like my last 3 major projects (I hasten to add just the parts I was involved in not the whole products))

Istvan Thank you all for your positive comments. I'm sorry I haven't visited recently or read them sooner. I actually have some marginally good news: things aren't as black as they were when I wrote the above material. Ep2 released, I'm writing code, my push for better communication has borne some fruit. It's mostly that I'm now feeling less powerless these days. Sure, it's still a train wreck, but I'm learning what I can and riding the ride. I have my fingers in the code a lot more, and I'm learning .. well, I'm learing how to manipulate my coworkers gently into doing things that I think need doing. It's slow going, and it doesn't usually work, but the small victories happen often enough that I really can say that I don't dislike my job, just a few things about it. Heck, if I can get the guy I called "the coder", above, to work more than four hours a day, we could even start to turn the train wreck around. Well, maybe.

Addendum 7/15/03: Things are still looking marginally positive, in that there's no reason for me to be wanting a different job for now. Jumpgate is still slowly dying, but I am into the code all the time now, and learning many things. Several of my efforts in terms of building bridges and improving relationships have borne fruit, so I've been pleased to see good things happening like that. Also, I want to make note that while I was not under a written NDA at the time I wrote the above material here, the management has since bothered to get that paperwork in place for all employees. Please keep the information above completely confidential within the SDx group, and I must consider seriously whether to revise or remove all or part of it. If this site were not under password protection and fairly secure, I'd have to remove most of it at once or risk losing my job.