Archive for November, 2006

Giving hourly pay a shot

Tuesday, November 14th, 2006

One problem with my current business plan is that if I want things done faster, I have to hire more programmers, which costs more per month. In theory, (aside from diminishing returns), this would pay for itself anyway. Twice as expensive for half as long still costs the same amount. In practice, I have a feeling this isn’t going to be the case. One problem is that, before hiring someone, it’s hard to get a feel for how fast they are. If I have 6 months of work for myself, and hire 1 programmer, is it going to now take 3 months? Probably not. Maybe it will only take 5 months instead. Or 4. Or 7 because they take so much of my own time that overall productivity is lowered.

This is hard to budget and hard to schedule.

What is much easier to budget is if I attach a fixed maximum and minimum cost to each item on the schedule. I now know the absolute minimum and maximum the game will cost, as well as the longest it could take to get done. It also lets me hire more people with safety, because it just spreads out the same amount of money between more people, rather than costing more with no guarantee the job will get done faster anyway.

I know from personal experience I actually like this better, from both sides. When I was an hourly contractor, I didn’t feel compelled to work when I don’t want to. As a manager, I don’t feel I need to check up on the schedule anymore. Either the work gets done in time or not. As a matter of fact, I liked putting down my hours, because I was fast and I could show it. And I worked hard, and I liked the extra money I made.

To try to help this along I’m also attaching minimum hours to each assigment. If a worker can get something done faster than I could myself, and still be up to spec, they still get paid for those hours. It’s a bonus for being especially smart. The maximum is to prevent cost overruns, and wasted time on dead-ends.

This might cause a rush of half-way finished code to try to beat the requirement. Hopefully not, but if it does, no big deal. It just costs me a bit more time to day to review code.

I’ll see how it works over the next couple of weeks.

Got a dedicated server

Sunday, November 12th, 2006

While it’s a bit early, I went ahead with Hypernia.net and got a dedicated server for development. Mainly right now it will be for source control. The price is somewhat high, at $150 a month, but this means I no longer have the security and speed problems of using my own home computer. It also means certain kinds of work can be done more easily, such as writing the webpage and database stuff, since it can all be done on the server directly.

I briefly considered using Orcsweb for source control but god what a ripoff. They charge you full-price for a Vault license, when in practice the price goes down the more licenses you buy. Then they charge a per-developer montly ($40) and setup fee, ($20) when in fact there is no per-developer incremental cost to the host, aside from a trival amount of bandwidth. At 4 developers it’s already the same price as my dedicated server and all I’ve saved is the trouble of installing SQL Express and Vault. I’m not sure why anyone would use them.

Now I’m faced with trying to figure out how to setup all the web services, such as email, FTP, security, and web hosting. IIS isn’t that easy to figure out when combined with user security rights and database security rights. Hopefully I run across someone who already knows all this stuff.

Got a name for my game

Saturday, November 11th, 2006

Cosmic Strife.

No domain campers on the URL
Nothing else using it that I can see.
Matches my game
Easy on the ears.

Only potential problem is Sony has Cosmic Rift, which is a similar genre of game. But by the same token, Star Wars and Star Trek also differ only by one word, are both Sci-Fi movies, and there seems to be no problem there. Strife and Rift are totally different words as well so one couldn’t take that argument either.

Handheld development sucking bigtime

Friday, November 10th, 2006

I won’t specify which one, but I have a contract to work on a certain handheld and I have to say that working on it sucks bigtime.

1. Adding files requires editing a makefile.
2. Testing any changes requires running the makefile, then loading up an entirely different IDE, then waiting for the hardware to reset, and lastly running it (in total a 30 second process, as opposed to maybe 2 seconds to do the same thing in Visual Studio)
3. This different IDE is just aweful. First among the problems is that setting breakponits doesn’t work consistently. Sometimes it put the breakpoint on the wrong line, wrong file, and sometimes it doesn’t hit the breakpoint anyway.
4. Watches similarly don’t work right.

So I’m reduced to adding what amounts to printf lines and recompiling to try to guess why things don’t work.

Worse, the library has no documentation other than a few code comments in the headers. The comments themselves aren’t very helpful, with comments like
// Calls the Start routine for TRL
void StartTRL(void);

(Actual 3 letters changed but same scenario). What the hell is TRL? No idea. No where ever does it say what that abbreviation stands for. These kind of short abbreviations are all over the place too. In one case they abbreviated a 6 letter word to the first 3 letters, totally obscuring the meaning until had to ask someone else.

Furthermore, things just don’t work. For example, there is a connection routine which has to go through like 9 internal stages. It goes through 8 of them and then just sits there. Why? Who knows. Their sample works and I copy/pasted the relevant parts. My guess at this point is threading, because in another case if I add a delay it works, and with no delay it doesn’t get past an earlier stage.

