Judicious Use of Shitty Code
Here’s a little secret for newbie app developers out there: a fun app has nothing to do with clean code.
Some of the worst code I’ve ever written has been in my most successful projects. Version 1.0 of Pillboxie was a tangle of spaghetti code written without delegation, NSNotificationCenter, or KVO. Let that sink in. Everything was somebody else’s property. Pillboxie 1.0 was featured at launch and many times thereafter. I haven’t updated that app in years and people still download it and use it.1 Riposte, still used and loved by some App.net diehards, has one or two view controllers I wrote that are thousands of lines long. The app was littered with procedures that should have been generalized but got copied-and-pasted everywhere. And it didn’t matter. If we’d had the time (Riposte was a side project) to write all the code “correctly,” it wouldn’t have made the app any better for the end user.
Not all shitty code is equal. There’s such a thing as judicious use of shitty code. Your app shouldn’t crash, so don’t try to be clever. Don’t assume that a web service will always give you the values you expect. Don’t assume that some index is within the length of an array. Don’t pass an NSManagedObject between threads. Some corners shouldn’t be cut.
If your goal is only to learn, then write clean code. But if your goal is to build a successful business, then stop trying to impress your heroes. Learn as you go. Be messy. Don’t use new technologies. Don’t use new languages for their own sake. Don’t waste time trying to think of the most elegant way to break an egg. Just smash it on the counter and leave a FIXME: comment and move on. The only question that matters: is this app fun or what?
-
Boy, do I really need to update that app sometime. ↩