sealed abstract class drew {}

I’m doing freelancing full-time this summer.  Here’s a brief summary of what I’ve learned so far.

Lesson 0: Be good.

The key to being a successful freelancer is being good at what you do.  If you are bad, no amount of business wisdom will save you.  In the iPhone business, this means:

• Write a half a dozen or so apps and get them through App Review.  Kind of obvious, really
• Troll the official and unofficial developer community hangouts and follow what is going on, especially with regards to new “unwritten” app review guidelines and practices
• Stay up-to-date with the latest beta SDK documentation so you know what’s coming
• Spend a lot of time trying out iPhone apps
• Spend a lot of time learning new SDKs and APIs

Lesson 1: Say “no” a lot

Apple wins by saying “no” to features.  It makes sense that in Apple’s market, you win by saying “no” to clients.  Some examples:

• Client wants to add lots of really complicated features.  But you can solve 80% of the problem with a simple solution.  Simple solutions are easy to maintain and can always be extended later to recover that last 20%.  If the client can’t understand this, perhaps they shouldn’t be partnering with Apple, the king of simple.
• Avoid visual overload.  This is a design aesthetic, but it’s key on Apple platforms.  Again, if the client doesn’t get it, what other parts of the HIG is the client going to fight you about?
• Don’t negotiate on estimates.  I’ve had dozens of people who want me to come down 5%, 15%, or 50%.  If it was going to be less, I would have quoted less.  If the start of the relationship is a spat about $500, what does that say about the rest?

Lesson 2: Filter clients fast

If you are good (see Lesson 0), the amount of work available to you is effectively infinite.  Every person who has held an iPhone has an idea for an app and dreams of riches.  The number of people who can take that idea and convert it to a product, on-time and on-budget, however, is vanishingly small–perhaps 10,000 good developers at most.  So only take the best clients.

This concept is a lot more counterintuitive in real life than it is on paper.  You are looking somebody in the eye who is offering you $5k (for a $6k app), and turning them down, because you know that next week somebody will call you who is willing to pay full price.  It means turning down a stellar multi-app repeat client who pays on time but is extremely picky about the background color of unchangeable Apple UI controls because you know that right behind him is another stellar client who trusts your (and Apple’s) professional design judgment and will be a lot easier to work with.  Turning down a deal in-hand that’s “ok” but less than stellar simply goes against all intuition.

As soon as I have any idea at all what the project will be, I quote new clients a price with a margin of error of a couple of thousand dollars.  I do this before investing any work into writing an estimate or even hearing much about the project.  I need to weed out the “revenue sharing” people instantly, not after even one hour of my time.  There are simply too many of those guys out there.

Lesson 3: Don’t bid

There are a lot of bidding war sites out there like iPhoneAppQuotes.com and GetAppQuotes.com.  Leads from them aren’t worth the time it takes to write an estimate.  Here’s why:

• Competent developers already have plenty of work.  So the number of competent developers on those sites are pretty small.  So if you’re a developer, you’re bidding against incompetent people.
• Those incompetent people you’re bidding against?  They will quote a lot less than you.  It doesn’t take much money to not deliver a project.
• All those clients (speaking from experience here) are either clueless or penny-pinchers.  The reason they’re putting projects up for bid is because they want it done (or not done, as evidenced by the responding developers) as cheaply as possible, even if it sucks.

Fast food is cheap.  It’s the same everywhere.  Any fool can be taught to make it.

I am not in the fast food business.  I am a chef.  I juggle Apple, clients, changing HIG guidelines, changing SDKs, tools, documentation… I design good layouts.  I think through small-screen UI design.  I pay attention to battery life.  I look at what the client wants and I see past the requirements and into the real business problem.  I anticipate what they really want, and I find the right balance between features and complexity.  Those are specialized skills.  They’re not cheap.  They’re not replicable.  They’re not scalable.  And if you give that speech to somebody who’s trying to order a burger at McD, you’re never going to get anywhere.

A lot of people are worried about lowball foreign developers “stealing” all the work.  I’m not concerned, any more than the 5-star chef is concerned when McD opens next door.  It’s not within 100 miles of the same market.  I will solve the problem for you and bill you a price to match.  Fast-food developers will copy and paste something off a forum somewhere and you’ll be stuck in revision hell forever until you give up and hire someone new.

Lesson 4: Revenue sharing is only mostly evil

In the past, I’ve come down pretty hard on revenue sharing:

If you’re going to offer something stupid like “revenue sharing”, just walk away.  Developers are going to laugh at you.  I have a “revenue sharing” deal already–I do development work, and Apple sends me a monthly check.  The only way to compete with that is to pay actual money up front.

I still think this is mostly right.  I have all the revenue sharing agreements I want already: with Apple.  And there’s still no shortage of people offering me a 50/50 split for their “app idea”.

However, I have begun to offer a 5% discount for a 3c per copy royalty for certain projects where the clients are known to be reliable/honest and the product is sound.  This gives me a little bit of residual income and a little bit of risk.  The smart clients realize that it keeps me invested in their projects.

Conclusion

