Talk Funnel

Idea vs. Execution

Raven Zachary in a post on the O’Reilly Inside iPhone Blog raises the old idea vs. execution argument. *Sigh*. This is the same debate I’ve been hearing (and having) for the past twenty years and it keeps popping back up again.

Folks, it’s not zero-sum / either-or. It’s both. One hand holding the other. Yin and yang. It’s like saying who was more important in your creation: your mother or your father? (OK, some might say it was the Rum and Coke, but remember that’s just the catalyst.)

A lot of people bandy about the phrase “Ideas are a multiplier of execution.” As near as (Google) can tell, this phrase was popularized in a short post by Derek Sivers. What most people ignore is the conclusion he posits:

To make a business, you need to multiply the two.

In other words: I * X = success

If either I (idea) or X (execution) values are low (or zero) the outcome suffers–or stays at zero. Without a good idea, the best developers will sit around and play games or post rubbish on Twitter. Without a good implementation the best ideas will sit around till the cows come home. And the converse is true as well (bad idea/bad execution).

Architects can draw as many designs as they want, but without the builders nothing will get built. The builders can build the most fabulous walls but they won’t quite connect because they don’t have good plans.

Shall I go on? (NNNNoooo!)

So the next time you discount somebody’s idea by assigning it a value of $0, you may want to pause and give it another listen. Naturally, there are lot more ideas than implementations, but that doesn’t mean ideas are worth $0. It just means you need a knack for sifting the good from the bad. And let’s not forget good and bad are subjective valuations. If it wasn’t so, all movies and games would be instant hits.

OK, ’nuff said. I’m sure this isn’t the last time I’ll be hearing this debate again.

Product vs. Project

On a different topic, if you go by Raven’s numbers your typical developer making $125/hr working full-time will gross ~$250K a year (most developers I know work only part-time, however). If they write an app, put it on the app-store and it sells, say, 30,000 copies for the year (a conservative estimate) they would need to price it at around $10.99 in order to match the consulting rate. Write a hit (say, 100,000+/yr) and at that price, you’d be waaay ahead of the hourly rate.

The dilemma most professional iPhone developers will face is whether to take on a consulting project or spend the time working on their own product. I can tell you from personal experience, it’s pretty damn hard doing both. In a perfect world, you could do one for a while then switch to another. But it rarely works that way. While doing consulting, you’ll have to battle the constant nagging feeling that you’re actually losing money by not having your product out there and the opportunity may well slip away when someone else beats you to the market. On the other hand, while working on your product and not generating income, it’s hard to say no to someone offering you cash.

It’s a tough choice (and you should drop to your knees and kiss the ground if you’re lucky enough to be facing such a dilemma.)

Pricing

The other thing to keep in mind is that if you’re planning on writing an app for yourself and pricing it low (say, $0.99) then you’re looking at a heckuvalot of copies to make it worth not going the consulting route. iPhone developers wanting to do product development for themselves and make a good living at it might want to take Andy Finnell’s sage advice and price their apps at a more reasonable rate–something that would at least cover their costs and allow them to turn down subsequent time-intensive consulting gigs.

My personal feeling is no competent developer should be putting out $0.99 apps. They’d only be shortchanging themselves. The iPhone store is in its early stages. It’s too early to have all the shelves be stocked with apps retailers put in the discount bargain bins.

Time Machine is great, especially if hooked up to a network storage device like Drobo so you can just have it run in the background. In my case the Drobo is connected to a Mac Mini acting as a network file server (yes, I know it’s not officially supported, but it works fine under Leopard).

However, lately the backups have been taking a lot of system and network resources, rendering the machine (in this case my development laptop) practically unusable while they run. But since Time Machine runs in the background, it’s OK to lower the backup daemon’s priority and let it run a little slower.

On Mac OS X Leopard, this is the command that does the trick. From the terminal:

sudo renice +5 -p `ps -axc | grep backupd | awk '{ print \$1 }'`

Here’s what’s going on:

• sudo – This runs the command as the root. You will need to enter the administrator password.
• renice – This is the standard Unix command for changing the priority of a running application.
• +5: Process priorities under BSD Unix-based systems typicall run from -20 to +20, with +20 being lowest (i.e. running slowest) to -20 being maximum (yes, I know it’s unintuitively backward, but there’s an old historical reason for it). What we’re doing is bumping Time Machine daemon’s nice priority up by 5 (or any number you want) to let it run slower.
• -p pid – This is the process id of the process you want to adjust. Since this changes every time Time Machine runs, we have to have a way to find it dynamically at runtime — which is where the rest of the line enclosed in ` back-quotes come in. On most Unix shells, items enclosed in back-quotes get executed and the result returned back to the command line. So we’re going to look up the process ID of the current Time Machine server process and return it here.
• ps -axc – The ps command returns a long list of all running processes on the system. We need to filter out the one we want, which we do by piping the output into a grep filter next…
• grep backupd – We’re taking all the output from the ps command and only keeping those lines that contain the string backupd — which happens to be the name of the Time Machine server. So we end up with a single line of ps output that looks something like this:
  

  19041 ?? 1:07.48 backupd

  But what we need is the process ID to pass back up to the renice command. In this case, it’s the first number on the line. We need a way to extract only that, which is where awk — the amazing text processing Swiss-Army knife — comes in…

• awk “{print \$1 }” – By default, awk splits its input into chunks based on whitespace. We’re simply asking that the first item be returned. Any time you do this, you should apologize to awk for so massively under-utilizing what it can do. It’s like driving your Formula-1 car down to the grocery store to buy milk. In this case all we’re doing is asking it to split up some text and return one item to us, something that awk can do practically in its sleep.

When you run this, the sudo part of the command will ask you for your admin password, then proceed to do its thing. Put it all together and you’ve got yourself a simple way to slow down Time Machine so it’s not such a CPU hog.

If you’re enterprising, you can put the whole thing into a shell function and run it over and over. The following code goes inside your .bash_profile file.


function tmslow {
    echo "Reducing Time Machine priority..."
    sudo renice +5 -p `ps -axc | grep backupd | awk '{ print \$1 }'`
}


Start a new terminal session (to make sure the shell function is loaded) then invoke tmslow and enter your admin password. It prints out a little message reminding you what it’s about to do.

Remember, the renice command doesn’t stick, so every time you reboot or a new Time Machine session starts, the process goes back to normal priority. There are ways to automate the priority lowering scheme or even make it permanent, but I don’t recommend doing that. Sometimes, you may want backups to run full-speed. Unix makes it trivial to do what you want by stringing together some built-in commands.