Monday, October 30, 2006

I want a sandwich...

Parenting is one of those things I never really understood, I just do. I know there are heaps of books you can buy on the subject, and that lots of people must freak out because they're not doing it right, and then go buy those books. Or maybe parents in law buy them as a discreet way of telling their children's spouses that they're not doing it right, or maybe nobody buys them at all...

Either way, my approach to parenting is really simple; children are people. They're often really short bizzare crazy people, but they're people none the less. I worry a bit about the supernanny and the baby whisperer training children to regimes and schedules. You can train children to behave according to your rules, the same way you could train a monkey or a goat, sure. But you don't treat people like that. All kinds of organisations from the Third Reich to Heaven's Gate have managed to successfully train people to behave in a particular way. They didn't get their own reality TV show.

My story goes that you should respect your children. That doesn't mean that you should let them do whatever they want - more that you develop a mentor relationship with them, where they'll listen to your advice because they respect it. This means that sometimes you need to tolerate behaviour that you don't like. But hey, I tolerate behaviour I don't like in lots of people, and most of them are grown ups. It means that you teach your kids the value of reason, by occasionally changing your mind based on their opinion. Then, the next time you want them to modify their behaviour, they're more inclined to listen to your argument. I'm not saying that my kids have no rules and can do whatever they want. My kids know about the rules, and why they are there. They don't always like them, but they comply with them.

Society is like that. Lots of rules for you to follow. People complain about 'them' - like how "they" make you fill in your tax return. Well, while my kids are little, I'm them. I'm society.

Humans are much cooler than goats or monkeys. In a child is all the personality and ego and specialness that you'll find in any human that ever lived. As a parent, I don't think it's fair to try to replace those little people's ideas or values with your own, any more than it is to assert your opinion over anyone else. Sure you'll influence them. But it's got to be more about providing guidance and advice than it is about fitting your child in with your life.

Of course, a lot of my ideas on being a parent come from my own Mom, who has decided to start her own site explaining how she managed for so long.

You can find her own, handcrafted thoughts on the topic at

Thursday, October 12, 2006

Selamat Pagi, Blog-Land!

I had the pleasure of getting an e-mail out of the blue from an old friend last week - thanks to the inter-connected world of the blogosphere. He'd ran across my blog (from Cam's blog) and had read up to find out what it was I'd been doing since we parted ways in college. It was kind of weird to talk to someone after such a long time and have nothing much to say that he didn't already know!

Dan's been adventuring in Indonesia for the last seven years, and he's finally 'sold out' and started publishing his writings. You should prime your rss readers (I found one that I love -this one!) and head on over to his new blog to get the latest updates on his progress -they'll be required reading around these parts.

Welcome aboard, Dan-o!

White Collar Tweakers

I mentioned a few weeks ago that I was trying to come to terms with exactly how to use the Novation Remote Midi Controller in conjunction with Reason...

Well, I'm still trying to figure it out - I've thrown away nearly everything that I've created, but today I managed to create a song that was worthy of persistence.

If you'd like to hear it, you can download it here.

I figure I'm using about 2-3% of the software's features. Not even having the faintest idea how a synthesiser works, I'm viewing the exercise as something of a random knob-tweaking frenzy...

So many buttons to push, so little time...

Wednesday, October 11, 2006

5 ways to survive the Death March

In Software Development Land, there is one kind of project that nobody wants to end up on.

Identifying features of these projects often contain wildly unrealistic goals, crazed unrealistic timelines, a lack of adequate requirements or supporting technical infrastructure, and often, a combination of all of those things.

These projects are affectionately termed 'Death March' projects. I know the name sounds a little extreme, but that's really what they are called. (Here's the wikipedia link to prove it.) I've just survived a project that has had me working crazy hours, weekends, public holidays, and basically any time that I wasn't asleep in an effort to pull one of these off. It all wrapped up today, and in the end, it wasn't that bad. Well, it was actually pretty bad in some ways. For example, my kids haven't seen me in 36 hours, and my wife hasn't actually kicked me in the balls , (but to be honest I wouldn't blame her if she did), so for the purpose of this article, I'm defining "not bad" in the sense that the project itself didn't fail.

