Farscape: Peacekeeper War Trailer Goes Online On Wednesday

Farscape - possibly the best science fiction show ever made (and I mean ever!) is coming back this fall with a brand new miniseries.

This is going to be big. This is going to be huge. Tell your friends. It's so big, that it's going to be on the Apple Movie Trailer site.

Tell your friends. Watch the trailer. Watch the show. If you've got Netflix, try getting a hold of some Farscape DVDs. If you don't? They'll be re-running the entire first 4 seasons of Farscape on the SciFi channel in October.

Patience is a virtue.


Microsoft Loses Sports Game Division

Looks like Microsoft has finally finished getting rid of their sports games division. Not that I was a big sports games fan to begin with... but still.

Hmmm... at this rate, there aren't going to be many more games companies left in the Seattle

area. Which is a shame.

One of the reasons I liked living in Seattle was the fact that it appeared to have one of the largest concentrations of applications and games software development companies outside of Silicon Valley.

Since the dot com bubble burst, the number of companies up here have dwindled. This is a huge shame; shrink-wrap software is what I love working on. The less companies, the less jobs... and the less opportunity.

At this point, I'd love to set up a company of my own. That, however, takes capital that I don't have. What I do have though is ideas for several games, and several applications - all of which could be potential money makers. Not huge sums of money, but enough to kickstart a small startup if it's run on a tight budget.

Anyone got any ideas on how to get something like that rolling?


Software Project Management

[This was written in April... and I was cleaning house on my computer, so...]

Over the years I've put together some rough guidelines on software projects and how to manage them. (I've managed two teams so far). This evolving list is something that I've come up with. It repeats what you'll read in most good management process books. But if you've not read them before, you might see something new.

Rule 1: Motivate Your Team

Make sure members of your team are motivated correctly. Each person's motivation is different - and may not coincide with yours at all.

Rule 2: Plan Your Project

Plan your project out accordingly. Use timelines and estimates. Use tools to produce planning documents (such as Project). If you don't have it written down, you're wandering around in the dark with a blindfold on.

Rule 3: Project Planning Isn't Finished Until You Ship

Repeat rules 1 and 2 until done. Timelines are never complete; they change as you go on. Teams never stop needing motivation - different people need different things. Both of these processes are iterative.

Rule 4: Let People Work When They're Most Effective

(a corrolary of rule 1)

It doesn't matter when your team do their work as long as they make it to meetings. You're paying people to work. If they are achieving their goals, they're doing the right thing. Insisting on people turning up at 9am every day and leaving at 5pm is a poor subsitute for actual performance reviews, understanding the work being done, and proper project maangement. For a start, you still have no idea what they're doing if they arrive at 9am. They could be sitting on their asses all day and twiddling their thumbs, perhaps watching the latest plays on ESPN or reading The Economist and The Beano. Maybe they track their stock portfolio all day long, or buy and sell things on Ebay. Maybe they don't.

A properly motivated employee, however, might show up at 11pm and leave at 7pm... and then work on the problem at home. They will work weekends, work evenings, and will pull your ass out of the fire again and again because they enjoy the challenge. Writing software - for really good software engineers - is a creative process. It's like writing music, or crafting a novel, or painting a picture. When the inspiration hits, a really good software engineer will be twenty - or many more - times more productive than a competent one. The rest of the time they're the same as a competent engineer.

If a software engineer feels that they're getting nothing done - and are highly unlikely to get anything worthwhile done - let them go home. Get them out of the office. Don't make them feel guilty about it - just get them out of there. If they're a professional, they will take the time, get their mojo back up, and then spend their official "free" time working on the problem. Making someone sit in a chair for hours at a time just because those are your working hours is useless and pointless. You're wasting their time, your time, and just causing resentment. Brains do not function at full pelt 24/7, and software engineering is very demanding on brain power.

Show me one physicist who works 8 hours a day on writing equations and papers using nothing more than the sweat and blood coming out of his pores as he thinks onto the page. They don't - they spend their time tinkering in a lab, playing around with physical bits and pieces, and otherwise toying with what they're doing. This is worlds different than what a software engineer does, which could most easily be described as doing a really difficult crossword or rubik's cube for 8 hours a day, nonstop. (Or longer, if you consider that most software guys just can't turn their brains off - they think about their programming problems nearly constantly).

Rule 5: List your tasks in priority order

Task lists and prioritization are good for your project, and good for the individual team members. If you don't have them, not only can you not track how and where you're going, but you're doomed to failure every single time. At the very least, you'll burn out your employees very quickly - because every time you throw them through a mad random crunch, you make them so much more weary.

Rule 6: Reward Crunches with Time Out

No matter whether your project is having random, planned, or unexpected crunches, or even if the workload is just too high, make sure that you give your employees some downtime at the end of the milestone. If you don't, you risk burn-out. If you burn-out your employees, you may need to get more employees - because they will walk out on you. This is costly - it costs you time, money and team morale. Especially if one employee leaving triggers an avalanche because the project is mismanaged and is being run close to burn out.

Rule 7: Never schedule more than 4 hours of real work per day

People have meetings, lunches, and life. And frankly, you're lucky if you get 1 hour a day of real work out of anyone at less than executive level - there's just not enough reason for those people to put any more effort into it than that, after all, executives own considerable chunks of the company - regular employees tend to not own squat. But if you schedule for 4 hours of work a day, it all smooths out nicely, everything happens on time, and you maintain a nice high energy atmosphere where things get done right.

Rule 8: Don't Randomly Screw With the Schedule

If you interrupt your engineers, it can take as much (if not longer) as half an hour to get back into the zone needed to thread back together the spatial relationships between everything they're working on into one piece. Every interruption - every other random task - has a similar effect. (This is why Microsoft gives software engineers offices).

Similarly with the schedule - if you throw random tasks, software is VERY difficult to steer. It takes time - sometimes weeks - to adjust to the random changes. In some cases, you have to throw out whole swathes of code just to compensate for the fact that priorities have changed and everything needs to be done yesterday.

If you must make changes, get buyin from people, and at the very least find out what the risks are with the changes you're planning. Better informed = better decisions.

Rule 9: Be Observant

Not all employees toot their own horns. The loudest employees might not be the ones doing all the real work. The quieter ones might be doing several things - it's only when you talk to them or watch them in action that you actually see everything they're doing.

(Corollary: watch out for other employees who try to steal credit from these people).

That's all for now. More later if I remember more to put up :)


Halo 2 Pre-Game Kickoff

Do you like bees?

I love bees.

Back when A.I. was coming out in theatres, there was a pre-movie game. Call it "The Beast" if you will. I was on CloudMakers, and participated in the fun.

Now the game is back. And this time, it's related to Halo 2 (as you can see by the rabbit-hole entryway to the game in the Halo 2 trailer - the URL www.xbox.com flashes up as www.ilovebees.com for a short moment).

I'm playing. Are you? Join the fun at www.unfiction.com - and go to the Haunted Apiary section.



subscribe via RSS