I’m sorely tempted to just dump this contract immediately, because it’s wasting my time and taking time away from working on my own game.

How to motivate with challenging assigments

Monday, November 6th, 2006

I can’t remember the URL but I read an article a while back the work programmers hate the most is work that is random. Random work is work such as fixing other people’s bugs, trying to figure out other people’s code (esp. undocumented and/or difficult to test), and problems with no clear specifications, direction, and/or solution. This is why many programmers reinvent the wheel. Although it’s often a time loss to do so, it’s much preferable to solve a known problem with a known solution and make daily progress than guess at something that may or may not do what you want.

Probably after random work would be busywork, or work with no especial benefit or use. It’s not the work in this case but the lack of importance of what you are doing.

Conversely, programmers like challenges, especially when the challenge is important. This is why lead programmers work hard. They feel important (because they are responsible for important things), they are given challenging tasks, and the work they are given is usually time and mission critical. It’s not really because they make more money. It’s true that money attracts workers and it’s important to pay enough so that workers can live comfortably. However, what retains workers is rewarding work. Programmers enjoy working on interesting, important problems. Creating this enviroment will give you far better retention and enthusiasm than just paying more money.

The same task presented diferently can get different results. Saying to a senior graphics programmer “You have two weeks to write the grass waving system” is guranteed to demotivate and the first week will be spent on Slashdot, especially if it’s something they solved before with no new challenges. Saying to a junior graphics programmer, or a non-graphics programer, “You have 3 days to do the grass waving system. Here are some resources to get you started” will be an exciting challenge with an opportunity to learn, especially with someone more senior available to ask questions of. No deadlines, or deadlines too long, is just as bad as deadlines that are too short. Deadlines present a challenge to get the work done in time, which motivates one to work.

This is why I try, when giving assignments, to remove as much guesswork as possible with clear specifications, descriptions of intermediate steps, and a justification as to why the assignment is important. It’s very important to be able to provide a constant line of communication, help, and answers to people working. Not doing so leads to guesswork, which is random, and hence annoying and demoralizing.

Incidentally, it’s also why I’ve finally figured out why I hate a new contract I took so much. It pays very well. Until today I couldn’t understand why I would feel literally sick to my stomach to work on it. I was assigned to create a facade design pattern to undocumented spaghetti code, on a platform I never used before, with little communication or support, using primitive tools. On top of that, when I do ask questions, I’m ignored half the time, making me feel I am not important. The work is essentially random – spend a lot of time to make a guess, repeat, until I figure out the system, then write the facade. In the end, it may not work anyway. It drains away my enthusiasm to work at all, including on my own game.

Got a new programmer, but perhaps not enough

Monday, November 6th, 2006

Funny how things work out. I contacted the contractor MIA and he just quit voluntarily. Then I had a mid-level programmer apply suddenly and get hired pretty much the same day.

Looks like about 6 months of full-time work left if I were to do the whole game by myself. I think the mid-level programmer can cut that down by 1-2 months, and the junior programmer possibly by 1 month. The graphics programmer might save some time if he finishes the effects early and helps implement the effects in gameplay. It would probably average out to 3-4 more months of programming, less the week already spent.

One thing I’m worried about is that simply finishing the game in 4 months is only a part of the whole process. Ramping up from 1-2 people during development to supporting 10,000 players is definitely non-trivial. Another thing is that good gameplay never comes out of a closed cycle. Only through beta testing, iteration, and feedback from the community. In the optimal situation, I would sit on the game in closed beta for 6 months. I have a suspicion that is going to happen anyway. There’s no point to releasing before the game is saleable. But that’s a bad thing, since it will essentially double the development cost. It’s going to be tough to figure that one out.

Need mid-level to senior people

Sunday, November 5th, 2006

My original plan for programming was to do most of the game work myself and have some junior programmers help me out to make things go quicker and take care of the small details.

This actually wasn’t a very good plan, because as I fill out the schedule I find that tasks can be categorized by the skill level of the programmer needed to do them correctly. Some tasks can only be done by me, some by any senior programmer, some by any programmer with gameplay experience, and some by junior programmers. My original schedule was to take the raw total hours, divide by 4 (the number of programmers) and figure out how many months that is. But that won’t work because most of the tasks are senior to mid-level, meaning with the people I have right now only I can do it correctly, meaning that I’ll never finish in the 3 months allotted.

This wasn’t total naivety so much as that I had never worked with any truly junior programmers before until now. When I thought junior I thought of my own skill out of college, which actually was mid-level. So in essence, the programmers I hired up to this point, except the lead programmer, aren’t really going to speed up the schedule.

The smart thing to do at this point would be to dump one of the junior programmers and hire 1 senior programmer and possibly 1 mid-level programmer. I’m not so cold-hearted as to just fire a junior programmer for no reason and will just go over-budget if I have to. However, the problem may resolve itself naturally.

Another contractor MIA?

