Living Close to the Bleeding Edge...

A short while ago, I decided that it was time to update my desktop system. I'd been using it less and less, having bought myself a Toshiba M205 Tablet PC in January... but then, we finished shooting The Good Samaritan, and it was time to edit it.

At which point, I discovered to my absolute horror that my 1.4GHz Athlon system just wouldn't cut it - because it didn't support the SSE2 instructions necessary to run the newest versions of Adobe Premiere - which also were the only versions which supported the 24P DV footage we were capturing using Miah Hundley's Panasonic camera.

(Miah, by the way, is really cool. I sincerely think that he's going to go very very far in his movie making career - certainly, if I were a betting man and the choices were me or him making it in Hollywood, I'd bet on him first)

Of course, because I still want to edit this film, I decided that... well... screw it. It's time to use those high credit card limits for what they're intended and upgrade the systems. At the same time, I went ahead and bought the full version of Adobe Premiere Video Collection Pro. Very cool - comes with Photoshop, Premiere Pro, Encore DVD, Audition and After Effects Pro. Basically, everything I'll ever need until I start shooting on actual real celluloid film and end up needing to Avid systems to do the editing.

To have a system to run it on, it was time to update my hardware. I already had 2x80Gb drives, a 40Gb drive, DVD+R burner, DVD reader, 2x512mb sticks of PC2100 RAM, and a firewire editor card. At the very least, I'd need a Pentium 4, so I went out to Fry's and went on a spending spree.

I walked out with a Pentium 4 3.2GHz CPU, a P4C800 Asus motherboard, 2x512Mb ultra low latency DDR Ram sticks, and two 250Gb 7200RPM Western Digital hard drives. (They ended up in a spanning RAID array for high speed access, so now I have over 1/2 a terabyte of space on my machine. This figure is mindblowing.... and I'd never have dreamed of having so much just a couple of years ago).

Well, the system was a little unstable. I've gotten about 3/4 of the editing done so far, but kept running into crashes, glitches, hangs and bluescreens. So I decided to start playing with this system to find out what was going wrong.

Ends up that it's a memory stick. What's amusing is that memory sticks have heatsinks on them now, they're being run so fast and hard. Only one of them is having a problem - the other is fine.

I remember when memory was really really stable. Chips which didn't function correctly used to be pretty rare. And these days, features are getting so small on memory chips that you're pretty damn lucky not to get memory corruption just from normal everyday background radiation which flies around all the time - and there's nothing you can do about it.

I think the next memory I buy will be error-correcting. We're riding very close to the edge, it seems. Expect things to be... flaky for a while. Unless we can figure out a new way of handling memory, that is. Maybe integrate it with the CPUs on a massively multi-layer 3D cpu die. Might even be lower power too.

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 :)