I’ve spent the last five years of my life doing embedded software for mobile phones. So everyone assumes that NthCode specializes in mobile application development.

We don’t.

Don’t get me wrong, I considered it. But I just couldn’t figure out how to make money writing mobile apps.

Why?

First, you have the platforms: Java, Symbian, Windows Mobile, and BREW (and now Android and iPhone). So, if you need to deploy your application on any handset, you’ll probably need to support all the above platforms. And, then, within each platform, there are multiple versions, which eats up a lot of your time.

Second, you need to get your app onto a handset. And I don’t just mean *your* handset, I mean, your neighbor’s handset, your mother’s handset, that guy in another country’s handset.

How do people get it onto their handset?

Well, you can get a carrier and manufacturer to preload it for a given market. That involves getting on a plane to visit some carrier somewhere and then meet with the handset manufacturer to get your applications installed.

Or you can ask people to download it – probably from their carrier’s portal. How does your soon-to-be user access your carrier portal? Some people know, but most don’t. So this is another barrier you need to jump over. Or maybe the carrier needs to jump over it. Or, I dunno, the end-user certainly needs to jump over it.

Oh, it’s awful. Don’t believe me? See what Paul Graham said about a team that had an idea for a smartphone applicatoin: Quite possibly the worst idea ever.

Then, if you haven’t given up, yet, you need to figure out how to get paid for it – in a timely manner. I don’t know how it works in most markets, but China Mobile has a reputation for taking six months to pay.

The only thing that comes close to solving the above problems is the Apple iPhone App Store. (See Apple Launches iPhone App Store)

The App Store isn’t perfect, but it’s a lot better than what I described above. Specifically, there’s only one – wildly popular – device to support and only one distributor, Apple, to deal with. And I have a feeling that Apple will pay you when their users pay them.

I am happy to see that things are getting easier for mobile application developers. But that doesn’t mean we’re going to start creating iPhone applications.

I don’t like specifications. They are not thought through when created, never up to date when needed, and get in the way of writing good code.

So why write a spec?

Well, the traditional reasons I was told are that it’s more efficient to figure out how to do something in a spec than to figure it out after you’ve written the code (true, but if the spec is hurried through, then the issue isn’t thought through) and that they help people come up to speed on your software when they are added to the team or leave (if the spec is well thought through and up to date, this might be true, but, on the other hand, if you’ve hired someone who isn’t smart enough to dig into my beautiful code to figure out how the system works, then you’ve made a hiring error ... and why am I not working here anymore?).

But now I’m writing a spec – for two primary reasons. First, the project needs a graphic designer, and that person needs a spec to work from. Second, the project has to be tested, and the testers need a spec to design their test cases.

And, third, the other folks on the team need a brain dump of what’s in my head so they have a firm idea of what they will be doing.

And, fourth, I need to write it all down so I can eliminate non-critical things from the spec so that the team doesn’t waste time getting to market.

So now I’m writing a spec. And I’m actually enjoying it.

Joel Spolsky’s famous blog, Joel on Software has a two-part article on spec writing that’s better than anything else I found during my google searches.

Part 1. Painless Functional Specifications - Part 1: Why Bother? Part 2. Painless Functional Specifications - Part 2: What's a Spec?

I spent some time in Google – the other sites are worthless. But feel free to dig.

Okay, cool video of the day: Using Photographs to Enhance Videos of a Static Scene

These researchers wrote software that analyzes moving video to reconstruct a 3D representation of a scene that they can then modify to increase fidelity, and remove and modify objects.

Very cool.

Next up, someone explains in rather plain English how Teleportation and Time Travel may someday be possible. Now I need to find a way to work Quantum Entanglement into common conversation.

And, finally, there’s been a battle in the blogosphre between the bootstrappers and VC-funded as to which way is better. The 37signals guys, who, normally, seem to be marketing their products by saying controversial things have a good response to why entrepreneurs should trust customers over VCs.

Enjoy!

Here’s a great article on Why Apple doesn’t do “Concept Products”

Kontra talks about the endless product concepts put out by General Motors, Nokia, and the like that never go anywhere, and comes up with a new spin on one of Steve Jobs’ favorite sayings:

“Real artists ship, dabblers create concept products.”

I’ve worked on products that never made it to market (that’s what burned me out and had me backpacking around Asia for the better part of two years). And I’ve worked on products that shipped in the millions. Shipping rules. And shipping things that don’t suck is even better.

Good article. Check it out.

Back before I ended up in China, I spent about two years of my life backpacking around Asia. Along the way, I met-up with an Argentinean, who’d spent time in Africa. He told me that while there, he ended up discussing with an African villager the cost of a wife in cows.

“In your country, how many cows does it take to buy a wife?”

“Cows?”

“Yes, to buy a wife. How many cows must you give her family?”

“Well, we don’t use cows to buy wives.”

“Right, but if you were using cows, how many would it cost?”

... Or maybe goats?

I am worth nine goats (And nuthin’ but nuthin’ beats Mom’s home cooking). How about you?