Saturday, November 4th, 2006

This might be premature but I’m getting nervous about the second contractor I hired. Other than an hour or so the first day, he’s been missing in action (about 3 1/2 days now). About a day and a half ago I sent him an email he didn’t reply to either. Normally I would not care if a contractor was offline for as long as two weeks. As long as they get their work done in the end that is fine. But for someone who just started I’m not sure how they will work out yet. To simply disappear makes me wonder if they are working, if they decided they just don’t like the job, if they are having computer problems, or what. I made a mistake in giving him his first task with a duration of two weeks. If I knew his work ethic it would be OK but for all I know he could wait until 2-3 days before the deadline and then start, doing the work at the level of quality that would take 2-3 days to do, rather than 14 days needed.

I might be totally off my rocker here. Perhaps his internet is down, he is only online when I am sleeping, simply has no questions, didn’t think a response was required from my last email, and/or is planning to crunch his time on the weekend. I got the impression he was very professional during the interview so I feel a little more confident because of that.

In any case, I have a lot more appreciation for the difficulty of putting together a good team. It takes time, money, and skill to find the really good people.

First firing

Friday, November 3rd, 2006

I’m feeling really bad because the first contractor I hired for my company is turning out to be untrainable. I have no recourse at this point but to fire him and find someone else. Part of me feels shamed for taking this guy away from his current job and then having to fire him right away. Part of me embarrassed – how crappy of an interviewer can I be to hire someone like this?

The straw that broke the camel’s back was when after 4 days of just trying to build the game, he told me yet again that it wouldn’t run because of missing DLLs. I’ve told him to copy the DLLs at least 5 times, and have walked him through that exact problem twice already. Honestly, I shouldn’t have had to tell him at all. The game is still in its infancy, there aren’t that many directories, and if you were to just open the 3rdParty directory you would see a DLL directory right there. So I told him “Copy the DLLs from c:\engine\dlls to your game directory” He said it still wouldn’t run with the same missing DLL problem. So I told him where to click, how to load a DOS prompt, what to type, how to copy/paste from the DOS prompt, and to give me the output of the dir command on that directory. Sure enough, the DLLs were not there. I got exasperated and (still politely) asked him if he really had the two years of experience he claimed during his interview, because one of those years he claimed was on Windows and even non-programmers should understand how to copy files, especially if told the same thing 5 times over 4 days, even including written setup instructions.

Earlier that same day he complained to me that he didn’t have permissions to check out files when I asked him to download the latest from source control. He didn’t have permission because two days ago I had to remove his permissions because he kept checking out the entire source tree exclusively. Eventually, although it took 4 days, I realized he didn’t understand the meaning of check-in, check-out, get latest, etc. He didn’t know how to use source control and never bothered looking up the terminology or reading the help, despite the lead programmer and I telling him 5 times to stop doing exclusive checkouts. I mean come on, if someone is telling you over and over not to do something, and you don’t understand the words they are using, maybe it makes sense to ask or to look it up. The information is out there.

After writing all that I feel annoyed enough I’m not so shamed anymore. I think the reason I hired him is because he was still so much better than the other 700 candidates before him. Even quartz looks good to a diamond hunter if they are in a coal mine. At least he could sort-of speak English, could sort-of answer questions, and claimed 2 years of experience. Because of the last point, I gave him the benefit of the doubt, which turned out to be wrong.

One on hand I could say the lesson I’ve learned is to be a hardass and to reject anyone at the slightest hint they might not be suitable. But that’s not really the case – for example my lead programmer is great and yet I didn’t get an overwhelming feeling of how good he was during the interview. It was too hard to understand him so I couldn’t cover technical questions very well. It’s questionable if I would have hired him for lead programmer if I didn’t give some benefit of the doubt. Maybe the lesson to learn here is when hiring in foreign countries, it’s best to have someone there on-site to help you, because without an understanding of the culture, language, and technical terminology they use (including degrees) it’s hard to judge talent.

Got a great lead programmer

Thursday, November 2nd, 2006

On the very last day of hiring I got a job application from someone who claimed to be a lead at nVidia. The interview went well and while he was a little hard to understand, I was really impressed by his motivation and his resume. So I gave it a shot, even though he was 3X more expensive than my other programmers.

It turns out this was the best decision I’ve made so far for the company. He is professional, knowledgeable, and incredibly helpful. I now have a resource to turn to ask about about India and Indian resumes and have a good feeling that even though I am not working, progress is still being made on the game.

I can see now that my previous attempts to save money by hiring juniors may have been a mistake. 3X the cost but 10X the productivity is a good deal as far as I’m concerned. If I could do it again I would have skipped hiring juniors and had gotten 2 people with experience instead.

I may have to restart the hiring process, which will delay the game by a month, but it’s better that than failing entirely. I asked the lead programmer if he knew anyone else as good as him looking for a job but unfortunately he didn’t.