So, I thought I'd share my thoughts of how to survive one of these projects, keep your team's reputation intact, and emerge with some semblance of dignity. (Even though the resulting bags under your eyes and disheveled appearance may very well scare young children.)

I'm going to leave out the concept of how to identify if your project is a death march or not - I'm assuming you already know if your project qualifies. So without further ado, here are my 5 tips for death march survival:

1) Cut the right corners

One of the hallmarks of death march projects is that things get left out. In an effort to make the deadline, all kinds of smart, sensible things that Joel tells you to do, like bug tracking and spec writing get abandoned in favour of getting it done. This makes sense - a Death March project has to take shortcuts if you want to have any chance of making it. What's crucial is that you make each one of these 'discard' decisions intentionally, and really carefully. Everything you skip will result in some level of risk - and you need to determine if you're willing to accept it.

Things we abandoned included source control (we had a small team in the same place), code reviews, major re-factoring, and most of the formal bug-tracking (we used a tadalist). We abandoned any written technical architecture, Object modeling, and coding standards, like variable naming or commenting. We didn't do unit-tests, or any other automated testing.

Pretty much all we did have, were a great requirements document with use case analysis, and a great functional spec, both signed off by the customer. This left is in the position that we didn't have any idea of how we were going to technically implement the thing in three weeks, but we did know what it was we had to deliver.

The most important point, in my experience, is that you might be able get by without most of these otherwise (extremely sensible) things, but I don't think you can abandon accurate requirements analysis. If you aren't sure exactly what ridiculous thing you are going to build in this ridiculous timeframe, you're pretty much hosed. Which leads on to:

2) Find the one true measure

When (and if) your death march project finishes, it will be judged on one thing - the way the product meets the original project goals. (Again, some projects don't have these, which makes it nigh impossible to pin down whether or not your project is a success or a failure).

Early on in the march, you need to identify precisely what it is that will determine your project's success (or it's failure.) Often, this is tied directly to the customers expectations.

Sometimes, the customers expectations are also too fuzzy to determine. In this case, I'd recommend that you look through the expected functionality and find the one or two use cases that will either:
(a) be used most often; or
(b) be used most by the user who can most influence the success or failure of the project.
Such obvious bias and prejudicial treatment is a little unethical, but hey, it's your ass on the line, right? Optimize your application for the one true thing that will give you the best chance of looking like a success, even if your project is largely smoke and mirrors...

3) Single Thread

The team needs to be able to focus only on the project. Don't try to maintain any persistent contact with a regular day job, or other people who want to ask questions about that other application that was built last year. Isolate the development team, and cut them off from any further distractions.

If possible, remove access to email - it's a huge source of distraction. Even better, move them off-site, and have them work from a relaxed environment, free of regular workplace hassles, where they can get all scraggly and unshaven and wear t-shirts.

Let the PM take care of any brewing issues with the customer or deadline or finances or anything else. If you don't have a PM- you need to appoint one immediately. Make him or her solely responsible for the success of the project. And they can't be on the development team - Single thread per brain, remember? - The team will have the best chance of success if it never has to look up or deal with anything but the application itself.

4) Do what you know

Software Developers love to play with new stuff. Lucky for them, the world delivers an endless stream of mysteriously named technologies that are really exciting and fun to play with. Things like Xaml and WPF and Indigo and RoR and REST and SOAP are all very interesting, but if they are peripheral to the core skill set of the team members, then abandon them all immediately.

If your developers are not bona fide experts in the technology you are building your software in, then either pull them off the project, or re-build the project in technologies that they really know.

