Having spent all too many hours enjoying Air New Zealand's hospitality - in the loosest sense of the word - I remain perplexed as to the design of their entertainment system. Things have moved on a lot since I last did a long-haul trip in 2005 - while we were chuffed then to have multiple movies broadcast to your seat, we now have personal on-demand systems in each seat. There's just one problem - they're somewhat rubbish.

So rubbish in fact that Air New Zealand warn customers: Please do not press the buttons too fast, or your screen will freeze and you will be unable to use it for 15 minutes while it reset. Robust, that. And the temptation is definitely there - there's a notable pause as you press each button, and sometimes it misses them all together. It doesn't help either that when you try to select a movie you have three fifths of the screen occupied by a large blurb teaching your grandmother to suck eggs, and therefore have a minimal section of the screen in which to page through said content. Streaming is also somewhat slow - the movies are compressed enough that MPEG artefacts are very clear, and you attempt to fast forward at your own risk.

The most vexing thing about all of this is that these problems have been solved: either you have smart terminals style devices talking to a central server (there's a hell of a lot of embedded hardware that can decode MPEG very cheaply) or you use dumb terminals with a multi-user server driving everything. How you end with with terminals that offer shocking performance and a 15 minute reboot time is beyond me.

It's a telling reflection on the state of software engineering that not only is this kind of half-arsed solution produced these days, but that it's both accepted and lauded by the customers and users. We wouldn't accept this from an engineer of any other form - why here?

Wired have a story today about how tech isn't helping US workers to be more productive. It's an interesting point, and possible the most interesting thing is that it has taken so long to come to light. Why? I can think of two reasons off the top of my head - no training and no translation. Let me explain, especially that second term.

Firstly, the easy one. Training. Earlier this week I was at the bank. Throughout the pain and suffering that is a bank appointment the lass interviewing us was typing in words a single finger at a time. When she wanted a capital, she'd stop, press caps-lock and then press the key. She also looked younger than I - probably in her early twenties, so didn't even have the excuse of not keeping up with the times. Which leads to our first problem - how can you possibly expect these tools to help people when they aren't taught the basics about using them? I remember our PC classes at secondary school - word processing using Windows 3.1 on 286s and 386s. This hadn't changed come 1997. This might explain why she had trouble with the start menu but certainly doesn't explain her unfamiliarity with the keyboard, a device mired in antiquity.

Secondly, translation. Most applications are designed by business teams - they sketch out what they want and then those of us who think adding ++ to something makes sense turn it into a program. Good in theory. Bad in practice. Why?

Firstly, business people focus on business. They design tools around their current workflow - they don't know how it can be made better. For example, we're working on an estimating tool at work. How do we do the UI? We design it around a table which looks like an Excel spreadsheet. Guess how they used to do estimates. Secondly, developers can't design UI. That's not a suggestion, it's a plain NO. If you let developers design a UI you tend to end up with the GIMP - an extremely capable tool that's horrendous to use. If you let designers design a UI you end up with something that's very pretty and completely unusable. And let's not forget that management have a stake and often have arbitrary choses about toolkits or requirements that are politically motivated and can make life harder for all. For instance, a previous client didn't like open source software - no good reason why, they just made us write our own. Result was a mess of code that didn't do as much, wasn't as stable and needed to be maintained entirely by us. And, of course, they weren't interested in paying us to maintain it. Spot the problem?

The result tends to be mediocre software. The examples are endless - I've worked on a few myself. And it's disheartening - it does make you wonder why you're doing it. On the other hand when you do put yourself in the firing line, fight for something you know will make things better and win, it's a fantastic feeling. But you've got to learn with losing sometimes for reasons which often make little sense. And that is perhaps why people who are happy to turn up, work and go home do very well as developers when those with a passion for the area often find life a lot harder. Perhaps it's not even restricted to this area, not that I can comment. But at the end of the day, 'tis better to have tried and failed than to have given up before you even started.