I’m learning more this summer than I’ve ever learned in a classroom.  Being forced to make actual money is perhaps the best teacher of all.  Why don’t we expose students to something like this before they enter the workforce?

Due to hardware problems, I’ve managed to lose quite a bit of data. My most recent full backup was from 2009.

If you know me, you know I have a very ridiculous backup setup, with stuff stored on multiple continents and pretty much instantly restorable going back years. Unfortunately, Sealed Abstract was not part of that setup (it is now…)

I’ve taken the opportunity of cleaning house. Getting rid of some old posts, and reimporting new ones from Google’s Cache. I’ve also adjusted the permalink structure, something I wanted to do for awhile but was afraid of breaking existing links.

I think I’ve got SA and DrewCrawfordApps (and a few other sites hosted here) back up. I’m still working to restore some custom servers I had running here.

If you see anything seriously missing, I probably have it around here somewhere… shoot me an e-mail and I’ll put it back up.

##############################
####DREW CRAWFORD#############
####ASSIGNMENT 2##############
####COMPUTER ARCHITECTURE#####
####FEB 2 2010########
##############################
.data
.align 2
A: .asciiz "A\n"
.align 2
B: .asciiz "B\n"
.align 2
C: .asciiz "C\n"
prompt: .asciiz "How many disks?"
.align 2
newline: .asciiz "\n"
.align 2
print:  .asciiz "Move from \n"
.align 2
to: .asciiz " to \n"
.align 2
movet: .asciiz "The total number of moves is: \n"

.text
la $a0,prompt
li $v0,51
syscall
move $t0,$a0

#####t0 - n
#####a1 - "A"
#####a2 - "B"
#####a3 - "C"
la $a1,A
la $a2,B
la $a3,C
jal hanoi
#print totals
la $s1,movet
jal printstr
move $a0,$v1
li $v0,1
syscall
li $v0,10
syscall

li $v1,0

#A hanoi solution in 32 instructions
#(11 print instructions, 1 move count instruction)
#So only 20 algorithmic instructions.
#And only one expensive lw/sw pair per call.
#Beat that.
hanoi:
beq $t0,0,silentreturn
addi $t0,$t0,-1
xor $a2,$a2,$a3
xor $a3,$a2,$a3
xor $a2,$a2,$a3
addi $sp,$sp,-4
sw $ra,0($sp)
jal hanoi
##############non-algoirthmic section
#An implementation detail prevents me from using the printstr syscall on my emulator
#Feel free to replace with the syscall
la $s1, print
jal printstr
move $s1, $a1
jal printstr
la $s1,to
jal printstr
move $s1, $a3
jal printstr
la $a0,newline
la $v0,4
syscall
addi $v1,$v1,1
#############end non-algorithmic section
move $t1,$a3
move $a3,$a1
move $a1,$a2
move $a2,$t1
jal hanoi
xor $a1,$a1,$a3
xor $a3,$a1,$a3
xor $a1,$a1,$a3
lw $ra,0($sp)
addi $sp,$sp,4
addi $t0,$t0,1
silentreturn: jr $ra

printstr: #my hack around a printstr issue on my emulator
ld $s2,($s1)
andi $a0,$s2,255 #select xxxX
li $v0,11
beq $a0,10,ret
syscall
andi $a0,$s2,65280 #select xxXx
srl $a0,$a0,8
beq $a0,10,ret
syscall
andi $a0,$s2,16711680 #select xXxx
srl $a0,$a0,16
beq $a0,10,ret
syscall
andi $a0,$s2,4278190080 #select Xxxx
srl $a0,$a0,24
beq $a0,10,ret
syscall
addi $s1,$s1,4
j printstr
ret: jr $ra
            

A lot of developers (myself included) have expressed disappointment in the app store on ideological grounds. Can’t install your own software! Apple keeps competitors off the platform! Apple doesn’t let innovative apps through!

But there’s another angle to this that nobody’s covering. The app store keeps piracy off the platform. Not because it makes buying easier than pirating (which it does), but it also makes pirating hard. You can’t be running the latest firmware. You have to forego security updates. Apple’s own development tools often have unexpected behavior on jailbroken devices (not intentional, I think. Just Apple never bothered to test it).

And so developers are pacified because piracy is constrained to those people who wouldn’t have bought anyway (in a way that computer apps aren’t)[1]. This sort of stronghandedness hasn’t worked on other platforms because the users are up in arms. Extra DRM isn’t a feature.

But in this case, the app store acts like an insurance policy. None of the apps are going to wipe out your data. They’re not going to hook into your OS and break Dashboard. They’re not going to forward themselves to everyone on your address book. Users are willing to put up with buying more software if it actually works. And so this is an acceptable trade for them.

And meanwhile, Apple is sitting in the back, pocketing lots of cash[2]. They’ve pacified the developers with more money (less piracy), and they’ve pacified the users with software that works. They’ve solved the two biggest problems in the industry, and they’ve been incredibly successful as a result. The major personal computing platforms of today are no longer desktop and laptop PCs. They’re devices running the iPhone OS.

2012 may very well be the year of the Linux desktop. But only because people using Linux might be the only desktop users left.