If this means writing your death march program in Visual Basic 5, then, so be it.
The last thing you need is for your team to be trying to deliver a project armed with technological tools that they don't understand. In the death march, Low Tech is King - pick the one true measure, and deliver that, regardless of 'coolness'. An overwhelming focus on results, rather than method, should be the focus for the team at all times - not playing with weird toys.

5) Heroes

This one goes without saying, but you just can't pull a death march project off unless you have a really, really great team. You need to make sure that everyone has the hero mentality - that the project can't be delivered unless they all give everything they've got.

It's worth noting that these kinds of projects are generally not good places for young, inexperienced kids who are trying to learn something. You need seasoned, skilled developers in order to even have a chance of making it. That means hardworking people who are dependable, and not easily distracted.

If you've got people who just can't cut it, you will need to either do some really aggressive hiring - and be prepared to pay premium cash, because most of the folk you really need to hire will be able to identify a death march project really quickly, and hey, nobody wants a gig like that..., or you'll need to restructure the project to meet the skills you've got, which might simply result in not being able to get there. Failure is never far away...

In short, the most important thing you can have with you on these projects is a stark and often terrifying focus on reality. If you keep your head in the clouds, you'll find that when you emerge, everyone will be screaming and yelling and pointing fingers.

On the other hand, if you carefully monitor what it is you really need to get done, match the application technology with the skills you've got, and you have an amazingly dedicated team, and the planets align just right, it is actually possible to make it out the other end (relatively) unscathed.

Thursday, October 05, 2006

How to rename an XML Node in C#

This was driving me crazy - here's an easy cut and paste solution to not being able to use the DOM to rename a node for lazy developers like me:

public static XmlNode RenameNode (XmlNode node, string namespaceURI,string qualifiedName)
if (node.NodeType == XmlNodeType.Element)
XmlElement oldElement = (XmlElement) node;
XmlElement newElement =
node.OwnerDocument.CreateElement(qualifiedName, namespaceURI);

while (oldElement.HasAttributes)

while (oldElement.HasChildNodes)

if (oldElement.ParentNode != null)
oldElement.ParentNode.ReplaceChild(newElement, oldElement);

return newElement;
return null;

Ahh. That's better :)

Tuesday, October 03, 2006

32 Sun-Laps

On Friday the current amorphous collection of cells (and more importantly their digital replication instructions) that make up me passed a milestone: the completion of their 32nd lap around the giant mass of incandescent gas that brings life to the planet Earth.

Or, to put it somewhat more concisely, it was my birthday.

My Dad and my Congo-family had sent me some money in celebration of this momentous event, and despite my inclination to pay some bills, my Wife insisted that I spend it on something for myself. It's pretty rare for me to have some money that I have to spend on fun stuff. You know what? I discovered that if you check out the shops, there are a LOT of things you can buy. I mean a lot. And they all look really cool. So, after much prowling and perusal, I had narrowed my purchasing field down to the following.

a) some kind of digital camera,
b) some kind of musical instrument.

In the end, I decided I couldn't afford to buy the kind of camera I wanted, and yet I still hankered for some kind of digital do-hicky with that fresh Chinese warehouse smell...

So I bought one of these.

A Novation RemoteLE 25 midi USB controller. What's that you ask? Well, I'm not still not quite sure... But when you couple it with a PC, and this software from Sweden, you can play and record nearly every instrument in the world, and several instruments from other worlds. In short, it's the most entertaining thing I've discovered to do with a computer since Boppie's Great Word Chase.

The ability to create unlimited synthesizers, effects racks, samplers, sequencers and drum computers is impressive, but the 'virtual patching' where you flip them all around, and are confronted with a mess of cables, just like real life is absolutely inspired.

I had hoped to be able to post some intriguing and wonderful music, but the sad reality is that I'm still trying to figure out how to make it work. Maybe later.

Lap 33 progresses, accompanied by weird and creepy goblin noises.