Big vs Small

During day time, I work for a rather large company. When I'm done work and finally get home, I have a few hours of play with the family and then move on to work for myself. The difference between working for a Big Company and for yourself is extreme. The company I work for employs about 400 people or so. There's multitudes of games being developed in parallel for many markets, all with their different rules and regulations. We have game designers, artists, programmers, QA, integration engineers and delivery managers (this is equivalent of a producer). Add to that managers for each of those groups and probably managers to manage them and you got lots of people working on intertwined projects.

Then I come home, and I'm the manager, designer, programmer, QA and on some occasion, artists *shudder*. That last role is a bit scary...I have no artistic bones in my body except for a bit of photography.

I don't mind day time work; sometimes I can truly find a lot of fun in it. After I'm done filling all my TPS reports that is. I find the overhead of doing things when you are in big groups a bit frustrating. Things are normally very simple, but put a simple problem in a large group and all of a sudden, it becomes really complicated. Politics, egos they don't really play a big role when you are developing by yourself.

Deadlines are probably some of the most frustrating element to deal with. Everyone has deadline. They are part of the software industry, it doesn't matter if you are on the gaming side, or the application side. If you have a client, you will have a deadline. As frustrating as deadline can be, they are a necessary evil in the software cycle. I've read once that if you give two equally bright programmers the same task, give a 1 week deadline to the first and a 2 weeks deadline to the second and they will most likely take the exact amount given to them to finish the task. I believe it. I've seen people take 1 day to do an hour job. Mainly because a task is never schedule for less than a day on a schedule.

What I don't like from deadlines is that they are more often etched in stone by sales department or middle management than by those doing the work. So if the date can't move, that's ok right, we can always throw out some features? Nope, they are etched on the other side of that same stone. So what gives? Personal time and quality of work is normally what goes first.

In my own personal projects, I try as much as possible to impose deadlines on myself. If I do come close to a deadline that I know I can't meet, I might put a bit more of my personal time in the project (but hey, it's all personal time right?) but I will also cut features if I need. As you can read in my post for my first AppStore Application, I had a very real deadline and had a long enough feature list. When I started planning in January, I had a mini game planned for it, although I knew it would be almost impossible to finish on time (I was just too new to Iphone development). So I cut the mini game, I also cut on some needless features. All in all, I finished about half a week ahead of schedule but I rather have more time than not enough. I really didn't know if my app was going to make it through the appstore review in one piece and I'd rather have more time to fix and re-submit than not enough.

I just recently did an estimation on a project I might be moonlighting on(if we get the contract). I normally estimate tasks, not entire projects. I have to say, it's not easy and I don't particularly like it. I've given an estimate that I think will be as accurate as possible given the current knowledge I have of the project. I added time for defect cycles in there for good measures. We'll have to wait and see if the project is approved and what our deadlines will be. Regardless, I think it will be interesting to see how our team of two compares to a team of 20. I bet, that our schedule will hold up better, but it certainly doesn't mean that I can do a schedule to manage 20 people. I probably would fail, like everyone else I know.